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 ?
Le problème de l’intégration de toutes les strates de l’entreprise dans un projet est séduisant mais peut aussi se révéler paralysant car il y aura forcément des personnes qui penseront différemment et qui mettront leur ‘véto’ pour telle ou telle décision. A un moment, il faut bien trancher. Il faut bien que quelqu’un prennent une décision et que toute le monde « rame dans la même direction ». Si chaque marin dans la galère devait discuter du cap à emprunter au lieu d’exécuter les ordres du capitaine, peu de bateaux quitteraient le port.
Certes écouter les avis de tous peut être intéressant, mais au bout d’un moment, il faut bien choisir et que tout le monde s’en tienne au choix retenu.
Dans les petites équipes, il est plus facile d’intégrer les avis de chacun. Mais dès que la structure de l’entreprise devient importante, cela n’est plus vraiment possible.
Enfin, c’est mon humble avis.
William
Je connais un développeur indépendant travaillant pour de grosses banques qui remarque parfois d’énorme manques dans la création de site ou programme. Conscienceux, il fait les remarques et est force de proposition, mais malheureusement, c’est toute une grosse machine qui ne réagit pas vite et pas facilement. Du coup, les erreurs doivent être produites malgré tout, ce qui est regrettable.