Comment éviter les échecs de vos projets numériques

Les mauvaises nouvelles annonçant les échecs lamentables de nouveaux produits logiciels dominent les médias. Ça nous fait questionner: peut-on réellement faire confiance aux solutions numériques de nos jours? Pourquoi tout ça arrive-t-il? Selon mon expérience, il y a trois grands problèmes d’un projet informatique: les objectifs instables, les bogues, et la dette technique.

Que peut-on faire pour aborder ces difficultés et redresser la confiance publique? Dans cette série d’articles, je vous partage mon opinion, en abordant trois pistes de solutions techniques et non techniques: le budget de temps de production, la gestion des erreurs et exceptions, et la surutilisation des ressources.

Image : xkcd

Budgéter le temps de production

Le premier éléphant dans la pièce est le temps de développement. Le développement informatique a une mauvaise réputation pour ses dépassements de temps et coûts. Mais qu’est-ce qui cause ces dépassements de temps? Les problèmes récurrents sont les changements des objectifs du logiciel (« moving goalpost »), la résolution des bogues, ainsi que la dette technique et sa correction - aussi appelé « refactoring ».

Moving goalpost

Le moving goalpost est une conséquence malheureuse du développement Agile. Cette approche itérative sur le produit, où l'équipe communique régulièrement avec le représentant du client afin de s'assurer que le produit répond bien aux besoins d'affaires. La force de la méthodologie AGILE est de permettre à l’équipe de développement de réagir aux besoins dynamiques du client et à ses commentaires. Toutefois, il y a des situations où le client ou son représentant vont changer d’opinion par rapport à des fonctionnalités déjà existantes. Ces demandes de changement ou ajout de fonctionnalités ont une conséquence: chaque réécriture et chaque fonctionnalité supplémentaire ajoute au temps de développement, ce qui immanquablement mène au dépassement des estimations de temps initiaux.

Afin d’éviter cette problématique, il est donc impératif qu’en tant que client ou en tant que chargé de projet de produire un document de spécifications pour le logiciel désiré tôt dans le processus et s’y tenir le plus possible. Ce n’est peut-être pas évident, mais il faut que l’équipe se discipline à le faire, si elle ne veut pas faire face aux conséquences de retard ou dépassement de coûts.

Les bogues

Il est important de comprendre que chaque fois qu’un bogue est découvert, c’est du temps additionnel qui doit être attribué pour le corriger. Mais pourquoi les bogues surviennent? Il est presque impossible pour un logiciel d’être 100% sans erreurs. La probabilité d'occurrence d’un bug dans une fonctionnalité est proportionnelle à la complexité et la taille d’un projet de manière linéaire dans le meilleur des mondes, et exponentielle si le projet doit être produit à grande vitesse. Les bogues peuvent survenir à tout moment durant la création du produit, mais plus ils sont découverts tard, plus ils sont coûteux à réparer, car la complexité de la cause et des impacts du bogue ont le potentiel d’être plus grands.

Dans le monde d'aujourd'hui, les besoins d’affaires demandent aux équipes de développement de produire vite des produits numériques. Les conséquences: plus on demande à l’équipe de produire rapidement, moins de temps sera alloué à la vérification du code et l’équipe aura moins de temps pour effectuer des tests. Si AGILE est une opportunité pour les développeurs d’être à l’écoute des besoins d’affaires, ce doit aussi être une occasion d’écouter les commentaires et les recommandations des experts pour produire du travail de qualité.

Un processus rigoureux de revue de code et de tests est aussi recommandé afin de tuer les bogues dans l'œuf, avant qu’ils ne contaminent l’environnement de développement. Je vous recommande également d’investir dans une bonne équipe de testeurs. Un bon testeur qui trouve des bogues tôt dans le cycle de production et qui documente bien les problèmes peut économiser beaucoup de temps à l’équipe de développement pour réparer lesdits problèmes.

Pour vous aider, prenez en compte le temps nécessaire pour corriger les bogues dans les estimations initiales du projet, implémentez des garde-fous dans le processus, et ayez une équipe solide de testeurs afin de limiter l’impact des bogues.

La fameuse dette technique

Deux éléments peuvent contribuer à la dette technique: la complexité de la base de code et les contraintes de temps. Bien que ces deux problèmes apparaissent distincts, il faut comprendre que les contraintes de temps augmentent la complexité du code. Pourquoi? Une équipe de développement pressée ne prendra pas le temps d'abstraire correctement le code et de le généraliser, ce qui aurait permis de plus facilement comprendre ce qui se passe et de réutiliser le code déjà existant. Ils ne prendront pas non plus le temps de produire des tests ou de documenter le code produit. Tous ces raccourcis, bien que bienvenus par le client et le chargé de projet qui voient le projet aller de l’avant rapidement, se transformeront en ralentissements majeurs par la suite.

Une nouvelle développeuse se joint à l’équipe? Ça lui prendra plus de temps pour comprendre le code et atteindre une bonne vélocité. Un bogue apparaît? C’est plus difficile de comprendre ce qui le cause et le corriger. Cette correction aura aussi plus de risques de causer des effets secondaires non désirés ailleurs dans le produit. Ajouter une nouvelle fonctionnalité prend aussi plus de temps, car il faut passer plus de temps pour trouver l’endroit et la manière adéquate de l’ajouter à la structure sans la faire s’écrouler.

La dette technique a un remède radical: le remaniement (« refactoring »). C’est un remède douloureux et souvent long qui implique de prendre du temps pour comprendre dans son ensemble la base de code (qui peut avoir atteint une complexité critique), développer des tests, deviser un plan de remaniement, puis réécrire une portion substantielle du produit de la bonne manière. Évidemment, cette solution n’est jamais populaire auprès des décideurs. Prendre plus de temps pour retravailler un produit qui fonctionne déjà? Absurde! Il faut toutefois comprendre que ce remède radical permet souvent de gagner du temps sur le long terme, car la dette technique ralentit exponentiellement le développement.

Il vaut donc mieux éviter de tomber dans ce piège dès le début. Comment l’éviter? Des conventions de programmation claires et appliquées par un processus rigoureux de revue de code permettent de réduire les risques d’ajouter à la dette technique. De plus, avoir des objectifs clairs dès le début du projet permettra la conception d’une architecture solide et limpide, qui non seulement aidera à prévenir la dette technique, mais assurera également une bonne vélocité dès le départ. Surtout, donnez le temps à votre équipe de développeurs et écoutez-les.

Un petit mot de fin

Temps, temps, temps. Les dépassements à la chronologie désirée et aux coûts d’un projet sont le cauchemar de tout gestionnaire. C’est pourquoi il faut être aux aguets face aux trois grands problèmes d’un projet informatique: les objectifs instables, les bogues, et la dette technique. Souvenez-vous toujours: « Slow is smooth, and smooth is fast. » Prévoyez suffisamment de temps pour votre équipe technique pour créer le produit qui fera exceller votre entreprise, et vous aurez un produit de qualité du premier coup et dans les temps prévus.

Si vous souhaiter en savoir plus sur l'importance de la confiance en ce qui concerne les solutions numériques, lisez le deuxième article de cette série sur la gestion des risques et des exceptions.

Crédit photo: Claudio Schwartz Purzlbaum