Je profite de l’excellente réponse de Michael Wolfe qui buzz pas mal sur Quora à la question “Pourquoi la majorité des développements informatiques explosent régulièrement le planning prévu d’un facteur 2 à 3?” pour me pencher à mon tour sur celle-ci et essayer d’apporter quelques pistes qui jusqu’à présent semblent ne pas trop mal fonctionner.

Comment planifier au mieux les développements de sa solution et de ses différentes versions/features afin de tenir au mieux les délais engagés? Cette fameuse question, je pense que tout entrepreneur y a déjà été confrontée et y sera confronté en permanence tout au long de son aventure.

Il s’agit là d’une question relativement cruciale à ce niveau, car contrairement à de plus grosses entreprises, le retard des développements en début de vie d’une entreprise sur ses releases peut avoir des conséquences désastreuses… Contrairement à une grosse entreprise toujours, il est impossible souvent d’obtenir des subventions supplémentaires, d’ajouter des développeurs à l’équipe tirant la langue pour compenser/rattrapper le retard ou de commercialiser quoi que ce soit en attendant la fin du projet.

Voici quelques pistes qui méritent je pense d’être explorées et adapter en fonction de sa startup pour essayer de mieux gérer cela:

• Adoptez une méthodo Agile. Au placard le cycle en V, au placard les bons vieux diagrammes de Gantt (dans mon cas, tout ce qu’on m’a appris à l’école. Encore une fois, vos diplômes et CV ne servent à rien ;)) La méthodologie Scrum est à mon goût la plus simple à épouser et mettre en oeuvre, et fait de vrais petits miracles. Cela permet de découper tout le projet en tâches simples et unitaires, ce qui oblige un effort en amont de réflexion mais met aussi en valeur toute tâche et donne à réfléchir sur sa complexité estimée. On diminue ainsi les mauvaises surprises non-anticipées sur un Gantt où on dispose de 5 jours pour effectuer une série de tâches non-réellement évaluées. Cela permet aussi au jour le jour de constater l’avancée de chaque développeur et de l’équipe en général (efficacité ou burndown). Ainsi, pas de mauvaise surprise au bout de 8 jours sur une tâche de 12 jours, on peut quantifier le retard ou l’avance de l’équipe jour par jour, semaine par semaine et y remédier en plaçant en développeur en avance sur une tâche d’un autre en retard.

• Planifiez les délais avec l’équipe, prendre en compte l’expérience, les spécificités et vitesses de chacun. A chaque projet que je planifie, je me sers de mon expérience et de mon intuition pour établir les bases de l’estimation des différentes tâches. Ensuite, tâche par tâche, je multiplie l’estimation de difficulté/de temps par un facteur dépendant de la personne qui se verra attribuer la tâche: est-ce que celle-ci est une tâche répétable qu’il a pu effectuer ou déjà croiser? Est-ce que cela touche du code ou un défi qu’il affectionne et où il sera plus performant? Est-ce que cela impliquera qu’il se documente?
  Par la suite, il est important de confronter mes estimations avec l’équipe (et je ne demande pas qu’à X de juger ses propres tâches, mais aussi celles de Z ou Y en fonction de la perception qu’il a d’eux et vice versa). C’est avant tout un travail d’équipe, et ternir les délais prends aussi en compte l’état d’esprit de l’équipe durant les développements. Il n’y a rien de pire qu’une équipe qui galope, stressée et maussade, derrière des deadlines dépassées de 2 semaine au moins.

• Ne pas passer aux oubliettes “l’enrobage” et les “finitions”. Personellement, c’est là où je pêche le plus. On a trop tendance à budgeter le gros-oeuvre du développement (schémas, modèles, bdd, archi, entités, controllers, actions… jusqu’au début de la recette) pour 80% des efforts et du temps, car en effet niveau écriture de code, cela doit bien représenter la majorité des inserts/deletes et commits du projet. Grave erreur. Les 20% d’efforts restants représentent bien souvent à eux seuls au moins la moitié du temps du projet nécessaire! Je m’astreint donc à la règle suivante (attention, recette de grand-mère!): j’estime de façon le plus réaliste possible la durée des développements du gros-oeuvre, et alloue cette même durée pour les finitions. Vous verrez, ça ira bien mieux: vous aurez désormais le temps d’écrire des tests unitaires et fonctionnels (qui vous feront au final gagner un temps fou) au fil des développements et prendre soin à l’UI et l’UX.

• Minimiser les perturbations éxtérieures au projet et les ajouts de features en continu. L’environnement de travail a extrêmement d’importance sur les délais de réalisations. Une équipe lancée dans son projet et focus uniquement là dessus sera moins encline à dépasser les estimations. Essayez de favoriser l’environnement de l’équipe pour qu’elle reste focus sur son projet. Ce n’est pas forcément évident en startup car on peut rarement se permettre ce luxe, mais dans mon cas, lorsque mes développeurs sont sur un projet/nouvelle feature, je prends en charge les modifications clients, retours de bugs et autres distractions qui viendraient les perturber sur leur lancée. De même, assurez-vous d’avoir clairement défini et approuvé le scope du projet en amont des développements avec vos associés ou le business et refusez tout ajout de nouvelle feature au cours des développements. Mettez-les de côté et cela fera partie de la version suivante, mais un sprint lancé ne doit pas être modifié (surtout pour lui ajouter des éléments).

Malgré toutes ces précautions, une infinité d’impondérables se metta en travers de votre chemin (et surtout en startup!): un arrêt maladie, un pic de business à absorber, un deal à ne pas louper et qui s’intercale dans votre projet, une tâche d’une heure mal prévue qui occasionne une refacto de 2 jours, une personne qui quitte votre équipe, des nouvelles qui s’y greffent et qu’il faut former… Il vous faudra en plus de planifier au mieux vos projets, savoir motiver et récompenser vos équipes tout en communicant et rassurant vos clients et associés pour mener à bien vos projets dans le meilleur des mondes :)

Et vous, comment limitez-vous les retards de vos projets?