Une des choses que j'ai vu assez souvent, dans les organisations où la gestion de produit (et une méthode de travail agile) est introduite, est que les gens se divisent souvent en deux camps. Le premier camp est constitué de ceux qui résistent à la nouvelle façon de travailler (soit par manque de compréhension ou de communication, soit parce qu'ils ne sont pas convaincus des avantages), et le second camp est constitué de ceux qui sont désireux d'embarquer et de l'appliquer à tout ce qu'ils font.

Le premier groupe est un sujet pour un autre article de blog sur lequel je travaille, alors retenez cette idée !

En ce qui concerne le deuxième groupe, j'ai vu beaucoup d'exemples d'équipes en dehors du produit et de l'ingénierie, qui peuvent voir comment l'approche améliore la façon dont les fonctionnalités et les capacités du produit sont livrées, et qui veulent appliquer la même approche à leurs propres équipes. J'ai probablement été un peu cynique à l'égard de cette approche dans le passé, la considérant comme une tentative de faire rentrer une cheville carrée dans un trou rond (c'est-à-dire prendre quelque chose qui a été conçu pour livrer des changements de logiciels d'une manière agile, et essayer de l'appliquer dans un espace qui pourrait naturellement ne pas se prêter à l'agile), mais en réalité il y a beaucoup d'éléments de la gestion des produits qui peuvent être appliqués plus largement à une entreprise, indépendamment du fait que le changement doit être livré d'une manière agile ou plus en cascade.

Alors, quels sont les éléments de base de la gestion de produit qui peuvent être appliqués plus largement ?

Communication

Les diverses cérémonies, qui sont utilisées dans la gestion de produit agile et la livraison de logiciels, sont généralement là pour améliorer la communication et la collaboration. Bien que certaines d'entre elles soient très spécifiques à la livraison de changements techniques (par exemple, les sessions de raffinement - pour clarifier les exigences fonctionnelles, les critères d'acceptation et le dimensionnement d'un produit livrable), certaines peuvent être utiles à toute équipe.

Les réunions : Une courte réunion régulière (par exemple, quotidienne ?) avec l'équipe pour partager ce sur quoi chacun travaille. Soyez bref (par exemple, 10 à 15 minutes). Soyez concis (nous n'avons pas besoin de l'histoire de la vie de chacun). Si des sujets sont soulevés qui nécessitent une discussion plus approfondie (ce qui fait partie de l'objectif des stand-ups), mettez-les en ligne avec les personnes concernées. C'est un excellent moyen de s'assurer que tout le monde est d'accord et que personne n'est bloqué.

Retros : Une réunion semi-régulière avec l'équipe pour discuter de ce qui va bien, de ce qui va moins bien, de ce que nous voulons faire davantage, de ce que nous devrions faire moins, etc. Tout le monde devrait participer à ces séances, qui constituent un moyen très utile de détecter rapidement les problèmes et d'inciter les membres les plus discrets de l'équipe à s'exprimer.

Démonstrations/showcases : Expliquez au reste de l'entreprise ce que vous avez fait et ce sur quoi vous travaillez. C'est un excellent moyen de rehausser le profil de votre équipe au sein de l'entreprise, de vous assurer que vous êtes reconnu pour le travail que vous faites, et de recueillir les commentaires.

Orientation client

Cela va sembler évident, mais assurez-vous que vous vous concentrez sur vos "clients", plutôt que sur un ensemble de priorités imposées. Qui sont vos clients, et quels sont les problèmes que vous essayez de résoudre pour eux ? C'est ce qu'on appelle la découverte du produit. L'identité de vos "clients" dépend du type d'équipe que vous êtes. Et vous aurez besoin d'un moyen de mesurer l'efficacité avec laquelle vous résolvez leurs problèmes.

Par exemple, si vous êtes une équipe de service clientèle, votre client sera le consommateur final qui interagit avec tous vos services. Les mesures que vous voudrez probablement suivre existent déjà, et pourraient être des choses comme:-

Combien de clients sont capables de résoudre eux-mêmes leurs problèmes sans avoir à contacter le service clientèle ?

Quel est le taux de satisfaction des personnes qui ont dû contacter votre équipe ?

