Tout au long du projet, plusieurs étapes vont se succéder, afin qu'ensemble, nous dégagions les fruits d'une collaboration réussie.
Vous prendrez connaissance dans cet article de ces différentes étapes, de quoi elles se composent et pourquoi elles sont importantes. Ces étapes constitueront la trame de notre accompagnement si nous travaillons ensemble.
Notre premier contact nous permettra d'apprendre à se connaitre mutuellement, avoir une première vision de votre projet et vous indiquer si nous sommes en mesure de vous accompagner.
Être en mesure de vous accompagner, cela signifie pour nous : vous aider pendant toute la durée du projet, et bien plus. De l'expression de besoin jusqu'à sa mise en conditions opérationnelles.
Mais il faut aussi admettre ses limites. Des contraintes spécifiques (technique, timing de réalisation, intégration d'un outil inconnu) peuvent faire que nous ne serons pas les plus à même de vous aider.
Le cas échéant, nous préférerons vous en informer de suite.
Selon nous, notre valeur ajoutée dans un projet va bien au-delà de son exécution.
Il s'agit de vous aider à identifier rapidement les pièges en s'appuyant sur notre expérience pour identifier les fonctionnalités disposant d'un excellent ratio valeur / difficulté de mise en place.
Nous sommes là également pour vous informer sur les usages et tendances de l'industrie du développement logiciel : les intégrations d'outils qui pourraient vous donner un avantage concurrentiel ou raccourcir les délais de développement, les bonnes pratiques en termes d'ergonomie et d'accessibilité, l'intérêt d'une technologie et tant d'autres.
Cette phase doit nous assurer à l'un et l'autre une chose très importante : nous travaillons ensemble dans une logique de collaboration, pas de subordination.
Bien entendu, il existe une relation contractuelle et le client a le dernier mot à l'heure des choix ; mais nous n'intervenons jamais comme de purs exécutants.
Les meilleurs résultats sont le fruit des meilleures collaborations. Chacun a son territoire de prédilection, qui correspond peu ou prou à son propre métier.
Pour confectionner un bon produit, il s'agit de croiser ces deux métiers. Pour cela, chacun devra s'aventurer en terre inconnue pour apprendre le métier de l'autre.
Il n'existe pas de solution miracle : pour réussir cela, il faut passer du temps ensemble pour comprendre les particularités d'un métier et en capter l'essence.
Il est important que cette démarche soit réciproque et que jamais l'un des deux acteurs ne considère le métier de l'autre comme une boîte noire.
Cette étape est sans doute l'une des plus complexes, car c'est pendant celle-là que nous sommes amenés à dire non. Pour un client, il est difficile de se voir opposer un refus, et c'est tout à fait normal.
Mais nous le faisons dans l'intérêt du projet, pour éviter de se lancer dans des réalisations trop ambitieuses, trop complexes ou basées sur trop d'incertitudes (ressentis, feeling, biais cognitifs…)
If you're not embarrassed by the first version of your product, you've launched too late — Reid Hoffman
Plus petit sera le périmètre, et plus rapide pourra être le lancement. L'important est de pouvoir apporter les fonctionnalités clés qui apporteront immédiatement de la valeur ajoutée aux utilisateurs finaux.
Pour cela, nous menons avec nos clients des ateliers de co-création (autrement appelés design sprint).
Le but de ces ateliers est de mener un processus de création de façon purement exploratoire, processus au terme duquel nous aboutissons à des maquettes et des hypothèses d'utilisation de l'application en question.
Il reste à éprouver ces hypothèses auprès des utilisateurs finaux en testant sur un ou plusieurs prototypes.
Cette étape de co-création, qui dure environ cinq jours, offre l'avantage d'être concrète et ludique tout en permettant une bonne prise en main et une bonne compréhension du métier et du besoin.
Vient ensuite la phase de développement. Pour cette phase, nous employons deux modes de fonctionnement distincts : soit nous livrons les développements toutes les X semaines, soit nous ne livrons que quand nous atteignons un ensemble fonctionnel cohérent (c'est à dire que nous ne livrons que quand N fonctionnalités sont prêtes).
Nous utilisons généralement le premier mode pour de l'amélioration continue ou des corrections, tandis que nous utiliserons le second dans le cadre d'un projet / sous projet.
Par projet, nous entendons ici un ensemble homogène de fonctionnalités, qui sont fortement interdépendantes. On peut par exemple considérer la mise en place de l'authentification d'une application comme un sous projet. Si vos utilisateurs peuvent s'authentifier (fonctionnalité 1) mais ne peuvent pas s'inscrire (fonctionnalité 2), ça n'a probablement pas grand intérêt : nous piloterons donc le projet d'un point de vue fonctionnel.
À l'inverse, une fois ce projet livré, vous pouvez vouloir faire en sorte que vos utilisateurs puissent s'authentifier avec Google. Dans ce cas, cela s'apparentera plutôt à de l'amélioration continue.
Au démarrage de chaque itération (temporelle ou fonctionnelle), nous allons devoir définir les ressources que nous souhaitons y affecter. En effet, les compétences ne sont pas nécessairement les mêmes selon les fonctionnalités à implémenter.
Une fois la fonctionnalité en place, il est indispensable de la tester, de la recetter. Pour chacune des fonctionnalités mises en place, nous vous encourageons vivement à mettre en place un cahier de recette.
Le cahier de recette offre plusieurs avantages :
Vous aurez peut-être le sentiment que cette tâche vous fera perdre un peu de temps au début du projet, mais elle vous en fera gagner énormément pour un projet dont la durée de vie est importante (> 1 an).
Une fois que l'application est développée et conforme aux attentes, il est temps de procéder à la mise en production.
Évidemment, c'est une phase qui aura été anticipée bien en amont, à la fois pour calibrer les besoins en dimensionnement des infrastructures, mais également la configuration des intégrations avec d'autres solutions, ou encore les garanties souhaitées (SLA, GTI, GTR…).
Un point important ici est de bien délimiter les responsabilités des uns et des autres. Il est généralement plus judicieux que le client n'ait qu'un guichet unique lorsqu'un problème survient, même si les équipes opérationnelles et celles de développement sont différentes.
Cela évite l'effet ping-pong, les premiers pouvant mettre les problèmes sur le compte des équipes de développement, et réciproquement.
Le second point est également crucial : ne partez pas en production sans filet !
Une fois l'application en production, vous devez savoir précisément :
Ces aspects sont importants, et requièrent une attention et une expertise à part entière. C'est notamment pour cette raison que nous avons créé une activité devops dédiée à ces sujets au travers de Plunge.
Ainsi, nous disposons d'un monitoring actif et nous mettons à disposition de nos clients (ou des clients de nos clients) une solution de Helpdesk permettant de remonter des dysfonctionnements (par ticket, e-mail, etc).
Ces outils permettent de suivre les incidents du moment où ils surviennent jusqu'à leur résolution et ce, même si plusieurs interlocuteurs (qu'ils soient côté technique ou côté client) doivent intervenir.
Notre guide sur la vision produit vous aidera également à vous projeter après la réalisation du projet. Car la mise en production d'un produit n'est pas une fin : ce n'est qu'un début, et un produit auquel on n'apporte aucune modification ni aucune amélioration est un produit mort.
Dans ce guide, vous verrez également comment définir (en amont) différents indicateurs qui vous aideront à mesurer le succès et la trajectoire de votre projet.
Bien entendu, une fois les différentes phases du projet terminées, nous continuons à vous accompagner dans la durée et en proximité.
N'hésitez pas à nous solliciter si vous avez la moindre question ou une simple demande de conseils : nous sommes là pour ça !