Design produit, roadmap et estimations

J’ai déjà écrit sur ce sujet, il y a longtemps. Mais avec d’autres mots, avec moins d’expérience. Et je recommence, car à travers les équipes que j’ai rencontrées et avec lesquelles j’ai travaillé, ça semble toujours être un point de friction majeur, alors que c’est vraiment dans l’intérêt de tous, ingénieurs, PMs et tous les autres.

Ne vous compliquez pas la vie

Avant d’aller plus loin, soyons clairs sur un point. Personne ne vous demande de dire précisément à quelle date et heure vous livrerez une fonctionnalité donnée. Pourtant, il est essentiel que, dans le temps et au sein d’une équipe donnée, une certaine prévisibilité apparaisse, et que vous évitiez soit de procrastiner soit de livrer trop tôt.

Vous avez bien lu ; les estimations ne consistent pas tant à répondre à “dans combien de temps pourrons-nous dire à nos clients que nous avons résolu tel ou tel problème ?” qu’à “combien d’efforts sommes-nous prêts à mettre dans ça avant d’être satisfaits du résultat et de passer à l’élément suivant ?”.

Il s’agit de trouver le bon équilibre face à toutes sortes d’obstacles, d’équipes changeantes et de défis business changeants, et d’être humain.

Fait : sur ce dernier point, en France, oubliez une release majeure en mai ; c’est une illusion de croire que ça arrivera jamais. Que ce soit à cause des nombreux jours fériés ce mois-là, ou simplement parce que vos équipes sont faites d’humains qui méritent d’être traités comme tels, de se déconnecter, de prendre soin d’eux-mêmes et de leurs proches, il peut y avoir tellement de raisons pour lesquelles vous avez plutôt intérêt à s’adapter au changement plutôt que de suivre un plan.

Maintenant, même si je suis contre les dogmes, ce qui suit devrait être considéré dans son intégralité. Ne faire qu’une petite partie et dire ensuite “ça ne marche pas” n’est pas acceptable. C’est un paradigme.

D’abord : avez-vous besoin d’estimations ?

Une nouvelle occasion pour moi de citer Donald Knuth (en partie) : “[…] l’optimisation prématurée est la source de tous les maux […]”. J’affirmerais que si vous êtes dans une entreprise en phase précoce, encore en train de découvrir ce que vous voulez vraiment construire et pourquoi, et encore en train de constituer votre équipe, vous pouvez passer.

Il existe des méthodologies très décentes et éprouvées qui ne nécessitent pas vraiment d’estimations, comme l’Extreme Programming. Ça convient particulièrement quand on travaille avec moins de 5 développeurs, et d’autant plus si ces développeurs ont acquis une certaine séniorité dans des business orientés produit.

Comme je l’ai rapidement mentionné, le besoin d’estimations découle du besoin de prévisibilité et, bien sûr, de communication. Il s’agit de dire aux gens autour de vous quand ils peuvent espérer obtenir une solution à leur problème. C’est juste, non ?

Pensez à l’un quelconque de vos outils. Qu’il soit cassé ou non fonctionnel, et que vous ne soyez pas la personne qui peut le réparer. Mettez de côté la frustration ; vous avez simplement une liste de choses à faire et devez prioriser. Que ferez-vous ensuite, jusqu’à ce que votre outil soit fonctionnel ? Car la tâche que vous devez accomplir avec lui reste votre priorité absolue, et pourtant vous ne resterez pas à ne rien faire. Aurez-vous le temps de faire A, B et C ? Ou juste C ?

Eh bien, c’est précisément ce qui se passe dans l’esprit de votre client. Et dans l’esprit de votre équipe support. Et dans l’esprit des commerciaux (bien que ça ne devrait pas être dans ces esprits-là en réalité : nous devrions toujours vendre sans promettre ce qui arrivera dans le futur, non ?).

Comprendre ce qu’est une estimation

Quand j’ai travaillé pour la première fois avec Scrum, j’ai travaillé en tant que PM avec l’équipe d’ingénierie pour transformer l’organisation existante dans son ensemble. L’entreprise existait depuis plusieurs années et était “plus ou moins” à l’aise avec une méthodologie Waterfall. Sauf qu’elle faisait face à des pratiques et des outils émergents (youpi, Git !). Nous avons rapidement commencé à travailler sur des “estimations”, à peu près comme décrit dans l’article que j’ai cité ci-dessus.

Plus précisément, nous parlions en “points de complexité”. Il y a de nombreuses options là, mais je trouve celle-ci comme la plus efficace. Et j’ai une opinion forte sur certaines autres options.

Un point clé que nous avons dû évangéliser en interne : il n’y a pas de taux de change entre les points et les heures-homme. Pour revenir à mon introduction : c’est un fait qu’aucun développeur ne sera jamais capable de dire en combien de minutes ou d’heures il développera quelque chose. Quoi qu’un autre développeur “senior”, ou le CEO, puisse jamais croire. Prenez en compte les obstacles. Ajoutez la dette technique. Plus le briefing changeant. Et ce crash en production (eh bien, c’est encore un de ces obstacles).