Des mesures telles que le temps d'appel moyen, bien qu'utiles d'un point de vue de l'efficacité opérationnelle (par exemple, elles permettent de mettre en évidence les collègues qui pourraient avoir besoin d'une formation supplémentaire, etc.), ont tendance à être très axées sur les coûts et ne sont pas susceptibles d'être une bonne mesure de la satisfaction de vos clients. Dans la plupart des endroits où j'ai travaillé, les équipes de services à la clientèle ont toujours été soumises à une pression importante pour réduire les coûts, mais plutôt que de se concentrer entièrement sur "comment puis-je réduire les coûts le plus possible", une simple reformulation de cette question en "comment puis-je offrir la meilleure expérience client de manière rentable" peut conduire à prendre des décisions différentes sur ce qu'il faut réellement faire.

Si vous êtes une équipe humaine, vos "clients" sont très probablement des collègues, et vous devriez donc réfléchir à la manière d'évaluer leurs besoins (quels sont leurs points sensibles, quelles sont les choses qui pourraient être facilitées pour eux, quels sont les problèmes qu'ils rencontrent dans l'exercice de leurs fonctions) et à une mesure appropriée de votre réussite (par exemple, la satisfaction des collègues).

L'essentiel est de s'assurer que votre équipe se bat pour vos "clients" (en veillant à ce qu'ils aient voix au chapitre) et qu'elle est prête à contester tout ce qui pourrait les désavantager.

Cependant, tous les "clients" ne sont pas égaux, et il se peut que les besoins d'un groupe de clients (par exemple, les consommateurs finaux payants) soient plus importants que ceux d'un autre. sont considérés comme plus prioritaires qu'un autre (par exemple, les collègues).

Être axé sur les données

Prendre des décisions fondées sur des faits plutôt que sur des opinions est un facteur de réussite avéré. Cela ne veut pas dire que l'expérience n'est pas précieuse. L'expérience peut aider à formuler des hypothèses initiales sur les besoins de vos "clients", mais vous devez toujours accepter que vous puissiez vous tromper. C'est pourquoi vous décidez des paramètres que vous essayez d'atteindre et vous utilisez des données (enquêtes, paramètres, analyse comportementale, etc.) pour déterminer dans quelle mesure vos actions améliorent ces paramètres. Si vous n'améliorez pas ces indicateurs (et s'il s'agit des bons indicateurs, alignés sur l'organisation au sens large), vous ne travaillez probablement pas sur les bonnes choses.

Si vous n'êtes pas en mesure de suivre la mesure que vous essayez d'améliorer, vous devez soit trouver un moyen de suivre cette mesure, soit choisir une mesure qui peut être suivie et qui est suffisamment similaire sur le plan sémantique.

Gestion du travail

Toutes les équipes devraient avoir un moyen de rassembler les éléments qu'elles sont chargées de fournir, afin de pouvoir les suivre, de les communiquer au reste de l'entreprise et de les ordonner (voir la section "Hiérarchisation" ci-dessous).

Qu'il s'agisse d'une feuille de route, d'un plan de projet ou autre, cela dépend entièrement de la complexité de cet ensemble de choses. Par souci de clarté, les éléments de travail qui doivent être livrés de manière séquentielle et dans des délais relativement fixes, à la manière d'une cascade (c'est-à-dire faire la chose A, puis la chose B, puis la chose C) sont souvent mieux gérés dans des plans de projet. Ce n'est pas de la gestion de produit, et dans les grandes organisations, il y aura une fonction PMO responsable de la livraison de grands flux de travail inter-équipes, donc je n'ai pas l'intention d'en parler, mais je tiens à souligner que pour certaines équipes, la gestion de projet traditionnelle est encore tout à fait appropriée.

Par exemple, si vous construisez une maison, vous ne pouvez pas commencer à construire avant d'avoir des fondations, vous ne pouvez pas installer l'électricité avant d'avoir des murs, vous ne pouvez pas peindre avant d'avoir plâtré, etc. Vous ne pouvez pas vraiment construire une maison d'une manière agile.

Cependant, il existe des moyens plus légers de gérer les "choses" dans le monde de la gestion de produit qui sont facilement réutilisables par d'autres équipes.

Feuilles de route

Une feuille de route peut être aussi simple qu'une liste hiérarchisée de choses sur lesquelles vous prévoyez de travailler. Vous pouvez même avoir une idée du moment où ces éléments seront travaillés, mais lorsque vous commencez à avoir des dates de livraison très précises, vous devez faire attention à comprendre pourquoi il y a un besoin pour une date (qui sera généralement une meilleure estimation), et utiliser des approximations plutôt que des dates exactes (qui sont une fausse promesse).

Vous n'avez pas besoin de payer un outil de feuille de route coûteux pour suivre une feuille de route simple. Il existe de nombreux outils simples (par exemple, Trello) qui vous permettent de gérer facilement une liste de priorités.

Backlogs/empreintes

Si vous avez une liste de choses qui change régulièrement (par exemple, si vous recevez constamment des demandes de nouvelles choses sur lesquelles travailler), c'est là qu'un backlog peut être utile. Des outils comme Jira sont le moyen le plus courant de gérer ces backlogs de demandes, car ils fournissent une piste d'audit complète pour l'avancement de chaque élément. Soyons honnêtes, beaucoup d'équipes le font déjà (par exemple, elles vous demandent de créer un "ticket" avant de travailler sur quelque chose), mais la principale différence que je vois est qu'elles devraient appliquer une forme cohérente de priorisation à cette liste, basée sur des mesures centrées sur le client.

Lorsque vous essayez d'empêcher votre équipe d'être surchargée, vous pouvez même utiliser les sprints comme un moyen de limiter le nombre d'éléments sur lesquels une équipe travaille simultanément.

Par exemple, choisissez un certain nombre d'éléments les plus importants de votre "backlog" (idéalement sur la base d'une hiérarchisation raisonnable de ce backlog) et attribuez-les à un délai fixe (par exemple, les deux prochaines semaines), et l'équipe ne travaillera que sur ces éléments, afin d'éviter un trop grand nombre de changements de contexte (qui peuvent avoir un impact sur l'efficacité du travail de l'équipe et sur la réalisation effective de tous ces éléments). Si un élément survient qui DOIT être traité en priorité (et qui, à mon avis, doit répondre aux mêmes critères de priorisation que ceux utilisés pour les autres éléments du backlog), vous convenez alors des éléments à abandonner dans le "sprint" en cours afin de répondre à la nouvelle demande.

Livraison itérative

L'une des plus grandes différences entre la gestion de projet traditionnelle et la livraison agile est la façon dont les capacités sont livrées. L'approche de la gestion de produit consiste à livrer d'abord la "tranche" de fonctionnalité ayant le plus d'impact (c'est ce qu'on appelle un MVP - Minimum Viable Product), puis à livrer progressivement des fonctionnalités/capacités supplémentaires par ordre de priorité au fil du temps. La fourniture de nouvelles fonctionnalités à vos "clients" de manière itérative présente de nombreux avantages.

Vos "clients" obtiennent de la valeur plus tôt, grâce à la livraison en premier des fonctionnalités/capacités les plus importantes (plutôt que de devoir attendre beaucoup plus longtemps pour que toutes les fonctionnalités/capacités soient livrées en une seule fois).

Vous êtes en mesure d'obtenir plus tôt un retour d'information ou des données sur l'efficacité des nouvelles fonctionnalités ou capacités à améliorer les paramètres de mesure de vos clients, et vous pouvez modifier votre orientation en conséquence.

Le processus de livraison de la première tranche de fonctionnalité/capacité peut être extrêmement instructif sur la manière de livrer plus efficacement la prochaine série de capacités, sur le temps que cela peut prendre, etc. Dans une approche traditionnelle de gestion de projet, vous n'obtenez cet apprentissage qu'à la fin, lorsqu'il est franchement trop tard pour être utile.

Hiérarchisation des priorités

Si vous avez un certain nombre de "choses" à faire, il existe de nombreux cadres utiles qui peuvent être utilisés pour vous aider à les classer dans un ordre de priorité raisonnable.

Le cadre à utiliser dépendra des mesures de réussite que l'équipe essaie d'obtenir. Les cadres grossiers tels que l'effort par rapport à l'impact sont un bon point de départ, mais ils ne constituent qu'une lentille limitée pour voir votre feuille de route/backlog. Lorsque les équipes ont des ensembles de mesures bien établis (centrés sur le client) qu'elles essaient de mettre en place, des cadres comme ICE/RICE (un modèle de notation qui combine la portée, l'impact, l'effort et la confiance) sont utiles pour les mettre dans un ordre raisonnable afin d'en tirer le plus grand bénéfice. Pour les équipes qui ont des mesures moins tangibles (par exemple, la satisfaction), il est préférable d'utiliser des cadres plus légers comme Kano, qui se concentrent sur le niveau de satisfaction du client pour toute nouvelle fonctionnalité ou tout nouveau produit.