Lorsque j’ai commencé à travailler en tant que Product Manager, communiquer avec des développeurs a été plus qu’un challenge. Soyons honnêtes : sans background technique, quand on est Responsable Produit, Product Manager ou Product Owner, sortis d’école de commerce ou équivalent, on est très vite perdu, voire même effrayé, en écoutant le langage des développeurs, ce franglais bizarre composé d'une tonne d’acronymes en tout genre.
Attention ! L’objet de cet article n’est pas de vous pousser à suivre un MOOC en informatique. Il sera question ici de vous montrer comment communiquer de manière efficace afin d’améliorer la productivité et la créativité de votre équipe agile. Comment se faire comprendre ? Comment passer outre le jargon technique, et recueillir les précieuses idées qui émanent de vos développeurs ?
Ainsi comme tout bon Chef de Produit, j’ai commis à mes débuts plusieurs erreurs de “com”. Voici pour moi les points sur lesquels vous devriez faire attention :
Parler dans son propre langage, en somme, parler tout seul
La première des erreurs est de ne pas communiquer avec un langage commun entre le Métier et la Technique. J’ai été auparavant ce genre de Responsable Produit qui reste trop attachée à ses “buzzwords” et qui ne vulgarise jamais son discours au public technique.
Exemple :
“Il nous faut une application qui traite des rejets de délégation en Santé Collective”
versus
“Il nous faudrait une application qui puisse vérifier si un contrat donné, possède les n critères imposés par la loi X”
Je pense aussi au fait d’utiliser maladroitement des termes équivoques qui ont bien souvent un tout autre sens d’un point de vue technique : “incrémenter”, “archiver”, “historiser”, “déployer”. Rappelez vous bien que des formulations évidentes pour certains, ne le sont pas systématiquement pour les autres.
Bref, “à paroles lourdes, oreilles sourdes”.
Lorsque l'on n'est pas assez clair dans ce qu'on dit on ne peut pas espérer être compris. Vous courrez ici le risque de vous faire mal comprendre et donc a fortiori de faire perdre du temps à tout le monde.
Testez plutôt ces actions:
- Expliquez les choses avec des mots simples et compréhensibles par tous les membres de l’équipe
- Reformulez systématiquement tout ce que l’on vous dit afin de déceler les éventuelles zones d’ombre
- Ne complexifiez pas vos propos avec des notions n’ayant de sens que pour vous
- N'utilisez pas des concepts techniques que vous ne maîtrisez pas. Votre équipe vous rappellera cette faiblesse. Soyez plutôt curieux, posez un maximum de questions
- Créez vous un glossaire commun
Formuler des demandes non justifiées
Voilà l’erreur la plus répandue dans les structures qui considèrent encore leur équipe de développement comme une fonction support à leur métier. Les demandes sont présentées aux développeurs sans objectif ou but précis.
Exemple :
“Nous voulons ajouter cette fonctionnalité parce que c’est trendy, tout le monde le fait !”
versus
“Nous voulons A/B tester cette fonctionnalité qui s’avère être une bonne pratique du secteur et voir si elle aura un réel impact sur nos problèmes de rétention ”
Il en est de même pour les contraintes de temps imposées sans avoir pris le temps de réaliser l’ampleur des tâches impliquées dans un développement donné.
“Nous voulons cette fonctionnalité déployée sur tous les devices pour Noël”
versus
“Le département Monétisation nous impose un time to market pour Noël car les achats y sont les plus nombreux. Quelle version de la fonctionnalité pouvons nous envisager face à ce délai ?”
Trop souvent confrontée à ce manque de rationalité, votre équipe va prendre l’habitude de décrédibiliser vos demandes. Comprenez aussi que les développeurs sont preneurs de feedbacks et autres KPI sur les fonctionnalités qui ont été mises en production. Prenez du recul et essayez de :
- Formuler vos demandes en problèmes. Cela permettra à votre équipe d’être plus créative et de vous proposer plus facilement des solutions alternatives.
- Demander une évaluation de la charge de travail pour les différentes versions de votre fonctionnalité avant d’annoncer une date butoir qui pourrait engendrer un surplus de stress (Extreme quotation par exemple)
Avoir un ton présomptueux
J'ai beaucoup hésité avant de rajouter ce point. Mais voyant encore un bon nombre de Responsable Produit s'exprimer avec un ton présomptueux, j’avais envie de rappeler l’humilité qu'impose tout travail collaboratif. Laisser penser, par votre ton de voix et votre attitude que vos développeurs bossent pour vous et non avec vous, engendrera au moins un des problèmes suivants : absence d’esprit d’équipe, frustration humaine, rétention d’information, esprit de compétition mal placé.... Est-ce que la rancoeur chez un développeur est source de productivité ? Non, alors essayez de vous remettre en question :
- Exprimez vous tel un membre à part entière de l'équipe
- Ne dites pas aux autres ce que vous ne voudriez pas qu’on vous dise
- Pour les plus doués, tentez la “cool” attitude
Voilà, j’espère vous avoir fait prendre conscience que la communication d’un Product Owner ou Product Manager est importante au sein d’une équipe agile. Vous avez par la simple parole le moyen de rendre les interactions entre équipes plaisantes et d’optimiser la créativité de vos collaborateurs.
Sources :
- Votre équipe d'ingénieurs vous crée des problèmes, et voilà pourquoi.
- Marketing vs. Engineering: 5 Rules For Peaceful Coexistence
- Kate Matsudaira, “The Engineer Whisperer,” Knows The Secrets of Working with Technologists
- This is why you need to learn how to talk to developers
- How do you earn the respect of the engineering team as a product manager or someone outside that team?
- How to Speak Engineer
- Engineer-speak vs. Marketing-speak: Talking to engineers successfully
