Pousser le changement


26 07 2006

Dans le livre Peopleware, le chapitre « Making change possible » parle de la difficulté à faire changer les choses dans un projet (aspect aussi bien technique que méthdologique).

J’ai à plusieurs reprises travaillé avec des équipes ayant un niveau de technicité différent.Par exemple, des équipes travaillant sans un gestionnaire de sources.

Ma première réaction est l’étonnement :

Mais comment pouvez vous travailler avec des conditions pareilles ?

(Si l’on y réfléchit, on peut très bien travailler sans gestionnaire de conf, il suffit de faire plus attention c’est tout 😉 ).

Passé cette réaction, la prochaine étape est de montrer à l’équipe l’intérêt de cet outil et leur faire intégrer dans leur process de développement.

Pour cela, j’avais tendance à donner l’ensemble des avantages, dire que tout sera plus beau et bien mieux. Ce qu’on peut représenter par le schéma suivant :

 ANCIENNE FACON ==> NOUVELLE FACON

Et bien, cette technique en pratique donne de mauvais résultats (incroyable c’est le sujet de ce post)…

Par exemple, la mise en place des projets sur le gestionnaire est difficile au début, des nouveaux mots sont à maitriser pour comprendre. La syntaxe n’est pas évidente non plus et les erreurs sont fréquentes. Résultat, on passe beaucoup plus de temps à gérer ses sources, temps qui était disponible auparavant pour d’autre chose…

Au final, la réalité s’approche plutôt du schéma suivant :

 ANCIENNE FACON ==> CHAOS ==> APPRENTISSAGE ==> NOUVELLE FACON

Le passage obligé mais souvent oublié c’est l’étape chaotique où les développeurs râlent car cette nouvelle complexité ne leur apporte aucun avantage. Ils ne voient que les défauts et aucun intérêt… Cette étape difficile est souvent le moment où se repose la question cruciale :

Est-ce que vraiment ca valait le coup, parce qu’on peut encore revenir en arrière sinon !

Finalement avec un peu de volonté et de la pratique, tout le monde finit par piger le truc et cette nouvelle façon de travailler plaît !

La leçon à retenir c’est que lors d’un changement, il faut être très clair sur plusieurs points :

  • Oui ça sera mieux (on y croit)

MAIS

  • Il y aura une période incertaine et plus difficile dont il ne faut pas avoir peur
  • Il faut accepter de sortir de notre sécurité actuelle pour tenter de nouvelles choses
  • Le changement ne doit pas être un couteau sous la gorge et il faut avoir le droit à l’erreur

Billets similaires

Actions

Informations

Une réponse à “Pousser le changement”

2 07 2007
Julien Carnelos Blog » Les 6 signes d'un bon développeur (16:35:04) :

[…] maxime du bon développeur et du mauvais développeur, je cite souvent une étude du livre Peopleware qui explique que l’on retrouve un écart de productivté entre développeurs […]