Le processus d'initialisation des projets chez Marmelab

Chez Marmelab, les projets commencent généralement par cinq jours d'initialisation. Ces cinq jours de travail se répartissent généralement sur deux semaines.

Ces cinq journées sont employées à construire conjointement avec le client un certain nombre de livrables, en préalable au démarrage des développements, indispensables au bon déroulement du projet ensuite.

• Objectifs
• KPI
• Risques
• Concurrence
• Personas
• Ubiquituous Language
• Parcours utilisateur
• Architecture technique
• Backlog
• Roles et responsabilités

Afin d'illustrer chacun de ces livrables, je prendrai comme exemple tout au long de l'article un vrai projet de développement, le projet TobaccoBot - un coach virtuel pour arrêter de fumer par SMS.

Définition des objectifs

Avant de parler de développement, il est important de clarifier les objectifs du client.

Pour cela, nous accompagnons nos clients dans l'écriture de leur vision du projet, en nous servant du template dit de "l'elevator pitch" :

Pour [les personnes ciblées par le produit/le service]

qui souhaitent [formulation du besoin des cibles],

notre produit est [description du type de produit/service]

qui [description du bénéfice majeur apporté par la solution].

A la différence de [la concurrence/la pratique actuelle]

notre produit permet de [éléments différentiateurs majeurs].

Voici par exemple la vision de notre projet "TobaccoBot".

Pour les fumeurs qui souhaitent arrêter de fumer, notre service est un coach personnel qui, en s'appuyant sur la psychologie comportementale, permet d'arrêter de fumer en 4 semaines. A la différence de la soixantaine d'applications Androïd sur le sujet, notre service fonctionne sans interface, évitant à notre solution de rejoindre les dizaines d'applications non utilisées sur les téléphones de nos utilisateurs.

De plus, l'utilisation du Business Model canvas permet de mettre à plat le contexte dans lequel se pose le projet qui nous est confié.

Cet outil, utilisé pour décrire de manière synthétique un projet de business, est très pratique pour se rendre compte de la maturité du projet du client.

Très didactique, les 9 cases qui le composent sont également un bon guide pour combler rapidement ses lacunes le cas échéant. Nous l'utilisons généralement pour challenger nos clients sur leurs choix stratégiques lors de la priorisation des développements qui nous seront demandés.

Voici celui de notre exemple. Il n'est pas très poussé car nous ne souhaitons pas en faire un business, mais il donne une idée assez claire de l'exercice.

Définition des KPI

Nous nous attachons à lister avec le client les critères chiffrés, que l'on nomme généralement des KPI (Key Performance Indicator en anglais) qui permettront de dire si, à chaque itération produit, on progresse dans la bonne direction.

Se poser la questions de ces indicateurs dès le début du projet force nos clients à se rattacher à des éléments concrets. L'exercice n'est pas évident - il est facile de tomber dans les vanity metrics qui ne sont pas vraiment représentatives du business model.

A cette étape, nous cherchons donc à définir entre deux et cinq indicateurs, et une valeur cible pour ces indicateurs à la fin de la période d'expérimentation initiale. Ces indicateurs doivent être mesurables dès les premières itérations ; cela implique de développer très rapidement des outils de mesure.

Voici les KPIs auxquels nous sommes parvenus pour TobaccoBot.

Nous voulons valider que nous pouvons conserver le contact avec l'utilisateur dans la durée, au travers d'un bot conversationnel. Nous voulons également valider que notre bot est efficace pour faire arrêter les gens de fumer. Les indicateurs de succès sont :

• sur un coaching de 4 semaines, nous souhaitons atteindre un taux de 50% d'utilisateurs qui terminent le programme.
• sur ces 50% ayant terminé le programme, nous souhaitons atteindre un taux de 50% d'arrêt du tabac.

