Les chefs de produit agiles sont confrontés à des défis particuliers.
Voici quelques conseils pour passer du classique à l’agile.
Avoir une vision
Le changement est toujours le bienvenu dans le développement agile de produits. Si de nouvelles connaissances apparaissent au cours du projet, il est tout à fait judicieux de les intégrer dans le développement du produit, même si cela implique de modifier des parties existantes du produit, voire de jeter des pièces entières. Cela ne signifie pas pour autant qu’il ne faut conduire qu’à vue et ne penser qu’au prochain sprint. Essayez de développer avec l’équipe une vision commune pour le produit prévu. Une vision commune permet à l’équipe de savoir plus clairement dans quelle direction le produit doit aller. Une meilleure compréhension de la solution envisagée permet de faciliter les décisions relatives à la conception du produit.
Prendre des décisions
Prendre des décisions est l’une des tâches les plus épuisantes pour un être humain. Malheureusement, le développement d’un produit implique de nombreuses décisions importantes afin d’obtenir plus tard un produit réussi. Qu’il s’agisse de la hiérarchisation des caractéristiques ou du groupe cible final. Le chef de produit doit prendre les bonnes décisions le plus rapidement possible.
Voici quelques conseils pour prendre de meilleures décisions :
- Essayez de prendre toutes les décisions sur la base d’une vision du produit préalablement définie. Les décisions doivent également être en accord avec les objectifs de l’entreprise.
- Utilisez toutes les informations que vous pouvez obtenir, en particulier l’avis de votre équipe. Mais ne prenez pas de décisions dont vous n’êtes pas convaincu. Vous devez aimer votre produit.
- Si possible, validez les options sur la base de faits et de données plutôt que d’une intuition.
- S’il n’y a pas d’alternative parfaite évidente pour la décision, ne perdez pas trop de temps sur le processus de décision. Done is better than perfect !
Focus !
Cette partie est en fait destinée à votre chef. Chef de produit n’est pas un travail à temps partiel. Une grande énergie, une disponibilité pour l’équipe, le développement d’histoires d’utilisateurs et la prise de décisions demandent une attention totale.
Essayez d’éloigner de vous toutes les distractions inutiles. Minimiser les préparations inutiles de rapports et de parties prenantes. Veillez plutôt à ce que les parties prenantes participent aux rituels Scrum, comme les démos, afin de se faire une idée de l’état d’avancement du développement, et utilisez les artefacts existants, comme le Sprint Backlog et les Epics, pour communiquer la feuille de route.
Les délais sont pour toi, pas pour l’équipe
Le nouveau produit n’en est même pas encore au stade de la planification et il existe déjà des attentes très fortes au sein de l’entreprise quant au moment où tout doit être terminé. Qu’il s’agisse du début d’un salon où le nouveau produit doit être présenté ou d’un autre événement qui fixe la date de déploiement comme une ligne rigide dans le calendrier avant toute planification. Même si cette attente vous fait très mal aux épaules et que vous voulez porter ce fardeau dans l’équipe. Ce rendez-vous ne concerne que vous, le chef de produit, et non l’équipe. Grâce au processus Scrum, à la priorisation du backlog, au développement incrémental avec un produit “prêt à l’envoi” toutes les deux semaines, le chef de produit a tous les outils en main pour gérer les attentes concernant la portée du produit et, en théorie, être en mesure d’être productif à tout moment, en fonction du degré de maturité du produit. Seul le Product Owner a ce contrôle. L’équipe, en revanche, est la machine qui ne peut traiter au mieux les histoires des utilisateurs que dans le cadre du sprint. Toute date limite, en particulier celles qui sont directement liées à l’attente d’un ensemble de fonctionnalités spécifiques, distrait l’équipe et conduit à la frustration plutôt qu’à un momentum du type “Hé, on va y arriver”.
Voici quelques conseils :
- Évitez de communiquer des délais et de susciter des attentes implicites.
- Un backlog complet, classé par priorités et estimé, est une meilleure façon de se prononcer sur un déploiement qu’une chronologie Powerpoint avec des jalons hypothétiques.
- Adoptez une gestion réaliste des attentes dans toutes les directions.
- Assurez-vous et faites participer l’équipe lorsqu’il s’agit de planifier.
- Commencez toujours par les fonctions principales d’un produit et laissez les parties non essentielles se développer à la fin.
Le M signifie Minimal
Lorsqu’Eric Ries a écrit sur le sujet, il a défini le MVP comme suit : “Un Minimum Viable Product est la version d’un nouveau produit qui permet à une équipe de recueillir un maximum d’informations validées sur les clients avec le moins d’efforts possible”. Dans de nombreuses entreprises, le terme est ici mal utilisé, car beaucoup se réfèrent simplement à une première version d’un produit qui n’est même pas destinée à tomber entre les mains des clients. Beaucoup d’entreprises n’ont pas le courage de se lancer et de proposer aux clients un produit très réduit. Mais ici, vous perdez l’occasion de recueillir directement auprès du client des informations sur l’utilisation du produit et sur la pertinence de fonctionnalités supplémentaires. Peut-être arriverait-on à la conclusion que de nombreuses fonctionnalités prévues ne sont pas du tout nécessaires et qu’une amélioration des fonctions de base apporterait plutôt un avantage bien plus important pour le client.
