La plupart des projets logiciels prennent du retard. Non pas parce que les développeurs travaillent lentement, ni parce qu'un problème catastrophique s'est produit. Ils prennent du retard parce que les délais sont construits sur des hypothèses - et les hypothèses, par définition, s'avèrent être partiellement fausses.
Ce n'est pas un échec d'effort. C'est une caractéristique structurelle du développement logiciel. Comprendre pourquoi cela se produit est la première étape pour le gérer.
Repères réalistes selon le type de projet
Avant d'aborder les causes, voici des délais réalistes pour les types de projets courants - en supposant qu'une portée claire existe avant le début du développement.
- Outil interne simple (un seul processus, pas d'intégrations, peu d'utilisateurs) : 4 à 8 semaines
- Système de complexité moyenne (plusieurs modules, au moins une intégration, rôles utilisateurs) : 3 à 5 mois
- Plateforme complexe (plusieurs types d'utilisateurs, plusieurs intégrations, flux de travail personnalisés) : 6 à 12 mois
Ce ne sont pas des objectifs agressifs ni des scénarios pessimistes. Ce sont des fourchettes réalistes pour des équipes qui savent ce qu'elles font. Si quelqu'un vous propose nettement moins, demandez-lui ce qu'il laisse de côté.
Ce qui rallonge les délais : des exigences floues
C'est le facteur le plus important dans les retards logiciels, et il relève presque entièrement du contrôle du client.
Chaque fois qu'une exigence est découverte en cours de développement alors qu'elle ne figurait pas dans le périmètre initial, le délai s'allonge. Le développeur doit s'arrêter, évaluer l'impact sur le travail existant, reconcevoir si nécessaire, et implémenter quelque chose de nouveau. Ce qui aurait pu prendre un jour à construire au début du projet peut prendre une semaine à intégrer dans un système existant.
Plus la spécification initiale est vague, plus ces découvertes sont fréquentes. "On veut un tableau de bord" n'est pas une exigence. "On veut un tableau de bord affichant les ventes hebdomadaires par région, filtrable par catégorie de produit, accessible uniquement aux responsables" est une exigence. La différence de temps de développement entre ces deux formulations peut se mesurer en semaines.
Être précis en amont n'est pas de la bureaucratie. C'est de l'argent économisé.
Ce qui rallonge les délais : les retards de retour d'information
Le développement logiciel est itératif. Le travail est construit par phases, revu, ajusté, puis poursuivi. Cela fonctionne quand le retour d'information arrive rapidement. Cela se dégrade quand ce n'est pas le cas.
Si un développeur livre un module pour révision et que le client met deux semaines à répondre, ce sont deux semaines ajoutées au projet - au minimum. Le développeur a soit continué sur d'autres travaux et doit maintenant reprendre le contexte, soit il a attendu. Dans les deux cas, le calendrier en aval est décalé.
Multipliez cela sur un projet de cinq mois avec six ou huit points de révision, et les seuls retards de retour d'information peuvent doubler la durée totale. Des réunions hebdomadaires et des réponses rapides aux demandes de révision ne sont pas des extras optionnels - ils font partie intégrante du maintien du calendrier.
Ce qui rallonge les délais : la complexité des intégrations
Connecter votre logiciel à des systèmes tiers - passerelles de paiement, plateformes comptables, portails gouvernementaux, API logistiques - est systématiquement la partie la plus chronophage et la moins prévisible de tout projet.
Le problème est que vous ne contrôlez pas entièrement l'autre côté. Les API changent sans préavis. La documentation décrit comment les choses sont censées fonctionner, pas comment elles se comportent réellement dans les cas limites. Les systèmes d'authentification ont des exigences non documentées. Le portail gouvernemental censé accepter du XML standard requiert un format décrit uniquement dans un PDF de 2019 que vous trouverez à la page 47 d'un post de forum.
Les intégrations peuvent être estimées, mais elles comportent plus d'incertitude que le développement autonome. Une bonne équipe le signalera explicitement dans le plan de projet et ajoutera une marge en conséquence.
Ce qui maintient vraiment les projets dans les délais
Il n'y a pas de magie ici. Les projets restent dans les délais quand :
- Le périmètre est défini avant le démarrage du développement. Pas complètement immuable, mais clairement défini. Les changements après le lancement doivent être traités comme des ajouts de périmètre, pas des corrections.
- Le retour d'information est rapide. Deux à trois jours ouvrables maximum pour répondre aux demandes de révision. Si vous ne pouvez pas vous y engager, le délai doit le refléter.
- Des réunions ont lieu chaque semaine. Pas pour surveiller le développeur, mais pour détecter les problèmes avant qu'ils ne deviennent des retards. Un risque identifié en semaine deux est corrigeable. Le même risque identifié en semaine six est coûteux.
- L'équipe remonte les problèmes tôt. Une équipe de développement qui cache les mauvaises nouvelles pour protéger la relation est plus dangereuse que celle qui signale immédiatement les problèmes. Vous voulez des alertes précoces, même quand elles sont inconfortables.
L'attente honnête
Intégrez une marge de 20 à 30 % dans toute estimation que vous recevez. Non pas parce que l'équipe sera inefficace - mais parce que la complexité se révèle avec le temps. Des fonctionnalités qui semblaient simples s'avèrent nécessiter plus de réflexion. Des intégrations qui paraissaient standard ont une exigence inhabituelle. Un processus métier censé être simple comporte une exception que personne n'avait mentionnée.
Ce n'est pas du pessimisme. C'est ainsi que fonctionne le logiciel. Une équipe qui vous donne une estimation serrée sans marge est soit trop confiante, soit vous dit ce que vous voulez entendre. Aucune des deux options n'est utile.
Prévoyez la marge. Essayez de ne pas en avoir besoin. La plupart du temps, vous vous retrouverez quelque part entre les deux.
Nous construisons des délais réalistes dès le départ, signalons les risques dès que nous les identifions, et vous tenons informé tout au long du projet - pas seulement quand quelque chose tourne mal. Contactez-nous pour discuter de votre projet.