dimanche 6 juillet 2008

PEOPLEWARE, Tom DeMarco & Timothy Lister

Si j'étais responsable de mon entreprise, j'offrirais ce livre aux managers et aux équipes. Je leur conseillerais avec insistance de le lire.
Certes, je n'ai pas l'impression d'avoir beaucoup appris, mais sa lecture m'as fait du bien pour deux raisons:
  • le livre est drôle, ce qui est rare pour un ouvrage concernant le développement logiciel, et
  • le livre met des mots clairs sur des impressions issues de mon expérience.
Le passage sur les bureaux, l'aménagement des locaux et la police du mobilier m'a bien fait rire d'autant plus que notre projet est actuellement en cours de déménagement. En effet, il existe des gens qui décident de l'organisation des locaux et de leur occupation alors qu'il n'ont aucune idée de la manière dont les gens travaillent!

Voici une petite sélection de vérités bonnes à retenir:
  • Les projets de développement échouent très rarement pour des raisons techniques;
  • Les principaux problèmes affectant les projets de développement sont d'ordre sociologique et non technique;
  • Les managers promus managers savent comment le travail est fait - pas comment il faut le gérer;
  • Plus le projet est risqué et plus il faut prendre le temps de réfléchir à la manière dont on travaille;
  • Les gens "pressurisés" ne travaillent pas mieux - juste plus vite;
  • Viser un très haut niveau de qualité est un moyen pour gagner en productivité;
  • Les managers ne doivent pas faire travailler leurs équipes. Ils doivent permettre à leurs équipes de travailler;
  • N'importe quoi peut être mesuré d'une manière plus bénéfique que ne pas mesurer (Gilb's Law);
  • Pour réussir un projet, il faut prendre des gens compétents et motivés et adopter un style de management délégatif;
  • Plus un processus est déterministe et moins il est adaptatif;
  • Un standard doit être consigné à postériori, c'est à dire après avoir fait ses preuves;
  • Le management par les objectifs individuels est destructeur pour l'efficacité des équipes (cf Deming);

3 commentaires:

  1. J'ai commandé ce livre et l'attends avec encore plus d'impatience suite à ce billet !
    Sinon quels sont les arguments en faveur de "Viser un très haut niveau de qualité est un moyen pour gagner en productivité;" ?

    Cela me paraît juste intuitivement, mais il me semble rencontrer parfois une croyance populaire selon laquelle augmenter la qualité réduirait la productivité...

    RépondreSupprimer
  2. Salut Bruno,

    un niveau de qualité au-dessus des exigences du client permet d'augmenter la qualité car:

    La motivation et la fierté des développeurs ne sont peu liés à la quantité de ce qu'ils produisent, mais très liés à la qualité de leur produit. Plus les développeurs peuvent cultiver la fierté de leur travail et plus ils travaillent bien.

    Aussi, plus on donne d'importance à la qualité du produit et moins sa construction sera ralentie par la gestion des défauts détectés à postériori. Viser un haut niveau de qualité élimine une catégorie de gaspillages.

    Faire un produit de qualité nécessite d'accorder du temps à la manière dont on travaille. Cette réflexion permet d'optimiser la manière dont on construit le produit - ce qui élimine une autre catégorie de gaspillages.

    RépondreSupprimer
  3. Lorsqu'on mesure la productivité pour voir l'impact de la qualité, il faut une mesure sur le long terme.

    Les projets qui visent un très haut niveau de qualité durent moins longtemps.

    RépondreSupprimer