[Lecture] Advan­ced Project Mana­ge­ment

Extrait de The Mana­ger’s Path

if you fill the sche­dule to 100% with feature deve­lop­ment, expect that the feature deve­lop­ment will quickly slow down as a result of this over­sche­du­ling »

Juste avant, l’au­teure parle de ne comp­ter que 10 semaines et non 13 par trimestre, pour prendre en compte les congés, l’on­boar­ding des nouveaux employés, les indis­po­ni­bi­li­tés de produc­tion, etc. C’est proba­ble­ment plus en France vu le nombre de congés.

Entre les deux elle parle de 20 % de temps pour les travaux de soutien tech­nique comme les tests, le nettoyage des codes histo­riques et les migra­tions.

Ce n’est pas précisé ici mais je me rappelle aussi ce que montre Shape-Up avec 2 semaines de cool-down pour 6 semaines de produc­tion.

De mon côté j’at­tends un focus sur la road­map de l’ordre de 70 à 80 % et c’est déjà beau­coup. Je me rappelle mes années à Yahoo! où la plani­fi­ca­tion se faisaient avec une réfé­rence de 4 heures de pleine effi­ca­cité par jour. C’était aussi ma première boite où il était accep­table de dire « je n’ai pas réussi à avan­cer hier, j’en suis au même point » sans que ça ne soit honteux.

Ce n’est pas tant que le reste n’est pas travaillé, c’est qu’il compte pour les la construc­tion des outils, les inves­tis­se­ments tech­niques, les échanges, les forma­tions, les périodes où on est moins voire peu produc­tif. C’est souvent de ces temps là que viennent tous les travaux annexes qui peuvent chan­ger le fonc­tion­ne­ment de l’équipe ou de l’en­tre­prise, et qui réduisent les frus­tra­tions au jour le jour.

Ce n’est pas tant qu’il faille doubler les esti­ma­tions des déve­lop­peurs (qui est plus loin une pratique consi­dé­rée comme posi­tive par l’au­teure), c’est qu’il faut arrê­ter de jouer au tétris avec les road­map et les esti­ma­tions. Prévoir une road­map qui occupe 50 % du temps de travail est plutôt une bonne cible.

You will almost certainly have occa­sio­nal dead­lines, either goal dates that you’ve set or goal dates that came down from on high. The only way to achieve these goals is to cut scope at the end of the project.

J’ai un malaise en lisant et je classe ça dans les compor­te­ment toxiques. Je crois que c’est la première fois dans ma lecture.

Je suis déjà gêné par le mélange entre la dead­line et le goad date. Il y a parfois des dates limites. J’ai travaillé sur un site d’ac­tua­li­tés spor­tives et on n’y a pas le loisir de déca­ler l’évé­ne­ment des Jeux Olym­piques. La date limite peut-être n’im­porte quoi d’ex­té­rieur et d’im­pos­sible ou très coûteux à déca­ler mais pas un objec­tif venu d’en haut. Si l’es­poir d’en haut n’est pas tenable alors c’est en haut qu’il faut chan­ger quelque chose.

La pratique qui consiste à passer en mode urgence quand la date approche c’est le pire possible pour la qualité, autant tech­nique que vis à vis de l’uti­li­sa­teur

Si on coupe le péri­mètre projet, c’est pour livrer rapi­de­ment, itéra­ti­ve­ment, simple­ment, et on devrait le faire tout le temps, pas pour tenir une date arti­fi­cielle qui n’est qu’un objec­tif de plan.

Si on prend des raccour­cis tech­niques c’est pour livrer plus rapi­de­ment, itéra­ti­ve­ment, et on devrait le faire souvent, pas pour tenir une date arti­fi­cielle qui n’est qu’un objec­tif de plan.

Pour les deux cas, ça veut dire aller enri­chir avec d’autres itéra­tions ou nettoyages derrière.

Je tiens beau­coup au mani­feste agile et à son « Respon­ding to change over follo­wing a plan ».

---

J’ai trop souvent de malaises quand je lis les chapitres de gestion de projet ailleurs que dans des livres qui parlent d’agi­lité. Je sens vrai­ment deux mondes diffé­rents qui s’af­frontent.