Je déjeunais, tranquillement (Jardin du Palais Royal, il y a pire), assis sur un banc.
S’assoie juste derrière moi une jeune fille et un garçon.
La fille parle fort, donc je l’entends :
Bon tu vois, machin, je l’aime pas. Il est dev, il doit rester à sa place.
Nous on a passé des heures à définir une fonction, on va pas tout remettre en question parce qu’il se pose des questions.
On a défini le besoin, à lui de le développer, point.
Le « dev » n’a qu’à s’exécuter, et développer la magnifique fonction définie par les équipes marketing, ou métier, ou produit (suivant les organisations).
Quelle erreur !
Si vous faites ça, vous vous privez de beaucoup de choses :
- Il est très démotivant d’être traité comme un simple exécutant. Vous risquez de faire partir les meilleurs, vous risquez des postures d’oppositions systématiques, vous risquez la montée de tensions entre les équipes, chacune positionnée en sniper vis à vis de l’autre ;
- Vous perdez une bonne partie du « cerveau » de l’équipe technique. Vous ne lui demandez pas son avis ? Très bien, elle va développer en suivant les spécifications. Mais attention, j’espère que vous aurez bien pensé à tout…
Il faut bien comprendre que, certe, vous avez passé du temps à définir, analyser une fonction. Mais l’équipe technique va passer encore plus de temps à la développer.
Il est fondamental qu’elle s’approprie le besoin et la solution.
Les « devs » peuvent remettre en question les choix ? Et pourquoi pas ? Si votre travail est très bien préparé, les fondamentaux doivent résister. Et si l’équipe technique propose des améliorations, c’est parfait ! Ils se sentiront complètement intégrés dans le processus, et seront bien plus motivés pour faire un « truc qui marche », et la solution sera meilleure que ce qui était prévu au début.
C’est une des raisons qui font qu’on doit bosser en méthode agile. L’équipe métier n’est pas séparée de l’équipe technique. Les équipes bossent ensemble, de manière itérative.
Alors, ça se passe comment chez vous ?
