Nous aimons obtenir rapidement une réponse à une question, accéder à un produit ou à un service. L’accès rapide à un produit peut même nous amener à réaliser un compromis tant sur le prix que sur la qualité, avec… satisfaction. C’est par exemple le cas, lorsque nous achetons dans une supérette, que nos amis québécois désignent si joliment comme un dépanneur. Le produit ne sera peut‑être pas exactement notre produit habituel, le prix sera 30 % plus élevé et, pourtant, cet accès immédiat peut nous apporter une grande satisfaction.
Photo : Nicolas Éliard
Il est à noter que ce besoin de réactivité n’est pas l’apanage d’une société d’enfants gâtés. La personne en détresse vitale, en attente de l’arrivée du SAMU, peut en témoigner. À l’inverse, une fonctionnalité permettant de réaliser des ventes à un salon, qui arrive après la fin du salon, n’aura strictement aucune valeur.
La réactivité a une valeur intrinsèque, sans corrélation directe avec celle de la fonctionnalité livrée.
Face à ce besoin de réactivité, le réflexe est souvent prédictif : élaborer un planning. Cela rassure. En tout cas, jusqu’à ce que le planning se révèle, comme tous ces honorables prédécesseurs, parfaitement foireux. Car utiliser des outils prédictifs dans un contexte imprévisible est aussi pertinent que manger sa soupe à la fourchette. Ce n’est pas juste inutile ; par le temps qui lui est consacré, la planification nuit à la réactivité.
Bien entendu, nous pouvons accroître la taille de l’équipe. Si, sur le long terme, cette stratégie peut s’avérer payante, sur le court terme, elle est vouée à l’échec. Car l’énergie nécessaire pour intégrer un développeur dans l’équipe ne sera pas consacrée à développer des fonctionnalités. Sans compter que cette approche sera rapidement limitée par le budget, qui est rarement extensible à l’infini.
La dernière option serait donc de mettre la pression sur les équipes, notamment via des deadlines (ou limites mortelles). Au‑delà des aspects moraux, les conséquences réelles vont rapidement osciller entre des bugs en pagaille et le départ des membres les plus performants de l’équipe.
Si la réactivité est essentielle, ni la planification, ni l’accroissement de l’effectif, ni la pression ne semblent apporter de solutions viables et pérennes.
La question que nous pouvons donc nous poser est : « Comment améliorer la réactivité d’une équipe de développement logiciel à moyens constants, c’est-à-dire à budget constant et sans accroître la charge de travail ? »
Nous essaierons de proposer des pistes en ce sens dans de prochains articles.