- Quand les développeurs disent non, savoir y répondre aide les product managers à affirmer leur autorité et à atteindre leurs objectifs
- Lorsqu’ils disent qu’une fonctionnalité ne peut pas être implémentée dans le délai prévu pour des raisons techniques, les bonnes questions peuvent aider à débloquer la situation
1. Existe-t-il d’autres solutions techniques pour construire cette fonctionnalité ?
- Il existe plusieurs façons de construire une fonctionnalité, et la première approche envisagée n’est pas toujours la meilleure
- Les développeurs veulent souvent créer des fonctionnalités impressionnantes avec les technologies les plus récentes, mais cela peut conduire à du sur-ingénierie plutôt qu’à une optimisation pour la simplicité
- Des développeurs disposant d’un ensemble de compétences spécifique peuvent ne pas percevoir des solutions plus simples qui sortent de leur champ de connaissances
- Il est donc utile d’amener les ingénieurs à réfléchir de manière plus créative aux solutions techniques
- Certains des meilleurs product managers avec qui j’ai travaillé avaient une compréhension technique et une connaissance de l’environnement suffisamment solides pour poser des questions pertinentes qui poussaient les ingénieurs à sortir du cadre
2. Si vous deviez proposer une solution avec ces contraintes, que feriez-vous ?
- Si les développeurs soulèvent des objections à la solution que vous avez proposée, demandez-leur quelle serait leur solution
- Les développeurs sont une véritable réserve de créativité et d’innovation, et leur demander s’il existe une version plus simple de la fonctionnalité leur donne l’occasion de penser de façon créative
- Quand ils comprennent le cœur du problème, les développeurs peuvent réfléchir de manière créative et trouver une solution qui fonctionne dans les contraintes du projet
3. Peut-on envisager une approche par étapes pour cette fonctionnalité ?
- Lorsqu’on vous dit qu’une fonctionnalité est impossible à implémenter en raison de sa complexité technique, demandez si le projet peut être découpé en étapes avec des dates de livraison différentes
- Il est tentant de vouloir livrer d’un seul coup une vision ambitieuse, mais une approche par étapes est plus itérative et permet d’apporter plus rapidement des résultats concrets
- Les priorités peuvent changer, et une approche par étapes permet d’ajuster avec les développeurs les fonctionnalités à ajouter ensuite
4. Quels obstacles peut-on supprimer ou résoudre pour rendre ce travail possible ?
- C’est une question à poser face aux objections liées aux ressources : lorsque les développeurs invoquent des ressources limitées (par exemple le temps ou le nombre de développeurs disponibles), retirez activement certaines tâches pour libérer leur temps
- Méthodes possibles : supprimer complètement certaines tâches, prendre en charge soi-même des tâches qui ne nécessitent pas de développeur, gérer la communication avec d’autres équipes et/ou des tiers, ou faciliter le travail en prenant en main le process et en supprimant des fonctionnalités legacy
Conclusion
- Il peut être inconfortable de « pousser » quand des développeurs disent « non », mais cela peut aussi vous faire gagner davantage de respect
- Il faut creuser un peu plus pour comprendre pourquoi les ingénieurs s’y opposent, identifier ces raisons et lever les objections une par une
- Toutes ces questions sont pertinentes parce qu’elles reconnaissent les difficultés et contraintes spécifiques auxquelles les ingénieurs peuvent être confrontés lors de l’implémentation d’une fonctionnalité
- Elles montrent aussi clairement que vous êtes prêt à faire votre part pour aider l’équipe et le projet, que ce soit en mettant la main à la pâte pour faire le sale boulot ou en ajustant les exigences et le calendrier
8 commentaires
Au final, tout dépend de la manière dont on s’ajuste.
Merci pour ce très bon contenu.
Si on pose des questions à partir des points ci-dessus, on pourra vite faire le tri entre ceux qui disent simplement non parce qu’ils n’ont juste pas envie de le faire.
En tant que PM/PO, il y a deux méthodologies qui m’ont aidé lorsque je jouais un rôle de coordination entre les équipes métier et les équipes IT sur un projet.
Bien sûr, cela suppose aussi bien côté métier que côté IT qu’on soit capable de se comprendre.
La première, c’est d’avancer par étapes.
La deuxième, c’est de réduire le périmètre.
Ce sont ces deux approches.
Dans la conduite d’un projet côté métier ou côté IT, la plus grande difficulté, c’est le délai.
Le délai est fixé, et très souvent le volume semble impossible à réaliser dans ce délai.
Dans ce cas, il faut procéder de manière progressive : phase 1, 2, 3… avec un calendrier séquentiel. On met les fonctionnalités les plus importantes en phase 1, les moins importantes en phase 2, etc.
Mais pour les projets qu’on ne peut pas découper ainsi, c’est-à-dire ceux qui doivent être mis en production d’un seul coup,
il faut réduire le périmètre pour l’adapter au "délai". Parmi ce qui entrerait dans les phases 1, 2, 3, il faut supprimer tout sauf les fonctionnalités vraiment nécessaires.
Avec ces deux méthodologies, la plupart des équipes métier/IT qui sont capables de se comprendre sont d’accord.
Parce que c’est toujours mieux qu’un projet qui part en vrille et se faire remonter les bretelles par son supérieur.
Bon…
Courage à tous ^^
PS :
Il y a aussi un dernier petit assaisonnement.
Même en utilisant les deux méthodes ci-dessus, il arrive souvent que les développeurs restent réticents.
Dans ce cas,
"Faisons un point vers le milieu du projet. S’il semble qu’il faille plus de temps, je prendrai la responsabilité d’obtenir une prolongation du délai"
et souvent, le visage des développeurs se détend.
Du coup, quand on fait ce point à mi-parcours, dans 95 % des cas il n’y a finalement pas besoin de plus de temps.
Et puis souvent, une fois que les développeurs commencent vraiment à coder, ça avance vite.
En tant que personne dont le rôle implique de se coordonner avec des développeurs, j’aimerais travailler avec des développeurs avec qui ce genre d’échange est possible. Jusqu’ici, je n’ai rencontré que des développeurs qui disent d’emblée que ce n’est pas possible, et ça me désole. Or, à force d’essayer de les convaincre et de poser des questions, il s’avère dans la plupart des cas qu’il existait simplement une méthode qu’ils ne connaissaient pas...
Hahahahahaha, ça fait mal au cœur..
Questions qu’un ingénieur devrait se poser avant de dire « NO ».
Ce sont aussi, à mes yeux, des questions qu’il est vraiment très utile de se poser à soi-même.
Avant d’être des ingénieurs, ce sont des personnes. Je suis d’accord que le réflexe de dire systématiquement non, en tant qu’ingénieur, pose problème, mais si les PM/PO ont ce genre de questions en tête, cela peut être d’une grande aide.