Piloté par le stress
Par Jean-Baptiste le lundi 26 mai 2008, 10:28 - Code - Lien permanent
Voilà un certain temps que je n'ai pas publié quelque chose, et il y aurait tant à dire, mais je vais me contenter de parler du danger que je crois voir dans une gestion "classique" d'équipe de développement.
Ce que j'appelle classique est en fait l'assignation de tâches rigides estimées plus ou moins bien par une instance supérieure. L'idée est ensuite de demander bien entendu au développeur x ou y de tenir le délais estimé, sinon attention les doigts, il va falloir justifier très précisément la moindre minute de retard.
Même si l'utilité d'avoir un planning n'est pas à remettre en cause, le fait d'avoir un responsable quel qu'il soit qui vient regarder derrière votre épaule en permanence pour savoir si vous n'avez pas de retard entraine l'apparition d'un comportement extrêmement dangereux pour le projet. Plutôt qu'un long discours, je vais passer directement à l'exemple qui a conduit à ce billet:
Suite à une modification d'un concept de base du projet, même si cruise control était au vert, le fait est que j'avais oublié de refactoriser une partie impactée : les entrepôts de données. Un membre de l'équipe m'en fait la remarque; effectivement c'est une modification cruciale à faire, donc je lui dis en substance:
- ok tu vois ce qu'il faut faire, et bien vas-y tu es le mieux placé pour le faire maintenant.
- ah oui mais je suis sur telle tâche, que je dois absolument rendre pour ce soir, je n'ai pas de temps attribuée pour ça.
Mon ressenti par rapport à cette réponse, c'est qu'entre faire le travail nécessaire pour la santé du projet, et faire le travail nécessaire pour ne pas se faire taper dessus, vu l'environnement de stress mis en place, le choix est souvent trop vite fait.
Poussé un peu plus loin, ce qui me fais peur dans cette petite conversation, c'est finalement combien de fois des choix similaires ont été faits? Combien de fois un développeur, face à la peur ou l'envi d'être tranquile vis à vis de son chef, a choisi la solution dangereuse pour la santé globale du projet? Ma conclusion serait donc que dans un environnement piloté par le stress, les mauvais choix sont trop faciles à faire.
Commentaires
J'agrée avec ton point de vue. Cependant, le mode de gestion que tu critiques peut fonctionner tres correctement si le chef de projet est assez clairvoyant pour affecter à son equipe les bonnes taches au bon moment. Est ce qu'un chef de projet clairvoyant est un concept qui peut exister est un autre probleme...
Cela mériterait sans doute un billet en plus, mais le fait qu'au delà des problématiques de "gestion pilotée par le stress", le diagramme de gantt et l'approche par tâche et en cascade ont fait son temps.
:
Quelque soit les qualités humaines d'un chef de projet, s'il s'appuie sur de mauvais outils, il a moins de chance d'atteindre son but.
De plus, croire qu'il est possible de définir les tâches correctement à l'avance et de les répartir correctement est croire que la construction d'application personnalisée est un processus automatisable, reproductible et donc industrialisable. C'est par extension adhérer au fait que des gens de la qualité doivent nous dicter comment mieux faire notre travail, et croire au fait que le projet peut fonctionner si une seule personne en a la vision d'ensemble tandis que le reste travail sur des parties décorélées de leur contexte.
Même si notre métier est jeune, et que nous ne savons pas encore comment le faire à la perfection, nous pouvons au moins dire je pense ce qu'il n'est pas. Pour répondre à ça, je préfère laisser la main à plus fort que moi
www.domaindrivendesign.or...
On a tendance à répéter qu'il n'existe aucune méthode de gestion de projet parfaite... Pour ma part, je pense qu'il faut surtout comprendre qu'elles ne se valent pas toutes, et que dès lors, il y en qui sont meilleures (voire incomparablement meilleures) que d'autres.
Tu as raison de dire que notre métier est jeune ; trop de gens l'oublient. Mais c'est aussi un des métiers dans lesquels les nouveaux processus et les nouvelles méthodes ont beaucoup plus de mal à s'imposer que les nouvelles technologies ou plateformes. Je veux dire par là qu'il existe des solutions qui sont trop souvent mal considérées, et qui peinent à être testées et appliquées. Lorsqu'elles y parviennent, elles fonctionnent.
La situation que tu décris dans ton billet pourrait être considérée comme normale - faisant partie des évènements prévisibles d'un projet - et donc appréhendée suivant une procédure établie capable de prendre en charge ces cas. C'est en substance ce que proposent les méthodes agiles, notamment. Malheureusement, trop peu d'équipes en profitent, trop de hiérarchies, d'organisations et de systèmes semblent sclérosés.
Ta conclusion est évidente, et peut même être étendue : beaucoup de projets sont encore conduits de façon archaïque en ingénierie logicielle. Le stress peut même être considéré comme étant à la foi un symptôme et une cause de ces mauvaises conduites. Il y en a d'autres...
Amplement d'accord avec tout ca.
Le paradoxe de notre métier est que par manque de recul et d'expérience, par péché de jeunesse en somme, on utilise des méthodes archaïques, issues des méthodes de productions du secteur industriel alors que nous travaillons dans le secteur des services. Et étrangement ces méthodes archaïques qui se sont imposées (j'imagine du fait de l'héritage industriel de l'informatique d'il y a 40 ans) ne sont pas loin d'etre les moins adaptées qui se puissent imaginer. Et par voie de conséquence, toute nouvelle tentative pour optimiser le processus de fabrication de logiciel ne peut qu'aboutir a de meilleurs résultats. D'ou la pléthode de méthodes emergeant depuis 20 ans.
Merci Romain pour cette réponse tout à fait juste.
EDIT: Je retouche ma réponse car je n'avais pas vu le commentaire suivant. Finalement je pose deux questions: Premièrement, pourquoi les méthodes industrielles se sont-elles imposées? Appliquées à notre métier elles défient toute logique et toute raison, et pourtant nous les croisons pratiquement sur chaque projet. Ma deuxième question serait de savoir pourquoi le "milieu" informatique affiche une telle résistance depuis 20 à l'émergence de nouvelles méthodes. Les bonnes idées fusent un peu partout, mais rien n'a été aussi magistralement accepté que l'approche en cascade et ses dérivées.Je ne sais pas si j'ai grand chose à ajouter, si ce n'est de dire que finalement je suis content de la version finale de ce billet retouchée trop de fois, car apparemment elle a permis des réactions de qualité.
Sur le rôle du chef de projet, valtech a pondu il y a un moment deja un article assez juste et assez clair : www.valtech-mag.com/mag/f...
Ensuite, je crains d'être un peu vindicatif dans le rudiment de réponse que je vais faire aux questions posées par Bodysplash. Le seul trait qui puisse justifier pour moi l'utilisation de méthodes aussi inefficaces est qu'elles permettent l'exercice de l'autorité et satisfont des formes d'ambition et de compétition et un peu simplistes des managers de projet. Il me semble que pas mal de chefs de projets que j'ai connus se sentiraient rabaissés par leur reconversion en scrummanager (par exemple) pour ces raisons.
Dans l'article que tu viens de linker, je trouve que les commentaires finalement donnent à peu prêt tout ce qu'il y a savoir:
- peur
- protection
- incompréhension
Je pense que surtout pour les projets informatiques, la définition d'un périmètre logiciel fait parti des tâches les plus difficiles. Un périmètre physique reste touchable, plus facilement imaginable. Un périmètre logiciel, en revanche, demande des capacités d'abstraction énormes. Par conséquent, l'évaluation des tâches et leur chiffrage est souvent inexact quelque soit l'expérience du chef de projet ou la méthode qu'il applique. C'est pourquoi, finalement, consciemment ou inconsciemment, il se trouve à appliquer "la méthode de Stress en Cascade": Propager le stress qu'il subit sur les développeurs. Bien sur, il y aussi, "Développement orienté carrière", mais c'est un autre sujet ...