La première et la plus importante chose à garder en tête, c’est qu’une estimation, quelle que soit la métrique utilisée, ne devrait jamais être une valeur absolue.

À plus grande échelle : une estimation ne devrait jamais se résumer à “combien de temps me faudra-t-il pour écrire les lignes de code”. Surtout dans un monde où l’IA pourrait en faire une partie à votre place. Elle devrait inclure l’ensemble du processus de conception technique et de livraison. De “OK, qu’est-ce que je veux construire maintenant ?” à “Hé les amis, les métriques d’usage arrivent !”.

Commencez à donner des chiffres, ne vous inquiétez pas

La seule chose qu’on peut dire, c’est : est-ce que cette chose est a priori (gardez ça en tête) plus complexe ou compliquée à construire que la chose précédente que nous avons construite ? Avons-nous construit quelque chose de comparable dans le passé ?

Ensuite, vous voudrez effectivement noter ou mettre un chiffre, simplement parce que ça marque un point de référence. La première fois que vous le faites, cette métrique sera en réalité la meilleure et la pire estimation que vous puissiez donner. Mais peu importe, car : 1. vous ne serez probablement jamais précis à 100% 2. c’est un processus itératif, vous ferez mieux la prochaine fois.

Autre considération clé : divisez pour régner. Vous pouvez probablement obtenir une estimation décente pour la mise à jour de la couleur d’un bouton sur une page donnée de votre application. Construire un nouveau moteur de recherche dans votre produit est certainement une entreprise bien plus grande.

Décomposez ça en parties plus petites. Chaque tâche, story ou développement devrait vous mener à un livrable indépendant et testable. Idéalement, quelque chose que vous pourriez pousser en production et laisser des utilisateurs en bénéficier ou en donner leur avis.

C’est là qu’utiliser la suite de Fibonacci (1, 2, 3, 5, 8, 13…) dans les estimations devient pratique, surtout pour estimer la complexité de la livraison d’une fonctionnalité. Tout ce qui est en dessous de 5 devrait être “simple”, prévisible, comme changer la couleur d’un bouton. Dès que vous commencez à penser en termes de fonctionnalités, vous voudrez probablement le noter entre 8 et 21. Notez que la suite de Fibonacci augmente très vite en valeurs : ça reflète très bien l’incertitude qui apparaît quand la complexité de ce que vous voulez construire augmente.

Une considération encore plus importante : les valeurs dépendront toujours de votre équipe, du logiciel que vous construisez, de la stack technologique et de tellement d’autres paramètres. Si vous travaillez avec deux équipes qui possèdent deux parties différentes du même portefeuille produit d’une entreprise, elles pourraient très bien donner des valeurs différentes à des développements assez similaires. C’est normal ! C’est une partie du deal. Encore une fois : les valeurs absolues n’ont pas d’importance.

Itérez

Vous avez donc planifié et terminé votre premier sprint ou cycle de développement. Devinez quoi ? Vous avez lamentablement échoué à estimer. Vous n’avez peut-être même pas livré certaines des fonctionnalités du tout, et avez à peine commencé à y réfléchir.

C’EST OK !!!

Tout comme vous avez pris un premier coup pour quantifier la livraison d’une fonctionnalité, puis déterminer si les autres étaient plus complexes, moins complexes ou équivalentes, vous estimerez les prochaines fonctionnalités à livrer en vous basant sur celles-là.

Ça prendra quelques cycles de livraison, mais vous convergerez finalement.

Tous ceux qui réussissent à estimer ont essayé

Comme je l’ai mentionné au début : c’est tout un paradigme.

Ce n’est pas déterministe, puisque ça dépend de toute façon des humains et des facteurs externes sur lesquels vous n’aurez aucun contrôle.

Pourtant, dans le temps et en appliquant les concepts fondamentaux de l’agile (oui, lisez-le, à nouveau si vous ne l’avez pas fait depuis un moment), vous gagnerez en prévisibilité. Et donc en clarté de votre communication avec le monde extérieur.

Petite fierté : après un an dans cette équipe avec laquelle j’ai travaillé pour la première fois en Scrum, nous avons réussi à planifier la livraison d’un tout nouveau produit dans un délai de 9 mois, avant même de déposer la première ligne de code, et le produit a été livré juste à temps. Est-ce qu’il ressemblait exactement aux premières ébauches ? Non. Avait-il toute une roadmap encore devant lui ? Oui. Résolvait-il les problèmes des utilisateurs ? Oui. Objectif atteint. C’est possible, même si c’est difficile et incertain.

Ce qui est clé dans cette histoire, c’est que tout au long du développement et de la livraison, nous pouvions prendre des décisions et des compromis pour déterminer jusqu’où nous voulions aller dans le développement d’une fonctionnalité spécifique, ou simplement si nous voulions la développer. À chaque fois, nous revenions à “est-ce que ça contribue directement à la valeur que nous voulons livrer ?”, “voulons-nous viser un MVP ou voulons-nous passer plus de temps à peaufiner ceci plutôt que cela ?”. Nous étions conscients de l’impact de nos choix, dans une certaine prévisibilité statistique.