Un projet de quatre semaines qui en prend dix n'a rarement perdu six semaines à cause d'un mauvais code. Il les a perdues en attente — d'une décision, d'une validation, de quelqu'un ayant les bons identifiants pour les envoyer, d'une réponse à une question restée quatre jours dans une boîte mail. Le temps de développement et le temps calendaire sont deux horloges différentes, et sur la plupart des projets en retard, l'écart entre les deux est presque entièrement du temps où personne ne codait réellement.
Les décisions sont le goulot d'étranglement le plus fréquent
Un développeur arrivant à un embranchement — deux façons raisonnables de construire une fonctionnalité, chacune avec des implications différentes — doit s'arrêter et demander, car deviner mal coûte plus de temps que demander. Si cette question reste sans réponse pendant une semaine parce qu'elle nécessite l'aval de quelqu'un en déplacement, tout le projet bloque derrière elle, même si le travail réel restant n'a pas changé. Désigner une seule personne ayant l'autorité de répondre à ces questions, avec un délai de réponse maximal convenu, élimine ce goulot avant qu'il n'apparaisse.
Les délais d'accès coûtent plus qu'il n'y paraît
Un projet ayant besoin d'identifiants pour un prestataire de paiement, un bureau d'enregistrement de domaine ou un système existant ne peut souvent pas avancer au-delà d'un certain point sans eux — et ces identifiants se trouvent fréquemment chez un tiers, un ex-employé, ou quelqu'un qu'il faut relancer deux fois. Une semaine perdue à attendre une réinitialisation de mot de passe équivaut fonctionnellement à une semaine perdue sur un problème de code, sauf qu'elle était entièrement évitable si les accès avaient été rassemblés avant le début du projet plutôt que demandés au fur et à mesure des besoins.
La latence des retours s'accumule sur tout le projet
Un tour de retours qui met trois jours à arriver au lieu d'un ne coûte pas deux jours une seule fois — il coûte deux jours à chaque point de révision du projet, et la plupart des projets en comptent plusieurs. Une équipe qui s'engage sur un délai de retour précis dès le départ, et le traite comme elle traiterait une échéance de paiement, élimine une source de retard qui, sinon, réapparaît à chaque jalon plutôt qu'une seule fois.
Ce qui relève réellement de la responsabilité du développeur
Rien de tout cela n'excuse de véritables retards de développement — une complexité sous-estimée, une dette technique découverte, ou un développeur simplement en retard sont réels et relèvent de la responsabilité du côté livraison de les gérer et de les communiquer honnêtement. Mais confondre un retard causé par une question sans réponse avec un retard causé par du code difficile mène à appliquer le mauvais remède — des heures de développeur supplémentaires n'accéléreront pas un projet qui attend en réalité une décision côté client, quel qu'en soit le nombre ajouté.
Distinguer les deux compte
Nommer la catégorie à laquelle appartient un retard, au moment où il se produit plutôt qu'au bilan final, est ce qui permet à un projet de réellement revenir dans les temps, plutôt que tout le monde s'accorde tacitement à ne pas être d'accord sur la semaine de qui c'était.
Cela s'inscrit dans la même conversation acheter, construire ou configurer — une réalisation bien menée ne reste dans les temps que si les deux parties gèrent l'horloge qui tourne réellement, pas seulement celle qui mesure le code.
Notre équipe logicielle fixe les attentes de délai de réponse et les besoins d'accès avant le début d'un projet, pour que les semaines autrement perdues en attente n'aient tout simplement pas lieu.
