Article invité : Troy Magennis de Focused Objective
En tant que professionnels de l'informatique de longue date, nous comprenons, chez Planview AgilePlace, la douleur de se voir demander des estimations détaillées sur des choses que nous n'avons jamais faites et que nous ne ferons peut-être jamais. On perd énormément de temps à élaborer des plans détaillés qui finissent par n'avoir aucun rapport avec la réalité. L'idée d'obliger les gens à assister à des réunions d'état ennuyeuses pour donner des estimations du pourcentage d'avancement pour des éléments du plan de projet pour la plupart non pertinents nous rend un peu malades. Nous soutenons donc de tout cœur la volonté du monde Lean-Agile de de s'éloigner des plans et des estimations détaillés au niveau tactique. Nous pensons que les mesures de capacité que vous pouvez obtenir d'un système Kanban bien conçu sont beaucoup plus utiles pour les prévisions à court terme. Indice, indice.
Mais ...
Les cadres qui prennent les décisions d'investissement doivent avoir une idée de la direction que pourrait prendre un grand projet avant de pouvoir donner le feu vert de manière responsable pour commencer à acheter des équipements et des licences, à embaucher du personnel, dans certains cas à louer des bâtiments, etc. Un de nos amis senior IT-exec a décrit ses pairs d'affaires posant la question "Vers quelle falaise nous conduisez-vous ?". À ce niveau, l'estimation est indispensable.
Notre ami Troy Magennis est du même avis. Troy est un associé de longue date de David Anderson, Dan Vacanti et d'autres personnes clés du mouvement Kanban. Présents à la création, pourrait-on dire. Il était chef technique senior pour Travelocity - une très grande et admirablement entreprise de développement de logiciels Agile. Il a maintenant écrit un livre très intéressant sur la nécessité d'établir des prévisions efficaces pour soutenir Agile at Scale. Et il est en train de créer de formidables outils d'estimation pour cadres que nous attendons avec impatience.
Son essai est une lecture incontournable pour les agilistes qui souhaitent sérieusement faire grandir le mouvement.
----
Les agilistes doivent accepter la nécessité de prendre au sérieux les prévisions de revenus et de budget
Il est facile de rejoindre le chœur d'opinion selon lequel l'estimation des projets logiciels est un gaspillage et doit être éliminée. Bien que je puisse comprendre les objections à consacrer un temps précieux à la préparation et à la rationalisation d'une série d'estimations pour des fonctionnalités ou des projets mal définis, ce post explique les contre-points - pourquoi l'estimation est nécessaire, et pourquoi il est dans votre intérêt de participer.
Je ne défends pas le gaspillage évident que représente le fait de devoir estimer des travaux qui vont être réalisés sans tenir compte du temps et des coûts nécessaires à leur réalisation ; il y a peu de raisons rationnelles de perdre du temps à établir ces estimations. Je dis que la plupart des entreprises auront besoin d'une certaine forme d'estimations de la part de l'informatique pour se développer et être compétitives. Ce post examine deux raisons fondamentales pour lesquelles les entreprises ont besoin d'une estimation -
- Choisir le bon portefeuille de projets, et fixer les objectifs de revenus de l'année prochaine.
- Planifier et embaucher du personnel pour l'avenir, et fixer les objectifs de coûts de l'année prochaine.
Sélection du portefeuille et objectifs de revenus
Une entreprise est souvent confrontée à de multiples idées de projets et de fonctionnalités. Les personnes du côté du produit et du marketing proposent de nombreuses idées et se démènent pour que leurs idées soient promues plus haut dans le portefeuille en augmentant l'estimation des revenus pour chaque fonctionnalité (et oui, les personnes du côté du produit et du marketing détestent aussi donner une estimation des revenus par écrit, mais elles doivent le faire aussi). Un comité ou un individu filtre ensuite cette liste massive et détermine les produits et les fonctionnalités qui offrent le meilleur retour sur investissement, ce qui conduit à un objectif pour les prévisions de revenus de l'année suivante. C'est à peu près à cette période que l'on assiste à de nombreuses interruptions en voiture dans la zone de développement par des personnes faisant pression pour obtenir des estimations du type "Combien de temps cela prendrait-il pour construire x" (où x est une description d'une seule ligne d'une fonctionnalité complexe).
Si vous avez déjà participé aux "Olympiades de la budgétisation" organisées chaque année dans les moyennes et grandes entreprises, vous savez que c'est un processus brutal, compétitif, politique et frustrant. Il est difficile de défendre l'exactitude éventuelle de cette aventure, mais plutôt que de faire la moue, je vais proposer que cette fois-ci, c'est la direction de l'informatique qui doit se montrer disponible et prête à aider. L'informatique doit fixer des attentes correctes et offrir des options à l'entreprise sur quels projets peuvent être réalisés, et quel personnel sera nécessaire pour réaliser ces rêves et aspirations des objectifs de revenus de l'entreprise. Le fait d'ignorer ce processus conduit simplement à ce que l'informatique s'engage à respecter des dates de livraison de projet mal considérées, et à l'incapacité de montrer l'équilibre entre les niveaux de personnel supplémentaires et les niveaux de personnel habituels pour les tâches opérationnelles et de maintenance. Trop souvent, on suppose à tort que tout le personnel informatique est disponible pour de nouveaux projets, avec des commentaires du type "vous avez 400 personnes et vous me dites que vous ne pouvez pas faire x !".
Les produits du portefeuille et du budget nécessaires pour que l'entreprise puisse faire des promesses avec une certaine certitude sont -
- Un objectif de revenus pour l'entreprise l'année prochaine.
- Une idée de la date à laquelle chaque projet du portefeuille commencera à générer des revenus.
- Le nombre total d'employés pour calculer le coût des personnes.
Vous pourriez penser que les estimations informatiques ne sont nécessaires que pour 2 et 3 ci-dessus, mais en réalité, c'est le premier résultat (objectif de revenu) qui est le moteur important. Un produit livré en mars rapportera des revenus d'avril à décembre, soit neuf mois complets. Un produit livré en novembre rapporte un mois de recettes. Cela signifie que pour que l'entreprise puisse rendre public (ou montrer aux investisseurs internes et externes) un plan de croissance pour la prochaine période, il est essentiel de comprendre à quel moment une fonction commence à générer des revenus. Entrez l'estimation de la date de livraison du projet logiciel.
Pour l'instant, nos méthodologies "Agile" et "Lean" rendent difficile la clarté et la certitude autour des réponses nécessaires. C'est souvent une cause de friction entre ceux qui essaient de préparer un portefeuille/budget et ceux qui, dans l'informatique, essaient de livrer des produits de qualité (valeur) à intervalles réguliers, mais avec des dates calendaires ambiguës pour chaque fonctionnalité individuelle (toutes les formes de Agile development). Pour que l'entreprise puisse comprendre l'impact sur les revenus de chaque fonctionnalité/produit, les dates de mise en service doivent être précises. Confronter ce besoin à ce qui semble être une excuse du type "nous sommes agiles" laisse la direction générale frustrée et désabusée par l'informatique. Nous devons travailler avec l'entreprise pour choisir les bons projets, leur donner des indications sur la date à laquelle une fonctionnalité sera prête à générer des revenus, et exprimer clairement les risques et les probabilités de respecter ces dates. Cela signifie travailler avec enthousiasme avec eux sur la sélection de la portée, et fournir des estimations de la date de livraison dès que possible. Nous devons également travailler avec eux sur les plans et les coûts du personnel, que nous couvrons actuellement.
Décisions de dotation en personnel appropriées et nécessaires
Le financement d'un projet ou d'une caractéristique d'un produit est souvent la première étape ou une tâche annuelle effectuée dans la plupart des organisations. Pour construire un logiciel, il faut des gens, et ces gens coûtent de l'argent. Comprendre combien de personnes, et quelles compétences ces personnes ont besoin, est une tâche clé de la gestion informatique, et il n'existe pas de formule unique correcte. L'ajout de personnes peut réduire le délai de mise sur le marché (ou peut ne pas le faire si elles sont ajoutées au mauvais moment ou avec des personnes ayant les mauvaises compétences), mais de combien ? Et même si nous livrions plus tôt, y aurait-il plus de revenus reconnus au cours de l'année ou de la période de déclaration ? Toutes ces questions nécessitent de comprendre la quantité de travail nécessaire à un projet, et le nombre de personnes pour chaque scénario de livraison ET de maintenir les produits actuels qui apportent de la valeur.
À moins que vous ne réutilisiez une équipe existante, ET que les personnes qui investissent dans le projet acceptent le risque de ne pas connaître la date de mise en service, ET qu'elles soient convaincues que le projet sera livré dès que possible, vous ne pouvez pas faire l'impasse sur l'estimation. Si vous le faites, vous risquez de devoir ajouter du personnel en urgence tout au long du projet afin de respecter une date cible arbitraire décrétée par une personne non qualifiée en matière de développement de logiciels. Ce n'est pas toujours évident, mais le fait de participer tôt, de s'assurer que toute date cible bénéficie de votre contribution et de votre bénédiction, et de doter une équipe de projet d'un personnel capable de réussir à respecter cette date, est de loin le moyen le moins stressant et le moins chargé en termes de travail.
La direction générale perd confiance dans l'informatique chaque fois que quelqu'un doit procéder à une embauche d'urgence ou à une réduction de périmètre pour remettre un projet "sur les rails". La seule solution est de s'assurer que les compromis et les attentes sont définis dès le début, et que les personnes du côté de l'entreprise ont participé à l'équilibrage des objectifs de coûts (personnes) par rapport aux objectifs de revenus dès le début, idéalement pendant le portefeuille et le processus de budgétisation avant le début du projet. Vous voulez que les équipes produit et marketing soient de votre côté lorsque vous demandez plus de personnel ; c'est très puissant lorsque l'entreprise, et pas seulement la direction informatique, demande plus de personnel pour consolider un objectif de revenu (en livrant à temps ou plus tôt), et c'est la seule défense contre la spirale d'opinion "l'informatique demande toujours plus de personnel".
Avoir la capacité de construire et d'articuler les options de ressources en personnel pour un portefeuille informatique de nouveaux travaux et le personnel requis pour les opérations habituelles est essentiel pour rétablir la confiance des dirigeants d'entreprise envers la direction informatique. Proposer des options pour augmenter le personnel de manière stratégique afin d'aider une entreprise à atteindre ou à dépasser ses plans de revenus rend à la direction informatique le statut de héros que nous méritons, par opposition aux cow-boys geek du deuxième étage dont on nous affuble souvent aujourd'hui.
Résumé
Dans un prochain billet, je résumerai les stratégies sur la manière de construire et de communiquer les estimations logicielles, tant pour les prévisions de dates que de personnel, et sur la manière de minimiser le temps et les perturbations pour l'informatique tout en aidant l'entreprise tout au long du processus de budgétisation. Ce matériel est tiré de mon livre Forecasting and Simulating Software Development Projects - Effective Modeling of Kanban and Scrum Projects using Monte-carlo Simulation . J'ai eu l'occasion de voir les deux côtés de l'argument de l'estimation, et j'ai construit des outils et écrit sur les moyens de modéliser rapidement et de manière fiable les projets logiciels (vous pouvez en savoir plus sur FocusedObjective.com).
J'adorerais vivre dans un monde qui ne nécessiterait pas du tout d'estimations pour les projets logiciels, mais je ne crois pas que cela existe dans tous les projets et entreprises, sauf les plus petits. Savoir pourquoi les estimations sont nécessaires et comment collaborer avec vos pairs de l'entreprise pour proposer des solutions et des avis dès le début de la phase d'élaboration du portefeuille et du budget est le meilleur moyen de changer l'opinion de la direction sur les responsables informatiques, en rendant à l'informatique le statut de héros qu'elle mérite tant.
A propos de l'auteur
Troy is an experienced executive who has been involved in many leading software organizations over 20 years. Most recently, Troy founded Focused Objective to build tools and training for simulating and forecasting software development projects, including the Monte-carlo techniques as described in his book Forecasting and Simulating Software Development Projects – Effective modeling of Kanban and Scrum projects using Monte-carlo simulation. You can follow Troy on Twitter at @AgileSimulation or contact him by e-mail at [email protected].
