En bonus, il explique comment le projet Word 1.0 a été redressé, pour devenir finalement le succès commercial que l'on connaît.
"Le développement de Word pour Windows 1.0 fournit un exemple parfait pour étudier les conséquences d'une estimation trop optimiste du planning" (page 209 et suivantes).
Le développement de Winword était prévu estimé à 1 an et a demandé en réalité 5 ans. Bill Gates avait expressément demandé "le meilleur traitement de texte ayant jamais existé" en 1 an maximum.
Microsoft avait à l'époque l'habitude d'utiliser le crunch comme technique de gestion de projet et d'équipes : comme en témoigne Steve Mc Connell (P. 270, également Maguire 1995), les développeurs dormaient sur des lits de camp pour réaliser les heures supplémentaires exigées par ces cadences infernales.
Cette technique est également évoquée dans "54 règles d'or pour un grand logiciel", où Jim Mc Carthy raconte comment à cette époque les projets Microsoft sont souvent en mode redressement.
Le projet WinWord est donc le reflet d'une culture toxique, aussi bien du point de vue humain, que du point de vue qualité et financier. Le projet a connu un très fort turnover, 4 chefs de projets s'y sont succédés, et la qualité du code est déplorable.
Mc Connell estime qu'il n'existe que 3 façons de sauver un projet :
- réduire la taille fonctionnelle
- accroître la productivité des processus
- repousser la date de livraison.
Ces 3 approches doivent généralement être combinées pour obtenir des résultats suffisants pour que le projet soit encore économiquement viable.
Mc Connell insiste sur la nécessité de "reprendre le contrôle", au niveau de la qualité logicielle comme au niveau de l'avancement réel du projet. "C'est le moment des actes décisifs. (...) Il est plus facile de reprendre le contrôle en un seul coup qu'en plusieurs fois".
L'auteur recommande notamment l'usage de la théorie W, une approche gagnant-gagnant pour toutes les parties prenantes du développement logiciel.
Il s'agit de faire tout-le-monde un vainqueur :
- inventorier les bénéfices recherchés par chaque partie prenante (stakeholder, développeurs, entreprise, clients, utilisateurs, équipes de maintenance logicielle...)
- établir des attentes raisonnables de la part de toutes les parties prenantes
- établir et gérer les risques vainqueur-vaincu et vaincu-vaincu
- faire correspondre les tâches de tous ces individus à leurs conditions de victoire
- maintenir un focus utilisateur et l'implication du client et des utilisateurs
- obtenir le soutien des décideurs sur le nouveau plan projet
Mc Connell, insiste également sur le respect de la nouvelle planification.
Exemples d'application de la théorie W :
- Theory-W software project management principles and examples (1989)
- Theory-W software project management: a case study
Ce qui me frappe surtout dans la méthode Mc Connell, c'est le pouvoir accordé au pompier chargé de sauver le projet :
- il commence par envoyer les développeurs en vacance, pour qu'ils récupèrent d'abord de la fatigue accumulée
- il obtient tout ce qui est nécessaire pour maintenir le moral de l'équipe
- le management accepte le nouveau planning (alors que celui-ci prend acte du retard accumulé et repart sur des estimations plus réalistes)
Cette façon d'aborder le redressement le projet repose donc sur l'intervention d'un homme providentiel, le pompier, et la légitimité que lui accordent le management comme l'équipe de développement.
Le temps perdu ne se rattrape pas. Le nouveau départ repose sur le respect des règles intangibles de la gestion de projet, qui avaient été sacrifiées jusque là sur l'autel d'un planning irréaliste.
PS : notes sur ce livre et l'auteur :
je suis très fan des livres de Steve Mc Connell, mais il faut les prendre pour ce qu'ils sont : le reflet d'une époque, sa mentalité dominante, et ses biais de réflexion.
"Stratégies de développement rapide" n'est pas le livre le plus important dans la bibliographie de Mc Connell, et n'a d'intérêt qu'en tant que témoignage historique, pour comprendre comment raisonnent encore les managers qui ont du mal à embrasser l'agilité (et ceux qui prétendent qu'ils ont toujours été agile, que ce n'est que du bon sens, un nouveau mot pour des pratiques anciennes, etc).
Par exemple, les heures supplémentaires y sont considérées comme une pratique acceptable, tant qu'on n'en abuse pas.
La plupart des livres de Mc Connell s'ambitionnent comme des "bibles", des panoramas quasi-exhaustifs, dans une approche qui se veut encyclopédique et scientifique.
On est très près de l'état d'esprit du PMBok : la plupart des techniques et méthodologies sont considérées comme viables, il suffirait de choisir celle qui est adaptée au contexte. Les mélanges entre pratiques issues de théories distinctes ne sont pas déconseillés, ils m'y semblent au contraire encouragés. Ce qui mène in concreto au mariage de la carpe et du lapin.
En résumé, vous pouvez vous épargner l'achat et la lecture de ce livre, il existe d'autres ouvrages plus simples et cohérents qui vous aideront à progresser en gestion de projet.