J’aborderai la question du point de vue du génie logiciel, bien que de nombreuses leçons apprises s’appliquent également à d’autres projets. Produire des estimations de projet précises est l’une des tâches les plus difficiles à accomplir en génie logiciel et une compétence souvent négligée que la plupart des ingénieurs (y compris moi-même) ne savent pas bien faire. Il est également vrai que les personnes qui n’ont pas eu besoin d’estimer les délais d’achèvement des projets auparavant ont tendance à sous-estimer la difficulté et à se tromper d’au moins deux fois leurs estimations. Comme toute compétence, on ne s’améliore qu’avec la pratique.
Mon souvenir le plus vif des estimations de projets qui ont mal tourné s’est produit quelques mois après avoir rejoint Ooyala, une start-up qui fournissait une plate-forme vidéo en ligne de bout en bout. En août 2008, un peu plus d’un an après la création de l’entreprise, l’équipe d’ingénierie a commencé à travailler sur une réécriture du lecteur vidéo Flash du produit. Nos objectifs étaient de rendre le lecteur plus modulaire et plus performant et d’avoir également une base de code plus propre et mieux testée. Une équipe initiale de 3 personnes a conçu et écrit une infrastructure de base avant de rejoindre moi-même et le reste de l’équipe d’ingénierie de ~ 10 personnes. Ils ont estimé à 4 mois la fin du projet, et le directeur technique et le chef de produit ont produit des diagrammes de Gantt résumant la répartition du travail et les dépendances. Le nouveau joueur a fini par lancer complètement 9 mois plus tard en mai 2009.
Nous avons raté la cible non pas par manque de travail acharné ou d’ingénieurs talentueux; il y a eu une série de mois où la plupart des membres de l’équipe ont tiré des semaines de 70 à 80 heures (non recommandées). À mi-parcours du projet, nous avons même minutieusement passé quelques jours d’exercices où nous avons attribué des estimations horaires à des tâches assez granulaires. Les retards les plus importants résultent presque toujours de facteurs, dont de nombreux externes, que nous n’avons pas pris en compte dans les estimations initiales:
- contrats clients hautement prioritaires en cours de signature qui obligeaient les ingénieurs à passer en contexte à un travail personnalisé,
- bogues dans le code flash player d’Adobe qui rendaient difficile la détermination précise du moment où la vidéo était réellement en pause, mise en mémoire tampon et lecture,
- bogues de corruption vidéo difficiles à reproduire qui bloquaient le lecteur lors de la recherche de certaines images vidéo dans IE,
- développement de produits devant reprendre 4 mois après le début du projet afin de satisfaire la clientèle actuelle,
- problèmes d’évolutivité qui devaient être résolus en tant que montant de les données analytiques ont augmenté,
- un ingénieur précoce a quitté l’équipe à mi-projet, nécessitant un transfert de connaissances important des principales parties de la base de code,
- etc.
Alors que la réécriture du joueur était définitivement nécessaire pour l’entreprise, la manière imprévue dont dragged out a eu un impact important sur le démarrage précoce. D’autres projets sur lesquels j’ai travaillé, que j’ai vus d’occasion ou dont j’ai parlé à d’autres ingénieurs, ont suivi des modèles similaires où le temps d’achèvement réel double souvent les estimations initiales.
Voici quelques-unes de mes leçons à retenir de ces expériences:
Autant que possible, demandez aux personnes qui produisent les estimations pour une tâche d’être les personnes réelles qui y travailleront. Ceci est similaire au point de Ian McAllister d’utiliser l’estimation du joueur B – il est déjà incroyablement difficile pour une personne de prédire avec précision combien de temps une liste de tâches lui prendrait, même si les tâches sont assez granulaires; il est encore plus difficile de prédire combien de temps cela prendrait à quelqu’un d’autre avec un degré différent de familiarité et un degré différent de compétence. Il est devenu évident lors de la réécriture du joueur d’Ooyala que de nombreuses estimations initiales étaient extrêmement agressives et ignoraient le temps de montée en puissance d’un ingénieur sur des parties de la base de code qu’il connaissait moins.
Méfiez-vous de l’effet du deuxième système. Dans Le Mythique Mois-homme, Frederick Brooks décrit à partir de ses expériences de projet chez IBM comment une tendance humaine à sur-concevoir le deuxième système entraîne une complexité considérablement accrue, entraînant un glissement des calendriers des projets de refonte :
Le premier travail d’un architecte est susceptible d’être épargné et propre. Il sait qu’il ne sait pas ce qu’il fait, alors il le fait avec soin et avec beaucoup de retenue.
Lorsqu’il conçoit la première œuvre, volant après volant et embellissement après embellissement lui viennent à l’esprit. Ceux-ci sont stockés pour être utilisés « la prochaine fois. »Tôt ou tard, le premier système est terminé, et l’architecte, avec une confiance ferme et une maîtrise démontrée de cette classe de systèmes, est prêt à construire un deuxième système.
Ce second système est le plus dangereux qu’un homme ait jamais conçu… La tendance générale est de sur-concevoir le deuxième système, en utilisant toutes les idées et les fioritures qui ont été prudemment détournées sur le premier.
Surtout pour un projet qui implique la réécriture de logiciels existants, il est tentant de regrouper une multitude de nouvelles fonctionnalités dans ce qui aurait pu être un port simple, en utilisant l’argument que l’équipe pourrait aussi bien le faire si elle réécrivait la base de code de toute façon. L’augmentation de la complexité peut conduire à ce que ni la réécriture ni les nouvelles fonctionnalités ne soient lancées jusqu’à beaucoup plus tard.
Veillez à confondre le temps que prendront les tâches d’un projet avec le délai avant la fin d’un projet. Plus un projet prend de temps, plus la probabilité que des variables environnementales externes entrent en jeu et prolongent le calendrier global du projet est élevée. La traînée récurrente mentionnée par Ian contribue à la chronologie d’un projet, tout comme les événements inattendus. Pour les projets sur lesquels j’ai travaillé plus tôt cette année chez Quora, un certain nombre d’entre eux ont mis plus de temps à se lancer que prévu en raison des coûts de temps cumulés de:
- réponse et récupération d’une panne AWS inattendue de plusieurs jours,
- traitement des alertes de devoir de téléavertisseur périoïdiques pour maintenir le site en service,
- vacances programmées qui semblaient autrefois loin d’un projet mais qui se chevauchaient avec celui-ci,
- préparation et participation à des événements de recrutement,
- changement de contexte entre plusieurs projets cela s’est avéré plus délicat que prévu initialement.
Pour tout projet, on pourrait probablement énumérer n’importe quel nombre d’événements et de distractions qui, individuellement, pourraient être improbables ou non coûteux, mais qui, collectivement, doivent se produire et s’additionner sur un laps de temps suffisamment long. Plus le projet est long, plus il y aura de distractions, et il est important de prévoir du temps de tampon pour des facteurs externes inconnus.
Prévoyez suffisamment de temps pour toutes les tâches liées à l’intégration. En particulier pour les projets avec de nombreux composants interdépendants, de nombreux ingénieurs ont tendance à 1) reporter les tâches d’intégration de bout en bout à la toute fin, et 2) sous-estimer considérablement le temps nécessaire pour intégrer toutes les pièces ensemble dans un système de travail. Parce que l’intégration a tendance à être si éloignée et que les risques sont généralement inconnus – l’hypothèse du temps d’intégration est que tous les composants fonctionnent avec succès isolément – la sous-estimation du temps d’intégration a tendance à être assez courante. Les projets ne reçoivent souvent qu’une infime fraction du temps total du projet pour les tests de bout en bout, même s’il s’agit généralement de l’un des aspects les plus risqués d’un projet et, par rapport aux étapes précédentes, nécessite beaucoup plus de frais de communication entre les membres de l’équipe.
Le corollaire est de commencer les tests de bout en bout le plus tôt possible pour identifier plus tôt les risques et les problèmes d’intégration afin d’avoir suffisamment de temps pour les résoudre.
Estimation basée sur la durée réelle des tâches, et non sur la durée que vous ou quelqu’un d’autre souhaitez qu’elles prennent. Il y aura toujours une pression pour terminer les projets plus rapidement, que ce soit de vous-même, des membres de votre équipe, de la direction ou des clients, et souvent la réponse émotionnelle à cette pression nous ancre dans des délais exigés de l’extérieur et nous conduit à sous-estimer systématiquement les tâches. Psychologiquement, personne ne veut laisser tomber les autres, et il est facile de se dire que si vous travaillez un peu plus dur ou plus efficacement, vous pouvez respecter un certain délai. Cependant, en particulier pour les projets à long terme, ce type de vœu pieux n’est finalement pas viable.
Réexaminez et révisez périodiquement les estimations du projet au fur et à mesure de l’avancement du projet. Tout comme la façon dont la plupart des bons logiciels sont construits et améliorés progressivement, les estimations de projets le sont également. La révision des estimations de projet et la comparaison des estimations pour les tâches de la semaine écoulée avec le temps réel pris aident à relever les erreurs d’estimation et à réviser les calendriers en fonction des risques précédemment imprévus.
Les estimations de projets ont presque toujours tendance à être sous-estimées plutôt que surestimées; on entend rarement parler de longs projets se terminant plus tôt que prévu. Être conscient que l’estimation du projet est difficile et réfléchir aux raisons pour lesquelles les estimations ont mal tourné sur un projet particulier vous guidera vers des erreurs d’estimation plus petites sur les projets ultérieurs.
L’exécution d’un projet ne se limite pas à produire des estimations précises. Si vous êtes ingénieur et que vous souhaitez maîtriser les techniques utilisées par les meilleurs ingénieurs logiciels pour transformer leurs projets en succès, téléchargez un exemple de chapitre gratuit de mon livre, The Effective Engineer. Il regorge de centaines d’histoires, d’idées et de stratégies exploitables de dirigeants de toute la Silicon Valley.
———-
http://en.wikipedia.org/wiki/Gantt_chart
http://go.ooyala.com/Swift.html
http://www.the-wabe.com/notebook/second-system.html