Les développeurs sont des créatifs... que les organisations ignorent

Quel que soit le secteur, les piliers d'un site de eCommerce sont le marketing, le customer care et, of course, les développements informatiques. Combien de fois ai-je entendu des dirigeants ou des managers se plaindre de leurs développeurs qui selon eux manquaient d'implication, de sens de la relation client, ou de proactivité ?  Les modes d'organisation conduisent en effet trop souvent à la création de silos étanches au sein desquels chacun s'enferme dans un schéma prédéfini. Les marketeurs créent et définissent les besoins, les designers conçoivent les UI, le customer care remonte des bugs, et les développeurs codent ce qu'on leur demande de coder. Point barre. Et chacun se renvoie la balle, reprochant à l'autre des instructions trop succinctes, un manque de prise en compte du degré d'urgence, ou une sous-implication chronique.
Cela se produit partout, y compris dans de toutes petites entreprises, et - incroyable - même dans des organisations agiles. Les outils de ticketing ou de project management, JIRA, Redmine ou Trello accentuent souvent ce cloisonnement, au lieu de le réduire, l'entreprise devenant alors une machine folle dans laquelle 50% de l'effectif crée des tickets que l'autre moitié s'efforce de traiter, tel un matelot vidant sa barque à la petite cuillère en pleine tempête.

C'est stupéfiant de voire à quel point ce schéma se généralise, et entraîne un antagonisme parfois très virulent entre les différents métiers.

Alors, où est le mal ? Qu'est-ce qui fait que les gens se cantonnent à des rôles contraints au lieu de libérer leurs énergies et décupler leur talent ?

Cesser de considérer les développeurs comme des "pisseurs de code"

Trop souvent, le développeur est exclu de la phase de diagnostic d'un besoin et de conception d'une solution. Ce rôle est dévolu à un chef de projet, un product owner ou un fonctionnel qui va être chargé d'imaginer la solution, de la spécifier et de demander au développeur de la construire. De fait, ce dernier est réduit à un rôle d'exécutant ; et s'il émet un doute sur la solution envisagée, son attitude est généralement perçue comme de la mauvaise volonté ou un franchissement caractérisé de ligne jaune.
Du coup, le développeur "pisse son code" pour reprendre une expression vulgaire mais ô combien répandue, livre sa fonctionnalité, et advienne que pourra... Si ça marche tant mieux, si ça tape à côté, et bien c'est que le besoin a été mal exprimé.

Pourtant, à bien y regarder, développer c'est tout sauf exécuter. C'est imaginer, construire, résoudre... Abstraction faite de l'outil, ce n'est pas si loin que cela d'un métier d'artisan ou de concepteur. Les développeurs les plus talentueux que j'ai eu la chance de croiser dans ma carrière - et que je croise quotidiennement encore aujourd'hui dans mon équipe - je les considère comme des créatifs. Au même titre que les plus imaginatifs des D.A. d'agences de pub, ils sont capables de donner vie à une idée ou un concept en partant d'une feuille blanche.

Intégrer le développeur au processus de réflexion

Au long des projets que j'ai pu mener, j'ai constaté que le fait d'intégrer les développeurs dès les prémisses d'un projet résolvait un grand nombre de problèmes d'organisation. Lors de la phase d'expression de besoin, en écoutant le fonctionnel, le développeur va comprendre la finalité du projet. Et ça, c'est essentiel pour obtenir un travail de qualité : avoir une vision long terme de l'objectif ultime. Savoir pourquoi on se lève le matin.
Dans plusieurs cas, j'ai même fait rencontrer un client à mes développeurs. Quoi !!! mettre un développeur en face d'un client, quelle hérésie ! Mais non. Faire cela va permettre au dév de mettre un visage sur un problème, ça va l'aider à incarner son code, à lui donner une finalité. Et les développeurs n'aiment rien moins que de résoudre des problèmes.
Et lorsqu'on arrive à la phase de conception de la solution (le fameux "Comment"), si le développeur est impliqué, il pourra s'exprimer, écouter et partager son point de vue, ce qui favorisera son adoption du projet. En n'étant plus un simple exécutant, il s'appropriera le projet et il le portera. Il ne sera plus dans la posture de l'exécutant qui code en débranchant son cerveau : il deviendra la composante technique d'une équipe qui doit solutionner un problème, et ça ça change tout en termes d'implication. Plus tard, lorsqu'un bug sera remonté, l'équipe à laquelle il appartient devra trouver une solution. Là encore, il ne faut pas hésiter à ce que le dév se frotte au client, raisonnablement s'entend. Il ne s'agit pas de faire du support direct, mais il faut qu'il s'imprègne du degré d'urgence du client, qu'il soit interne ou externe. Derrière le ticket, il y a des humains, et ça il ne faut jamais le perdre de vue.

Flat management et holacratie

L'agilité ne se résume pas à coller des Post-Its au mur et à parler de sprints et de stories. C'est une philosophie de travail qui nourrit les organisations et les modes de management. Je crois aux vertus d'organisations souples, peu hiérarchisées, mais totalement responsabilisées. Des équipes dédiées à une problématique précise, qui ont la capacité d'agir avec une grande latitude, et qui conçoive elles-mêmes les solutions qu'elles mettront en oeuvre. Pas de micro-management, pas de définition de tâches par la hiérarchie. Un encadrement souple, bienveillant et dynamisant, et qui favorise l'intelligence collective. Je suis convaincu que ce type de fonctionnement produit des merveilles, en particulier dans les environnements constitués de développeurs et de spécialistes du digital.

Alors, qu'attendez-vous pour faire confiance à vos développeurs ?