Le développement de logiciels manque d’un processus prévisible et reproductible
La création de logiciels est complexe et difficilement prévisible. Nous pouvons essayer de la gérer, mais contrairement à la fabrication d’un produit physique tel qu’un gadget, où les processus sont affinés et optimisés jusqu’à ce qu’ils soient à toute épreuve, le développement de logiciels résiste à ce niveau de prévisibilité.
Lorsque vous construisez quelque chose de physique, vous savez à quoi vous attendre. Chaque widget sort de la ligne à l’identique du précédent. Vous affinez les choses, vous ne réinventez pas la roue à chaque fois.
Les logiciels ne fonctionnent pas de cette manière. Chaque projet semble être le premier de son genre, parce qu’il l’est à bien des égards. Bien sûr, nous avons établi des pratiques et des cadres de référence, mais il s’agit davantage de lignes directrices que de véritables règles. Les développeurs débattent souvent des méthodes de mise en œuvre, sans véritable consensus, parce qu’une grande partie du processus consiste à résoudre des problèmes de manière nouvelle et unique.
Dès que vous essayez de définir la « meilleure » méthode, vous êtes confronté à la réalité : chaque solution peut engendrer des défis entièrement nouveaux, ce que certains appellent des « inconnues inconnues ».
Ce niveau de variabilité signifie qu’aucune feuille de route ne fonctionne à tous les coups, et c’est pourquoi les logiciels restent une cible en constante évolution. C’est un peu comme essayer de construire un puzzle dont une poignée de pièces sont incorrectes ; vous ne savez pas quand ni où les choses vont mal se passer. C’est cette incertitude inhérente qui fait du logiciel une bête si complexe à transformer en un processus reproductible et prévisible.
Il est pratiquement impossible d’estimer avec précision les délais de réalisation d’un logiciel
Donner un devis de livraison pour un projet de logiciel ? C’est le début des problèmes. Pour aller droit au but, il est pratiquement impossible de prévoir avec précision un délai. Lorsque les développeurs commencent un projet, ils ne connaissent pas nécessairement toutes les péripéties qu’ils vont rencontrer. Parfois, la véritable solution ne devient évidente qu’après plusieurs séries d’itérations – et seulement après avoir emprunté quelques voies sans issue.
Les délais ne sont pas dépassés en raison d’un manque de compétences ou de planification. Ils sont manqués parce que l’innovation ne suit pas un calendrier.
Les clients professionnels ne veulent pas entendre cela. Ils veulent une date. Les équipes de développement font donc de leur mieux pour proposer une estimation. Tout le monde comprend les enjeux, mais la pression exercée pour fixer une date limite conduit à des dates qui sont rarement exactes, et parfois spectaculairement erronées.
Cela tient plus à la nature du travail qu’à des attentes mal alignées. Vous pouvez essayer de tout prévoir trois mois à l’avance et vous en approcher. Mais il est fort probable que vous vous trompiez.
Les besoins des entreprises et les attentes des clients sont en contradiction avec les réalités du développement
L’aspect commercial des logiciels est toujours un peu en décalage avec les réalités du développement. Souvent, les entreprises vendent des idées, des fonctionnalités qui n’existent pas encore mais qui semblent intéressantes lors d’une réunion de présentation. Les clients entendent ces promesses et s’attendent à ce qu’elles soient livrées en temps voulu.
La demande de capacités futures peut rapidement devenir délicate. Les équipes de développement se voient imposer un calendrier basé sur ce qui a été promis, et non sur ce qui est techniquement faisable. Ce qui se passe ici, c’est un désalignement dans la façon dont chaque partie comprend le processus. L’entreprise a besoin de certitudes et d’objectifs, tandis que les clients attendent un suivi.
D’un point de vue technique, cependant, ces promesses donnent l’impression de s’aventurer en terrain inconnu. Il s’agit d’une tension permanente : les développeurs ne peuvent pas garantir un calendrier parce que le travail est très fluide, mais l’entreprise a besoin de cette garantie pour satisfaire les clients et les parties prenantes. C’est un exercice d’équilibre difficile, qui conduit à des relations tendues lorsque les dates ne sont inévitablement pas respectées.
Pour respecter les délais, il est inévitable de faire des compromis sur la qualité, les caractéristiques ou le calendrier.
Le triangle classique du développement de logiciels dit que vous pouvez avoir la qualité, la vitesse ou les fonctionnalités, mais pas les trois à la fois.
En général, les caractéristiques et les calendriers l’emportent, ce qui signifie que la qualité finit souvent par être le sacrifice « facile ». Pourquoi ? Parce que c’est le moins visible. Une fonctionnalité retardée ou manquante est immédiatement remarquée par les clients, mais les problèmes de qualité peuvent rester cachés juste le temps de livrer le produit. Il est tentant de respecter un délai en rognant sur quelques aspects, même si cela signifie que les bogues passent.
Ce que l’on constate souvent ici, c’est que la qualité est reportée à des correctifs postérieurs au lancement ou à des « versions ponctuelles ». Cela ne résout pas le problème, mais le déplace vers le bas de la chaîne. Le logiciel peut arriver sur le marché avec moins de retards, mais il arrive aussi avec des fissures cachées qui devront être réparées un jour ou l’autre.
Ainsi, alors que le projet semble avoir été livré dans les délais et avec toutes les fonctionnalités promises, le coût se fait sentir plus tard, lorsque les développeurs doivent rattraper leur retard en matière de qualité. Cette approche axée sur les retards aboutit généralement à une version du logiciel qui « fonctionne » techniquement, mais qui finit par accabler l’équipe de corrections de bogues après que les utilisateurs ont signalé des problèmes.
Les développeurs et les équipes d’assurance qualité supportent le fardeau des défauts de processus
Lorsque la qualité est sacrifiée pour respecter un délai, les développeurs et l’assurance qualité finissent par porter le fardeau après le lancement. Ce sont eux qui subissent les conséquences immédiates des raccourcis pris au début du projet. Les clients constatent les problèmes et les développeurs sont chargés de les résoudre, ce qui signifie qu’ils passent du temps à corriger ce qui, idéalement, aurait dû être fait avant le lancement.
C’est un cycle ingrat. Parce que les équipes de développement et d’assurance qualité sont soumises à la pression d’une livraison rapide, elles prennent souvent des raccourcis. Malheureusement, ce sont elles qui paient le prix lorsque les choses tournent mal.
Lorsqu’un logiciel parvient aux utilisateurs dans un état imparfait, la réalité est que l’équipe qui en est à l’origine se démène déjà pour gérer la prochaine version, rattrapant sans cesse un niveau de qualité qui aurait pu être atteint plus tôt si elle avait disposé de plus de temps. Ce cycle – pression pour livrer rapidement, sacrifice de la qualité, puis résolution des problèmes par la suite – maintient les équipes logicielles dans un cercle vicieux. Ce n’est pas un défaut dans leurs compétences ou leur dévouement. C’est le résultat naturel d’un environnement de développement régi par des délais qui ne correspondent pas à la nature imprévisible et innovante des logiciels.
Dernières réflexions
Voici donc la question que chaque dirigeant doit se poser : préparez-vous vos équipes à construire quelque chose d’authentiquement génial, ou vous contentez-vous d’attendre la prochaine échéance ? Chaque fois que vous sacrifiez la qualité à la rapidité, vous portez atteinte à la confiance et à l’expérience client.
Imaginez qu’au contraire, vous puissiez créer une culture où l’innovation a de l’espace pour respirer, où les développeurs ont le temps de bien faire les choses et où les clients reçoivent des produits qui dépassent réellement leurs attentes. Réfléchissez bien : que pourriez-vous faire pour votre marque si vous investissiez réellement dans l’intégrité de ce que vous construisez ?
