Au fil des années, j'ai travaillé avec beaucoup de gens différents et traversé plusieurs cycles de développement de produit. Ce qui me surprend encore, c'est à quel point les organisations oublient vite, et à quelle fréquence les mêmes schémas reviennent.
Ce n'est que mon point de vue, et je peux me tromper sur certains détails. Mais c'est la boucle que je continue de voir.
Les premières fonctionnalités et l'élan
Au début de ma carrière, la majorité des demandes venaient de partenaires et d'affiliés. On écoutait rarement les clients directement. Notre objectif était surtout de plaire aux gens qui faisaient la promotion de nos produits.
On construisait des fonctionnalités selon ce que d'autres pensaient se vendre. Les revenus montaient, alors il y avait peu de pression pour remettre ces hypothèses en question. Pendant un moment, l'approche semblait fonctionner.
Ajouter de la structure et remettre en question
Plus tard, l'entreprise a adopté des pratiques agiles et mis en place une définition de prêt. Les demandes étaient examinées et remises en question par le produit et l'ingénierie avant d'être mises en œuvre.
Si quelque chose n'était pas clair, on freinait et on demandait plus de contexte. On montait aussi des MOC et des POC, qu'on revoyait avec les parties prenantes avant d'itérer.
Ce n'était pas parfait. Les parties prenantes étaient souvent prêtes à livrer tôt des prototypes, et il fallait insister pour faire le tri avant la production.
Livrer sans s'arrêter
Les fonctionnalités restaient encore guidées par les demandes des partenaires, mais aussi par des idées internes. On avait l'impression de savoir ce dont les utilisateurs avaient besoin.
On livrait sprint après sprint, puis on passait directement à la demande suivante. On s'arrêtait rarement pour valider si ce qu'on avait bâti créait réellement de la valeur. Comme les revenus restaient solides, cet écart demeurait surtout invisible.
Quand les revenus ont ralenti
Cette confiance a tenu jusqu'à ce que les revenus ralentissent. La première réaction a été une restructuration : des équipes ont été brassées, certaines personnes sont parties, et des idées qui étaient auparavant acceptées ont soudainement été remises en question.
Une fois la turbulence immédiate passée, une autre conversation a commencé.
Mesurer la valeur
On a décidé que les idées devaient avoir des plans de mesure plus clairs. Le ROI n'était pas un concept nouveau, mais planifier comment valider l'impact après le lancement ne faisait pas partie des habitudes.
Une équipe a été créée pour imposer la mesure et le suivi. La transition n'a pas été facile. Les gens avaient l'impression d'être bloqués, et les partenaires avaient l'impression d'être ignorés.
Mais pour le travail qui passait par ce processus, on comprenait mieux les résultats. Certains projets ont dépassé les attentes. D'autres ont apporté peu de valeur et ont été retirés. D'autres encore amélioraient l'expérience utilisateur, mais rapportaient moins que ce qu'ils coûtaient, ce qui forçait des décisions explicites sur les compromis.
Résister à la lourdeur
Cette phase a bien fonctionné pendant un certain temps, puis le pendule a bougé à nouveau. Le processus était perçu comme trop lourd, et la question dominante est devenue : pourquoi les unités d'affaires ne peuvent-elles pas décider directement de ce que l'ingénierie doit construire?
Des couches ont été retirées, des équipes ont été brassées, et les développeurs se sont rapprochés des unités d'affaires. Le temps d'ingénierie est devenu plus difficile à justifier à moins qu'une demande soit présentée comme obligatoire.
Je ne pense pas que tout dans ce changement était mauvais. Le modèle précédent créait bel et bien de la friction. Mais la mesure est devenue sélective. On mesurait souvent les projets dont on se méfiait, alors que les projets poussés par l'entreprise passaient avec moins de questions.
De retour à la case départ
Ce changement a eu un effet direct sur la feuille de route en ingénierie. Le travail qui avait autrefois sa place dédiée devait maintenant rivaliser pour attirer l'attention et être justifié comme urgent.
Quand les revenus se sont améliorés, un peu de cet espace est revenu, mais pas au niveau d'avant. Quand je regarde aujourd'hui, le schéma me paraît encore familier : moins de projets sont mesurés de bout en bout, plus de décisions reposent sur l'intuition, et l'investissement en ingénierie reste difficile à défendre.
Je ne sais toujours pas si ce schéma est inévitable ou si c'est simplement une habitude qu'on répète. Ce qui a changé pour moi, c'est que je cherche maintenant moins un modèle permanent qu'une certaine continuité : ce qu'on mesure, ce qu'on cesse de mesurer, et ce qu'on décide de retenir quand la pression change.
- Patrick