Si les KPIs choisis dans notre cas sont pertinents, ils ont l'inconvénient d'être difficiles à mesurer (puisqu'il faut attendre 4 semaines). Dans ce cas, il convient de définir des objectifs intermédiaires, plus faciles à mesurer, comme:

• 5 jours après l'inscription, 90% des utilisateurs doivent avoir répondu dans la journée au SMS du matin

Identification des risques

De notre point de vue, il est important d'identifier les risques car ils sont une bonne clé de priorisation. En effet, si nous devons échouer, autant échouer le plus vite possible. Nous tenterons donc de lever les risques les plus importants le plus tôt possible. Ainsi, si l'un d'entre eux s'avère insurmontable, nous n'aurons pas trop dépensé de temps et de ressources avant de nous en rendre compte.

Les risques peuvent être de plusieurs ordres :

• des risques techniques, comme par exemple une vulnérabilité connue ou pressentie
• des risques fonctionnels, comme par exemple une très grande incertitude dans les hypothèses qui ont été suivies dans l'expression des besoins
• des risques de marché, comme par exemple le fait de devoir faire coïncider la sortie du produit avec un calendrier que l'on ne maîtrise pas, comme un salon professionnel

Nous prenons donc soin de les identifier afin de les intégrer à notre intervention, que ce soit sur le planning, le design technique, ou encore la validation des hypothèses.

Voici les risques que nous avons identifiés pour TobaccoBot :

• un risque technologique, car la technologie derrière les bots est loin d'être mature (notamment sur le traitement automatique du langage). Nous voyons circuler bon nombre de librairies à moitié finies, et certaines solutions gratuites aujourd'hui ne le seront peut-être plus demain.
• un risque économique, car l'envoi de SMS n'est pas bon marché, ce qui rend très périlleux l'emploi d'un modèle économique de type "freemium".
• un risque fonctionnel, car nous ne savons pas si cette méthode fonctionne réellement pour arrêter de fumer.

Forces et faiblesses vis-à-vis de la concurrence

Que ce soit grâce au benchmarking de la concurrence, ou lors de l'utilisation du Business Model Canvas, nous exerçons notre devoir de conseil : un développement informatique est l'aboutissement d'une démarche plus vaste. En nous souciant du contexte, nous sommes plus à même d'apporter des solutions en cohérence avec le projet, mais pas seulement. En effet, notre connaissance du secteur du web nous permet de faire gagner beaucoup de temps à nos clients.

Ce que l'on peut apprendre de l'analyse de la concurrence, ce sont les aspects du domaine qu'ils ont adressé, leur positionnement, mais également l'expérience utilisateur qu'ils ont mis en place, ainsi que le ton qu'ils emploient. Autant d'éléments qui permettent à nos clients de mieux se positionner sur leur marché.

Du point de vue méthodologique, voici comment nous réalisons notre benchmarking :

1. Nous définissons des critères de comparaison
2. Nous testons chacun des services concurrents selon ces critères
3. Nous rassemblons toutes les réponses et essayons de déterminer des groupes
4. Nous réduisons les critères à deux dimensions les plus significatives et dessinons un graphique

En ce qui concerne notre projet, vous avez pu le lire dans notre Vision, pour 60 d'entre eux, nos concurrents ont pris l'option de créer une application mobile. Nous avons décidé de nous démarquer en optant pour un fonctionnement sans interface, ce qui a quatre avantages :

• réduire la friction lors de l'installation (puisqu'il n'y en a pas)
• se démarquer des applications existantes pour arrêter de fumer
• ne pas nécessiter d'être sur plusieurs stores pour couvrir les différents OS existants
• ne pas rejoindre les 50 autres applications sur votre smartphone que vous n'avez ouvert qu'une fois depuis son téléchargement

Cependant, voici les applications qui ont la meilleure note sur le Play Store.

La plupart d'entre elles basent leurs moteur de motivation sur les économies potentielles à réduire sa consommation de cigarettes, et également sur l'accroissement (ou non) de son espérance de vie.

Rédaction des Personas

La technique des personas est utilisée par les personnes du marketing, les UX designers, ainsi que les développeurs informatiques.

Cela consiste à créer des fiches décrivant des utilisateurs type. Cela permet de "personifier" les différentes catégories de personnes qui vont utiliser l'application.

Cette démarche oblige nos clients, vous l'aurez compris, à se questionner à nouveau sur les destinataires de leurs services. En effet, la segmentation client a déjà été faite à l'étape du Business Model Canvas. L'idée ici est bien de transformer un segment en personne - étape supplémentaire dans le processus de maîtrise du sujet.

"Lorsque l'on s'adresse à tout le monde, on ne s'adresse à personne", ont coutume de dire les communicants. Connaître ses utilisateurs est essentiel : cela permet de cibler ce qui les rend spécifiques, et donc de pouvoir segmenter son marché en conséquence.

Un point important est de clarifier les objectifs de chaque persona, les tâches qu'il ou elle veut accomplir et que notre solution doivent faciliter.

La technique des personas permet de mettre en oeuvre une démarche centrée utilisateur.

Sur ce même blog, vous pouvez retrouver un article que nous avions dédié aux personas. Cet article est en anglais.

Voici les personas de notre projet :

Brice Brice est fumeur. Il veut arrêter de fumer. Ce n'est pas la première fois qu'il essaie : il a déjà essayé le patch et l'acupuncture, sans succès. Il a la quarantaine, un enfant. Il se rend compte que si fumer c'était cool quand il était plus jeune, ça l'est beaucoup moins aujourd'hui : en regardant sa fille, il se dit qu'il ne veut pas la quitter trop tôt. Il aime bien sortir et boire des coups avec les copains, c'est d'ailleurs, après son travail stressant (il est commercial), ce qui le fait fumer à nouveau. Son téléphone, un Huawei de 3 ans d'âge, est plein d'applications qu'il n'utilise jamais. Ce qu'il recherche, c'est de la motivation quand il en a besoin. Comme il ne veut rien laisser au hasard, il veut être accompagné par un professionnel. Il n'a jamais utilisé notre outil.

Thomas Thomas est responsable de la relation client chez TobaccoBot. A l'aise avec l'outil informatique, il travaille en sédentaire, sur un PC dernière génération avec un grand écran. Ce qu'il recherche, c'est maximiser les AARRR, les fameux cinq axes du growth hacking (Acquisition, Activation, Rétention, Revenue, Referral), et pour ça il a besoin de vues sur l'activité des clients pour qu'il sache déterminer d'où vient le fait que les utilisateurs abandonnent le programme. Thomas n'hésite pas à décrocher son téléphone.

Définition de l'Ubiquituous Language

Afin d'approfondir plus encore notre connaissance du domaine métier de nos clients, nous leur proposons de fixer ensemble le vocabulaire que nous allons être amenés à utiliser durant le projet. Nous définissons ce vocabulaire de la manière la plus précise possible, en veillant à lever toutes les ambiguïtés de langage avant que les quiproquos, ou les erreurs de compréhension ne s'installent.

Nous appelons ça l'ubiquituous language, terme provenant du Domain Driven Design (DDD).

Les termes que nous décrivons dans cette liste sont en anglais. En effet, le code étant en anglais, le fait d'avoir un langage commun basé sur des mots en anglais permet d'utiliser exactement le même terme à toutes les étapes. Cela évite également des interprétations lors de la traduction que devrait immanquablement faire le développeur.

Pour TobaccoBot, voici les termes que nous avons choisi d'expliquer :

• Subscription : Pour pouvoir participer au programme et recevoir les SMS, il faut que l'utilisateur s'inscrive. Cet évènement s'appelle subscription.
• Goals : Les objectifs sont personnalisés pour chaque utilisateur. Ils sont déterminés à partir du nombre de cigarettes fumées quotidiennement par l'utilisateur au démarrage du programme.
• Consumption response : Cela correspond au nombre de cigarettes fumées la veille par l'utilisateur. C'est la base de nos échanges par SMS avec lui. C'est également à partir de cette information que nous produisons des statistiques.
• Daily target : Déterminé à partir du calcul de l'objectif principal, l'objectif journalier permet au bot de répondre de manière appropriée à l'utilisateur.
• Content : C'est le contenu du message, variable, envoyé à l'utilisateur en réponse à sa consumption response.
• Message : C'est le message que, chaque jour, le bot envoie à l'utilisateur pour lui demander le nombre de cigarettes il a fumé la veille.

Modélisation du parcours utilisateur

L'exercice qui consiste à modéliser le parcours de l'utilisateur sur l'application qui va être réalisée nous permet d'accompagner nos clients dans la dure tâche de préciser leurs attentes, sous une forme visuelle.

C'est la première fois que l'on aborde la solution, puisque les étapes précédentes s'attachaient à définir le besoin. Le travail sur le parcours utilisateur représente bien souvent la plus grosse partie du temps que nous consacrons à la phase d'initialisation. Le résultat est généralement un ensemble de croquis de tous types.

Une fois le, ou les, parcours représentés visuellement, nous demandons à nos clients de nous décrire les éléments du parcours qui produisent le plus de valeur pour leurs utilisateurs - ce qui servira à la priorisation.

Dans le cas de TobaccoBot, voici comment nous avons initialement représenté le parcours utilisateur.

Une fois rentré dans le détail, ça donne le workflow de conversation suivant :

Conception de l'architecture technique

En parallèle de la solution fonctionnelle, nous nous attachons à proposer une solution technique.

Cette étape est l'occasion pour nous de prendre connaissance des contraintes techniques de nos clients, et donc d'adapter nos offres à leurs contraintes, ou parfois de leur proposer des solutions nouvelles.

Notre expérience s'exprime à nouveau dans la conception d'une solution en utilisant des outils et des composants cohérents entre eux, et alignés avec les fonctionnalités qui devront être développées. Le résultat est un schéma d'infrastructure qui liste les langages et outils utilisés pour chaque composant.

La plupart des architectures que nous délivrons aujourd'hui sont API-centric, et contiennent au moins deux applications : une application frontend qui peut être web ou mobile, et une application d'administration.

Pour TobaccoBot, c'est à peu près ça, mais il y a 2 applications frontend : une application web pour s'inscrire, et une application SMS pour les intéractions quotidiennes.

Transformation de l'expression des besoins vers un format agile

Dernière étape avant le lancement des développements, l'expression des besoins doit être "traduite" vers un format agile.

En effet, nous utilisons Scrum comme méthode de gestion de projet (des sprints de deux semaines, une équipe constituée de deux développeurs et d'un facilitateur, des "cérémonies", une démarche d'amélioration continue - pour plus de détails, veuillez lire notre article sur l'itération agile). Il convient donc de fournir aux développeurs une matière première "assimilable" par eux, en cohérence avec la méthode.

Ce format d'expression de besoins assimilable s'appelle, dans notre jargon, un backlog. Ce n'est ni plus ni moins une liste de fonctionnalités. Mais ces fonctionnalités doivent être formulées selon un formalisme particulier : les user stories.

Voici le format type d'une user story :

En tant que [persona] >je veux [réaliser une action] >afin de [obtenir un bénéfice]

Lui sont généralement associés des critères d'acceptation qui, en fournissant les conditions de validation, viennent compléter la description du besoin.

Ces critères d'acceptation peuvent suivre ce format type :

Etant donné [l'état du système], quand j'effectue [cette action] >alors j'obtiens [ce résultat]

Comme il s'agit de la matière première pour les développeurs, et qu'ils devront les utiliser pour écrire du code, user stories et critères d'acceptation sont écrits en anglais.

Backlog produit et Story Mapping

Les user stories sont écrites en se basant sur les personas, le parcours utilisateur et l'ubiquituous language.

Les user stories sont rassemblées dans un backlog produit. Comme nous travaillons généralement à distance avec le Product Owner, le backlog est sur Trello.

Une fois écrites, les user stories doivent ensuite être priorisées entre elles. La technique du story mapping permet généralement de faciliter cet exercice : en effet, en partant de la cartographie des parcours utilisateurs, on détermine le ou les chemins qui sont prioritaires par rapport aux autres, afin de faire un premier ensemble fonctionnel cohérent.

Voici une user story de notre projet TobaccoBot :

As Brice

I want to enter the number of cigarettes I have smoken yesterday

So that I answer to the bot day after day

Et voici un exemple de critère d'acceptation correspondant à cette user story :

Given I subscribed to the program

When I send an SMS to answer to the message of the bot with a number inside, written in letters or numbers, with or without additional words

The the Bot takes into account this number as the number of cigarettes I have smoken yesterday

Backlog de Sprint

Dernier exercice de préparation des besoins avant le démarrage des développements, la constitution du backlog de sprint est l'opération consistant à définir le périmètre des deux premières semaines de développement.

Ce nouveau travail de priorisation vient faire se croiser les priorités définies au niveau du backlog produit, et la capacité à faire de l'équipe.

Pour arriver à boucler cet exercice, il convient donc d'estimer les user stories. Ce travail est réalisé par les développeurs eux-mêmes, au moyen de la méthode du Planning Poker : les participants ont des cartes de valeurs qui facilitent la communication lors de l'estimation. Les développeurs estiment ainsi un plus grand nombre de travaux à réaliser dans un temps relativement court comparé aux techniques classiques d'estimation.

Les estimations sont réalisées en jours hommes pour chacune des user stories. Cela reste une estimation peu précise, qui donne un ordre d'idée général de la charge de travail nécessaire : les valeurs utilisées dans le planning poker sont 0,5 jours, 1, 2, 3, 5 jours.

On n'estime en général qu'une partie du backlog produit - celle que le product owner estime apporter le plus de valeur et/ou apporter le plus d'éclairage sur les incertidues.

Le travail du Planning Poker est long et fastidieux, puisqu'il faut en général une séance de 3 heures pour planifier assez de users stories pour remplir une itération (soit 20 jours de développement). C'est que pendant le planning poker, on parle scénarios d'implémentation, on itère avec le product owner sur le meilleur compromis coût/bénéfice. Une autre bonne raison de ne pas tout estimer est qu'une user story doit être assez détaillée pour être estimée, et cela nécessite pas mal de préparation. S'il fallait attendre que tout le backlog produit soit prêt à être estimé pour lancer le planning poker, alors la phase de préparation durerait des mois et pas deux semaines.

Une fois l'estimation d'une partie du backlog produit réalisée, il ne reste plus qu'à lister les user stories prioritaires à hauteur de la capacité à faire de l'équipe pour une itération (20 jours). On aboutit alors au backlog de sprint.

Cet exercice sera à refaire à chaque itération, pour planifier l'itération suivante.

Documentation de l'organisation du projet et planification des réunions

Sur le portail web du projet (habituellement sous Basecamp), nous listons un certain nombre d'informations relatives à l'organisation du projet :

• les rôles et responsabilités au sein du projet
• les contacts côté client et côté Marmelab
• la liste des outils, avec liens et codes d'accès

Nous calons également avec le client les prochains rendez-vous liés au projet, comme les dates de Planning meetings et Review meetings et rétrospectives pour les sprints à venir.

Conclusion

Cinq jours, ça peut paraître beaucoup, mais c'est très peu au regard de la somme d'informations qui est collectée et des documents qui sont produits. C'est aussi pour nous un passage incontournable : ces cinq jours marquent le début d'une collaboration, véritable socle sur lequel va pouvoir s'élever l'application que l'on va développer.

Durant cette période, nous réalisons parfois du coaching agile, ou plutôt de la formation sur comment tout cela marche, sur qui fait quoi, le tout illustré par nos expériences passées. Il n'y a pas de livrable pour tout ça, mais cela fait partie de notre apport au projet.

Enfin, même si nous le faisons rarement, nous recherchons l'approbation formelle du client à la fin de cette période. Si quelque chose ne va pas dans le projet, nous préférons nous en rendre compte avant d'écrire la première ligne de code.

Au terme de ces cinq jours, l'équipe technique est en mesure de démarrer son premier Sprint. Mais ça, c'est une autre histoire ...