C'est quoi le prochain truc à coder dans votre projet ?
La prochaine fonctionnalité à implémenter ?
Souvent, on lit que ce sont les retours des utilisateurs qui imposent les priorités. Malheureusement, quand on code directement ce que les utilisateurs veulent, il y a 2 risques :
Le premier est de rendre le système trop compliqué pour ceux qui le découvrent. En empilant les fonctionnalités, en ajoutant des sous-menus aux menus, des sous-formulaires aux formulaires, on va faire un outil moins accessible. Une usine à gaz.
Anciens utilisateurs : "Cool, ils ont codé ce qu'on voulait"
Nouveaux utilisateurs : "Woo, pas facile de comprendre comment ça marche. Par où commencer ?"
Le second risque est d'aligner le produit avec ceux des concurrents.
En se ralliant à la majorité des demandes, on se rapproche de ce que font (ou préparent) les concurrents. On sème les graines du "churn", en facilitant l'abandon futur de son outil au profit d'un autre.
Et si vous pensez "je suis tranquille, je n'ai pas de concurrent", c'est encore plus grave. C'est soit que vous n'avez pas de marché, soit que vous n'avez pas bien réfléchi. Par exemple, la principale alternative à votre super outil B2B, c'est peut-être Excel + le mail.
Alors comment choisir ce qu'on code dans les 15 prochains jours ?
Dans un podcast Artisan développeur (référence à la fin), Guven Urganci aborde une façon de classer chaque nouvelle fonctionnalité dans l'une des 4 catégories suivantes :
L'épicentre
La fonctionnalité contribue au minimum requis. Sans elle, le projet n'est pas utilisable ou pas commercialisable en l'état.
J'observe régulièrement des demandes classées à tort dans cette catégorie. D'ou l'importance de bien définir l'épicentre de son projet.
Neutralisateur
Une fonctionnalité de neutralisation réalise quelque chose de disponible chez les concurrents et qui risque de mettre votre produit hors jeu si vous ne le faîtes pas aussi.
Votre outil d'analyse de texte est génial, mais contrairement à xxx et yyy, il ne sait pas exploiter les documents au format pdf. Même si ce n'est pas nécessaire pour démontrer la valeur de l'outil (donc pas dans l'épicentre), c'est un critère perçu comme éliminatoire parce tous les autres le proposent.
Différenciateur
C'est ce qui colle à votre vision. Ce qui tranche avec l'existant, l'habitude. C'est là ou se loge l'innovation.
C'est soit :
- Une fonctionnalité que personne d'autre ne propose : grâce à un algorithme différent, une UX différente, une source de données jusqu'à présent inexploitée, un détournement de cas d'usage, ...
- Mais aussi le truc que vous choisissez délibérément de ne pas faire. Je crois beaucoup à cette innovation "soustractive". Enlevez le volant d'une voiture (→ autonome), le tabac d'une cigarette (→ vapotage), le formulaire de saisie du compte-rendu des appels client (→ transcription temps-réel dans le CRM)
Epicentre, neutralisateur, différenciateur. On résume ça sur un schéma :
Mais il y a une 4e catégorie.
La réduction de la dette technique
Parfois, il est urgent de ne pas coder une fonctionnalité en plus. Mais plutôt d'améliorer le code existant.
Parce que tout logiciel comporte au moins une fragilité technique sans conséquence à court terme, mais qui expose à un risque plus tard.
Il s'agit souvent d'une question d'architecture. L'organisation du code est mauvaise. Il manque de modularité. L'ajout d'un truc à un endroit provoque une défaillance imprévue ailleurs.
Cette inter-dépendance est le cauchemar des développeurs depuis que le code existe. Pleins de solutions pseudo-miracles ont été essayées.
La mode actuelle est aux architectures micro-services. Comme le résume Arnaud Lemaire dans sa conférence "Un monolithe microservices ready", c'est rarement le découpage en petits paquets qui transforme par magie le tas de boue que l'on avait construit.
On a juste des tas de boue plus petits, assortis de pleins d'autres problèmes qu'on avait pas avant.
La réduction des dépendances dans le code est un principe premier, qui nourrit pleins de méthodes et de design patterns. Le temps à y consacrer est un investissement pour la pérénité du code.
Le choix est forcément collectif
Le classement de chaque demande dans ces 4 catégories permet d'y voir plus clair sur leurs enjeux.
Mais classer n'est pas choisir. On imagine bien toute la difficulté à arbitrer entre un nettoyage du code sans plus-value immédiate pour les utilisateurs (en êtes-vous si sûr ?) et un différenciateur auquel on pense depuis des semaines.
Lorsqu'on a les yeux rivés sur le nombre d'utilisateurs, le neutralisateur possède lui aussi un beau potentiel d'attraction.
L'organisation d'un projet de développement logiciel doit identifier le décideur, mais aussi le processus. La voix du staff technique doit porter autant que celle des autres.
Une fois la décision prise, il ne suffit pas de déplacer une carte dans un trello, ou d'affecter une tâche Jira.
Les équipes doivent comprendre pourquoi c'est prioritaire. En expliquant le sens de la décision, il va naturellement transparaître dans la qualité du code.
Pour en savoir plus :
- L'épisode "Développeur de produit avec Guven Urganci (noCRM.io)" du podcast Artisan Développeur https://podcast.ausha.co/artisan-developpeur/developpeur-de-produit-avec-guven-urganci
- la conférence d'Arnaud Lemaire "Un monolithe microservices ready" https://www.youtube.com/watch?v=F8C_iPGhHoI
- une réflexion sur les "principes premiers" : https://remihuguet.dev/blog/2021/06/12/relativite-logiciel-principes/
