Aujourd’hui, nous allons parler d’un classique, vous l’aurez compris au titre : la fracture entre les développeurs et le marketing. En cas de doute, cherchez si vous n’avez jamais ressenti une certaine « mauvaise ambiance » entre les deux équipes ; de la pique « de toute façon, vous les devs… », jusqu’à l’explosion « put$*% mais quel est le c*$ qui a promis cette feature ?! ».
Je suis certain que maintenant, vous voyez du genre d’ambiance dont je parle. Alors comment se fait-il que ce type de fracture soit monnaie courante dans les sociétés tech ? Comment faire pour remédier à cette situation ? À quoi devons nous aspirer ?
Afin de répondre à toutes ces questions, je vous propose que nous abordions ce problème comme une maladie ; une maladie qui ronge peut-être votre entreprise.
Diagnostic
Tout d’abord, nous devons établir le diagnostic de cette fracture, dépasser le « c’est cassé » et comprendre « pourquoi ça casse ». Cela nous permettra de traiter le problème sur le fond plutôt que de maintenir les apparences en traitant simplement les symptômes.
Appartenance tribale
Ce premier point est probablement le plus simple, mais aussi le plus surprenant ; nous avons tous besoin d’appartenir à une tribu. Dans notre quotidien, bien évidemment, nous nous rassemblons autour de points communs, intérêts, compétences… et cela est également vrai au travail. Si vous pensez que j’exagère en parlant de « tribu », je vous propose que nous creusions un peu plus le sujet.
Le code vestimentaire est un signe visible d’appartenance à une tribu. Vous croiserez rarement quelqu’un du service marketing en short, sauf pour les « casuals friday » peut-être ; même combat pour les développeurs, pas de costume sauf sous la contrainte, ou un entretien d’embauche, méfiez-vous !
Les petits rituels de type « pause café/clopes » sont aussi de bons indicateurs d’appartenance. Certes, tout le monde prend une pause, mais là n’est pas l’essentiel ; observez les individus qui se synchronisent pour cette pause : toujours les mêmes.
L’utilisation du même langage est probablement le point le plus criant de l’appartenance tribale ; tellement criant, qu’il a sa petite section consacrée dans la suite de cet article.
Le dernier point à soulever est que pour former une tribu au sein d’une société, le moyen le plus efficace est encore d’avoir un ennemi commun. Au sein d’une société tech, cela peut-être un manager particulièrement chiant, ou alors une tribu rivale… C’est en général là que les désignations « marketeux » et « geeks » prennent place.
Langage
Comme je vous le disais plus haut, le langage est un signe d’appartenance majeur à une tribu ; nous nous regroupons autour de nos acronymes, termes techniques et autres connaissances communes. C’est une bonne chose, jusqu’au moment où il faut communiquer avec une autre tribu ; je pense d’ailleurs, que l’on perd la majeure partie de l’information à cet instant précis.
Prenons, vraiment au hasard, l’exemple du cahier des charges ; pour moi, il s’agit de la cristallisation même de la non-communication entre les individus. Un individu A a passé des jours, voire semaines, à remplir un document pour essayer d’exprimer ce que pourrait vouloir un individu B (l’utilisateur), afin qu’un individu C lise ce pavé et réalise l’app correspondante.
Vous avouerez que vu comme ça, tout cela semble plus ou moins hasardeux ; je vous entends déjà : « oui, mais si le document est bien normalisé pas de soucis ». Si, le problème tient au fait que la bonne communication entre A et C, sans parler de la satisfaction de B, tient à l’interprétation d’un bout de papier.
À l’inverse, lorsqu’un bug dans l’application survient, essayez de tirer une explication simple et sans jargon technique d’un développeur. Même si certains se cachent derrière ce jargon pour noyer le poisson face à leurs responsabilités dans l’affaire, il faut avouer que la vulgarisation est probablement l’exercice le plus difficile qui soit.
Absence de vision commune
Une autre source de cette fracture peut-être l’absence d’une vision commune pour unir ces équipes. Ne confondez pas le fait de « travailler dans la même entreprise » et le fait de « travailler ensemble ». J’admets que le raccourci est tentant, surtout pour les dirigeants, mais cela relève de l’utopie ; un contrat de travail, encore un bout de papier, ne suffit pas à unir des individus dans leur collaboration.
Ce manque de partage de vision vient en partie du fait que chacun fait son travail pour atteindre des objectifs propres et ne va pas plus loin :
- le développeur aime résoudre des problèmes, trouver un prétexte pour coder et exercer son savoir-faire. Néanmoins, n’allez pas croire que nous produisons des bugs exprès pour coder ; ce que nous aimons encore plus que le code, c’est le code propre. Cela peut relever de la maniaquerie pour les plus atteints d’entre nous.
- le marketeur vise à créer le besoin auprès de ses cibles, ou plutôt le faire émerger. Ses propres défis se situent dans les métriques autour de l’application, la gestion du timing de publication, mais surtout la compréhension de ses cibles.
Le manque d’intéressement au métier de l’autre est aussi une partie de ce problème. En effet, sans s’intéresser à ce que fait quelqu’un, il est difficile de considérer son apport dans le projet ; c’est à ce moment où les clichés tels que « les marketeux ne font que brasser de l’air » et « les devs sont des aliens ne parlant pas notre langue », apparaissent.
Prescription
Ok, si l’on résume, nous avons donc deux tribus qui ne parlent pas la même langue et qui, en plus, ne regardent pas dans la même direction ?! Ne paniquez pas, l’ingénieur qui est en moi vous le dit : ̶p̶é̶t̶e̶z̶ ̶u̶n̶ ̶c̶o̶u̶p̶- à tout problème, sa solution.
Équipe > tribu
Premier conseil pour gérer les différentes tribus existantes au sein d’une société : n’essayez pas de les exploser. Ces regroupements tribaux se font naturellement et nous permettent d’assigner un rôle aux uns et aux autres. La seule chose que vous gagnerez à séparer des personnes qui s’entendent bien, c’est un mauvais fonctionnement.
Non, l’astuce réside à créer quelque chose de plus grand, plus important que la tribu : l’équipe. En effet, il faut essayer de faire résonner les individus en termes d’équipe projet plutôt que des départements. Par exemple, on ne file pas l’app au « département marketing » pour qu’ils testent ; l’équipe doit avoir un membre ayant les capacités marketing pour évaluer l’app. C’est même assez basique lorsqu’on y pense : pour réussir un projet, plusieurs types de compétences sont nécessaires !
Prenons, encore au hasard, le cas de l’équipe agile où le rôle de Product Owner peut être assuré par un marketeur ; cela permettrait plusieurs choses telles que :
- l’augmentation des interactions entre les individus ; recréant ainsi le lien social indispensable à une bonne collaboration.
- la possibilité de voir que le travail de l’autre n’est pas aussi obscur que ce que l’on pense.
- l’engagement des individus autour d’un but commun afin de les fédérer.
Dialogue : implémenter une interface commune
Il n’y a pas de recette miracle, surtout pas lorsque nous parlons de compréhension entre individus ; la paix dans le monde, ce n’est pas pour demain ! En attendant, il est possible d’établir une interface de dialogue commune afin de définir des bases saines pour la communication.
Pour nous référer à notre problème précédent, autour de l’expression fonctionnelle, une première étape est de définir un formalisme d’expression simple. Les méthodologies agiles, voir souplesse VS agilité, recommandent l’utilisation des User Stories pour la transmission des besoins utilisateurs. Leur convention permet d’un côté : une expression simple ne permettant pas de partir dans des détails interminables ; de l’autre : une portion suffisamment petite pour être digeste et plus simplement implémenter. Adieu le cahier des charges de plusieurs milliers de pages !
Dans le cas d’une communication depuis la technique vers le fonctionnel, essayez de garder des règles simples :
- la personne en face souhaite des solutions, pas une dissection des problèmes que vous rencontrez.
- si vous devez fournir une estimation, ajoutez le pourcentage d’incertitude après le chiffre initial, exemple : 2 j + ou – 20 %. Cela permettra à votre interlocuteur de réaliser qu’il s’agit d’une estimation, non d’un engagement.
- jargon technique interdit ; sans aller jusqu’à supprimer tous les mots techniques, l’essentiel est de transmettre l’information, n’hésitez pas à avoir recours à un tableau blanc pour schématiser.
Maintenant, il ne vous reste plus qu’à ne pas vous tromper de sujet dans votre communication : lorsque l’on parle du projet, il s’agit TOUJOURS de l’intérêt de l’utilisateur.
Vision : UX Design à la rescousse
Le dernier point évoqué est également celui qui vous permettra de conserver une communication efficace au sein de votre équipe : toutes les discussions doivent être recentrées autour des utilisateurs.
Et qui dit « utilisateur », dit « expérience utilisateur » ; et oui, l’UX est une arme redoutable lorsqu’il s’agit de calmer les débats. Attention : n’allez pas croire que les UX Designer sont des espèces d’arbitres, loin de là ; simplement, si vous ne perdez pas de vue votre objectif qu’est la complétion d’un besoin utilisateur, vous avez beaucoup moins de chance de vous égarer en chemin dans des débats stériles.
Un bon moyen, par exemple, peut être de faire définir à l’équipe des personae utilisateurs de façon à ne pas oublier qu’ils font tous ça pour des personnes.
N’oubliez pas qu’il est inutile de dépenser des ressources et de l’énergie si aucun besoin n’a été émis de l’autre côté. Personnellement ce que je déteste le plus, c’est perdre mon temps sur une fonctionnalité qui se révèle au final inutile…
A garder en tête
Encore une fois, tous ces retours sont tirés de mes expériences personnelles et de ma réflexion sur le sujet. Les solutions sont loin d’être absolues ou exhaustives, cela est d’autant plus vrai lorsque l’on parle de relations humaines.
Le point essentiel à retenir est qu’il faut créer du tissu social entre les individus ; ce tissu ne peut être créé artificiellement, mais il est possible d’encourager sa fabrication, notamment à travers la proposition d’activités communes (team building) . Comme je vous le disais dans mon précédent article, un baby-foot n’est pas un avantage concurrentiel en terme de recrutement, en revanche, c’est un bon générateur d’interactions !
Si vous désirez avoir l’avis d’un marketeur sur le sujet, je vous recommande d’écouter le point de vue de Stan Leloup (Marketing Mania) dans cet épisode de l’excellent podcast de Benoît Gantaume (Artisan Développeur).
Merci de m’avoir lu jusqu’au bout : si l’article vous a plu, partagez-le afin de m’aider à le diffuser !
