Renforcez la collaboration entre les professionnels du projet et du produit afin d’améliorer l’efficacité et l’alignement.
Éliminez les silos et obtenez de meilleurs résultats, ensemble. Ce cours permet aux managers de projet et aux chefs de produit de collaborer plus efficacement dans des environnements de développement modernes. Il présente des concepts clés de management de produit pour aider les managers de projet à manager plus efficacement les initiatives de développement de produits. De plus, il fournit également des cadres fondamentaux de management de projet pour renforcer l’action des chefs de produit.
Grâce à des outils pratiques, des conseils d’experts et un apprentissage basé sur des scénarios fondés sur des défis du monde réel, découvrez comment les équipes de projet et de produit peuvent tirer le meilleur parti d’une approche synergique pour générer ensemble une plus grande valeur organisationnelle.
Stan, un client potentiel, a eu du mal à trouver le temps de participer à notre session de découverte. (C’est la session de travail où le client et moi discutons des limites d’une mission de conseil.) Après qu’il ait annulé trois appels programmés, j’ai soupçonné que nous ne travaillerions pas ensemble.
Mais ensuite, il m’a demandé une conversation un soir, après sa « journée de folie ». (Ses mots, pas les miens.)
Lorsque nous avons discuté après nos heures normales de travail, j’ai appris plusieurs choses importantes sur son organisation.
Tout le monde était surchargé. Les équipes avaient trop de projets et de travail de support. Les managers avaient trop de décisions à prendre.
En conséquence, leur débit était assez faible. Cela signifiait que leurs boucles de rétroaction étaient trop longues. (Ils souffraient des effets de Loi de Little avec un en-cours élevé, un long encourt et un faible débit.)
Il était certain qu’il allait perdre des gens s’il ne changeait rien. Et il ne savait pas par où commencer.
Au cours de notre conversation, il a convenu avec moi qu’il devait mener ces changements. Ces changements étaient d’atteindre plus de résilience dans le système de chacun, plus de marges dans le système, et que tous fassent tout ce qu’ils peuvent pour créer des boucles de rétroaction plus rapides.
Commençons par ce que j’entends par plus de résilience dans le système.
Astuce #1 : Résilience du système.
Beaucoup de personnes pensent que la résilience leur permet de rebondir après des moments difficiles. Au lieu de cela, considérez la résilience comme un moyen de vous projeter vers l’avant. Si c’est le cas, vous pouvez vous libérer pour prendre des décisions différentes, et peut-être meilleures.
Lorsque Stan a repensé ses idées sur la résilience, il s’est rendu compte que l’organisation avait créé un système fragile, peu susceptible de rebondir du tout, sans parler d’aller de l’avant.
Stan a identifié ce qui rendait le système fragile :
Des feuilles de route longues et détaillées pour la plupart des produits.
Des promesses spécifiques que les ventes avaient faites à plusieurs clients, ce qui a forcé à maintenir ces feuilles de route en place. Parce que les feuilles de route étaient si longues, les gens ont continué à y ajouter davantage de fonctionnalités.
À la suite de toutes ces promesses, tout le monde regardait en arrière, pas en avant.
Cette perspective, de toujours regarder en arrière, rendait difficile, voire impossible, la réévaluation d’une décision. Après avoir discuté des problèmes, Stan a décidé de reconsidérer toutes les différentes promesses faites aux clients. Comme il l’a dit :
« Nous avons déjà rompu les promesses de date de livraison. Autant tout négocier. »
Lentement, en supprimant les ancres autour des engagements de chacun, Stan a pu réduire le nombre de projets actifs et créer un peu de marge dans le système.
Astuce #2 : Intégrez de la marge dans le système
Stan et moi avons reparlé dans la soirée. Même si les équipes ont réussi à dégager un peu de marges, Stan avait toujours l’impression que le travail le submergeait. Mais maintenant, il avait besoin d’informations pour garder ces marges dans le système. Pendant si longtemps, les gens avaient été si occupés qu’ils ne savaient pas quoi faire de leur temps « supplémentaire ».
Je lui ai demandé : « Coachez-vous les gens pour qu’ils prennent certaines de vos décisions ? Ou est-ce que vous devez encore prendre toutes les décisions ? »
Il s’est arrêté et a dit :
« Je suppose qu’il est temps pour moi de déléguer certaines décisions, n’est-ce pas ? »
« Vous n’obtiendrez pas de boucles de rétroaction plus courtes tant que vous n’aurez pas intégré un peu de mou dans votre système », ai-je dit. « Il suffit de regarder notre relation de conseil. Vous me payez cher pour travailler avec moi en dehors de vos heures de travail normales. C’est comme une taxe de décision. Je parie que vous avez beaucoup plus de ces taxes de décision chaque jour que nos simples discussions.
J’ai su qu’il comprenait quand il a émis un grognement. Mais cette idée lui a permis de raccourcir de nombreuses boucles de rétroaction.
Astuce #3 : Raccourcissez les boucles de rétroaction
Lorsque j’ai parlé pour la première fois avec Stan, son temps de prise de décision et celui de toute la direction exécutive éclipsaient tout le temps de travail sur les projets.
Comme les équipes ont travaillé sur moins de projets et sur moins de fonctionnalités, elles ont raccourci leurs boucles de rétroaction internes. Cela leur a permis de montrer des démos et de livrer plus souvent en production, ce qui a permis aux chefs de produit de réduire le contenu du backlog et des feuilles de route. Cela a aussi permis aux chefs de produit d’être beaucoup plus réactifs aux besoins des clients et de terminer les projets plus rapidement. Plus les équipes terminaient les projets rapidement, plus il était facile de modifier le portefeuille de projets.
Aujourd’hui, en repensant leur approche de la résilience et en créant davantage de marges dans le système, Stan pouvait constater que l’organisation était plus efficace. Il avait encore du travail à faire avec son équipe de direction, mais elle était sur la bonne voie.
L’efficacité mène à l’agilité de l’entreprise
Lors d’une conversation récente (pendant les heures normales de travail !), Stan a dit qu’il avait enfin l’impression que l’organisation était plus efficace. Et qu’il avait plus d’options, ce qui était le point de l’agilité business.
Nous nous réunissons maintenant pendant nos journées de travail, et non le soir. Stan a l’air plus détendu. Il a dit qu’il prenait des décisions plus rapidement et mieux, ce qui était le but de notre engagement.
Il se peut que vous ne souhaitiez pas ou n’ayez pas besoin d’une « véritable » agilité business. Cependant, je soupçonne que vous voulez être plus efficace.
Considérez ces idées :
Utilisez la résilience pour vous projeter vers l’avant.
Intégrez des marges dans le système pour ne pas être frénétique.
Raccourcissez les boucles de rétroaction, en particulier les boucles de rétroaction de la direction.
Si vous mettez en œuvre es conseils, partagez comment cela se passe.
Êtes-vous nouveau sur la newsletter de Pragmatic Manager ? Voir les éditions précédentes.
partagez ce billet avec vos amis, collègues et relations professionnelles
Avez-vous remarqué que certaines équipes semblent être plus efficaces que d’autres ?
La plupart du temps, elles gèrent leur WIP (Work in Progress). Ses membres apprennent ensemble. Souvent, ils collaborent à l’échelle de l’organisation. Mais le point majeur, c’est qu’ils ont tendance à livrer plus rapidement et plus souvent que les autres équipes moins efficaces.
Bien que la plupart de ces équipes efficaces soient interfonctionnelles, j’ai travaillé avec des équipes de composants qui ont démontré ce comportement. Chaque équipe était autonome, mais elle collaborait pour livrer quelque chose de plus grand que « son » seul composant.
Qu’est-ce qui crée ces équipes plus efficaces ?
Plusieurs caractéristiques :
Elles ont un objectif global clair.
Tout le monde collabore pour travailler vers cet objectif, et seulement vers cet objectif.
Les membres de l’équipe ont appris à donner et recevoir des commentaires les uns des autres. Ces commentaires aident l’équipe à apprendre et à s’améliorer.
Et comme très peu d’équipes peuvent livrer seules, elles peuvent aider les autres équipes à apprendre et à s’améliorer. Tout cela parce qu’elles créent et utilisent des plus petits réseaux. Ce sont des équipes autonomes.
Comment fonctionnent les équipes autonomes ?
Les équipes autonomes prennent leur objectif clair, se concentrent sur celui-ci et atteignent cet objectif. Elles décident comment travailler ensemble et comment manager les membres de l’équipe lorsqu’elles ne le peuvent pas. Lorsqu’elles ne peuvent pas livrer, elles vous en informent le plus tôt possible.
Si vous êtes manager, comment pouvez-vous créer ces équipes autonomes ?
Établissez et clarifiez l’objectif global de cette équipe.
Demandez à l’équipe si elle a besoin d’une certaine facilitation au début ou au fur et à mesure qu’elle persiste. Si certaines équipes autonomes n’ont pas besoin de facilitation, beaucoup en ont la nécessité. Surtout face aux exigences omniprésentes de multitâches.
Encouragez la création de communautés à l’échelle de l’organisation et de plus petits réseaux. Cela aide les personnes et les équipes à réfléchir à la manière dont elles peuvent apprendre à l’échelle de l’organisation. Et d’offrir des informations recueillies dans leur équipe aux personnes de l’ensemble de l’organisation.
Commençons par l’objectif global.
Définissez et clarifiez l’objectif global de l’équipe.
Les équipes de développement de produits ont souvent un objectif global axé sur le produit. C’est de la forme :
Cette version permettra au jeu de clients numéro un de résoudre les problèmes A, B et C dans cet ordre de classement. Bien que nous espérions pouvoir également résoudre les problèmes D, E et F, nous nous concentrons pour l’instant sur ce plus petit objectif spécifique. Parce que même si nous voulons accomplir D, E et F, nous pouvons également vouloir nous concentrer sur un jeu de clients différent lorsque nous terminerons A, B et C.
Vous pouvez décrire différemment l’objectif global de votre équipe. Cependant, ces objectifs sont souvent spécifiques, c’est pourquoi ils définissent un périmètre circonscrit autour du travail de l’équipe, afin que l’équipe puisse se concentrer uniquement sur son travail. Pas de multitâche. Pas d’interruptions.
Mieux encore, un périmètre circonscrit aide l’équipe à repousser ce qui est hors de celui-ci pour le moment. L’équipe ne se laisse pas distraire par un travail futur ou d’autres possibilités. Au lieu de cela, elle livre ce qu’elle doit livrer.
Si vous faites partie d’un programme, un ensemble de projets tous axés sur un livrable business global, vous avez probablement vu des équipes agir ainsi. Chaque équipe se concentre sur sa contribution pour que le produit global réussisse.
Alors que certaines équipes peuvent s’accaparer leur objectif global et le suivre, certaines équipes ont également besoin de facilitation.
Envisagez des rôles d’animation d’équipe.
Normalement, je ne considère pas le leadership de produit comme un rôle d’animation d’équipe. Mais parfois, c’est le cas. Surtout si les membres de l’équipe ont du mal à se concentrer sur le premier jeu de clients. Ou dans l’ordre de hiérarchisation des problèmes A, B et C.
Il y a longtemps, j’ai travaillé sur un programme où la direction avait décidé de reporter pour le moment plusieurs fonctionnalités intéressantes et de les considérer pour une future version. Cependant, un développeur était convaincu qu’il devait « sauver » le produit en continuant à travailler sur ces fonctionnalités intéressantes.
C’est à ce moment-là que le chef de produit a expliqué l’intérêt de reporter ces fonctionnalités intéressantes et ce que l’entreprise espérait gagner avec cette version plus limitée.
Une fois que le développeur a compris ceci, il fut heureux de se concentrer sur le travail de l’équipe, et non sur ses intérêts.
Parfois, les équipes ont besoin de liberté pour être autonomes. J’ai vu des managers bien intentionnés (et certains moins bien intentionnés) s’insérer dans le travail de l’équipe. Lorsque les managers font cela, l’équipe perd son autonomie. Au lieu de cela, un manager de projet facilitateur peut agir comme une boîte de délimitation pour l’équipe elle-même, protégeant l’équipe des personnes qui détruiraient l’autonomie de l’équipe.
Les managers de projet facilitateurs ne disent pas à l’équipe quoi faire ou comment travailler. Au lieu de cela, ils et elles créent l’environnement pour que tout le monde puisse contribuer. Parfois, cela signifie expliquer à des managers bien intentionnés que non, l’équipe ne peut pas en faire plus.
Parfois, ces animateurs et animatrices aident l’équipe à mieux travailler ensemble. Il peut s’agir de faciliter les accords de travail de l’équipe ou d’aider l’équipe à s’entraîner à donner et recevoir des commentaires. Il peut s’agir d’aider l’équipe à envisager des pratiques alternatives pour la rendre encore plus efficace.
Mais les leaders facilitateurs ne disent pas à l’équipe comment travailler. Ils et elles offrent des options. Souvent, l’une de ces options inclut les communautés de l’ensemble de l’organisation.
Construisez des communautés à l’échelle de l’organisation.
Lorsque je vois des équipes autonomes, je découvre souvent que ces équipes ont construit des réseaux à l’échelle de l’organisation. (Voir l’image en haut de cet article.) Non pas parce que quelqu’un leur a dit de le faire. Mais elles se rendent compte que Marie, là-bas, a des connaissances intéressantes. Et Fred, ici, a déjà résolu un problème comme celui-ci. Ou Suzanne, dans cette autre équipe, a déjà eu affaire à ce client.
Les équipes autonomes peuvent combler leurs lacunes en travaillant avec et auprès d’autres personnes, même si ces autres ne font pas partie de « leur » équipe.
J’aime particulièrement les groupes d’apprentissage ciblés. Envisagez les communautés de pratique formelles comme un moyen de commencer par un apprentissage ciblé. À l’époque où les entreprises avaient des cafétérias, j’apprenais beaucoup de choses de manière informelle au déjeuner. Non seulement j’ai appris à connaître les produits, mais j’ai aussi appris qui avait quels types de connaissances. Cela m’a aidé à décider par où commencer une quête sérieuse.
Bien que de nombreuses équipes autonomes n’aient pas besoin d’un leadership spécifique axé sur un projet ou une équipe, elles ont besoin du type de leadership qui peut définir l’objectif global.
Les équipes autonomes ont toujours besoin d’un leadership d’entreprise.
La grande chose dont les équipes autonomes ont besoin de la part de la direction est la suivante : L’objectif global et la durée de cet objectif.
Cela signifie que les équipes autonomes doivent comprendre le(s) objectif(s) du produit et la stratégie. Ces équipes doivent comprendre à quelle fréquence la direction de l’entreprise souhaite être en mesure de modifier ces objectifs de produit et/ou cette stratégie.
De plus, il arrive que des équipes se retrouvent en difficulté et qu’elles ne sachent pas comment s’en sortir. (Imaginez un membre de l’équipe qui cesse de venir travailler. Ce genre de problème.) C’est à ce moment-là que les managers peuvent soutenir l’équipe et les différents membres de l’équipe.
Les équipes autonomes ne fonctionnent pas en circuit ouvert. Au lieu de cela, elles montrent leur travail tôt et souvent. Elles utilisent un périmètre circonscrit pour se concentrer sur leur objectif et uniquement sur cet objectif. Et si quelqu’un demandait autre chose ? Elles ont des options, mais ces options incluent rarement le multitâche ou le fait de dire oui. Elles sont beaucoup plus susceptibles de dire non.
Si vous êtes manager, voyez comment vous pouvez soutenir les personnes que vous menez et les servir pour qu’elles forment une équipe autonome. Votre équipe apprendra et s’améliorera, et contribuera à partager cet apprentissage et cette amélioration dans toute l’organisation.
Si les vraies priorités ne sont pas bien posées et comprises, l’équipe projet risque fort de travailler sur trop d’éléments en même temps et ne pas être très efficace.
How to Tell the Difference Between Rank-Order and Prioritization par Johanna Rothman
Trop de mes clients confondent deux termes spécifiques : Ordre de classement (Rank Order) et hiérarchisation. Trop souvent, cela signifie que l’équipe travaille sur trop d’éléments en même temps. Cela conduit à un en-cours élevé, à un temps de cycle court et à un faible débit.
Voici donc un visuel et une explication.
Voir la partie gauche de l’image « L’ordre de classement ». Lorsque nous classons les travaux par ordre d’ordre, nous choisissons une priorité #1, une priorité #2, une priorité #3, et ainsi de suite.
Nous ne choisissons qu’un seul élément à chaque priorité.
Oui, ce mot « priorité » fait partie du problème. Nous y reviendrons plus tard.
Comparez cette approche et cette explication avec le nombre d’organisations qui créent une « La liste priorisée » (Prioritization) (partie droite de l’image) :
Cette organisation a déclaré :
« Nous allons prioriser le travail, mais nous avons trop de travail pour vraiment faire la distinction entre chacun des éléments aux niveaux élevés, moyen et bas. Nous laisserons donc à l’équipe (ou au chef de produit) le soin de décider quand il sera temps pour eux de décider.
On dirait que l’équipe a de l’autonomie, n’est-ce pas ?
Pas si vite.
Cette équipe a trois éléments prioritaires « Forts». Selon la taille de chaque article, cela peut représenter l’équivalent d’un trimestre entier de travail. Ensuite, l’équipe a six éléments prioritaires « Moyens ». Combien de temps cela prendra-t-il ? Aucune idée.
Pire, l’équipe a 12 articles prioritaires « Faibles ». celle-ci peut aussi être une liste infinie.
Parlons de la « priorité » et de ce que cela signifie.
Ce que signifie la priorité
Lorsque nous disons « prioriser », nous sommes censés répondre à cette question : « Quelle est la préséance de cet élément par rapport à tous les autres éléments ? »
Lorsque nous classons le travail, avec un élément à chaque rang, nous pouvons le dire.
Mais lorsque nous classons le travail avec Fort, Moyen et Faible, nous commençons à peine à classer le travail. Si nous autorisons plusieurs articles à chaque rang (comme je le vois chez mes clients), nous n’avons pas terminé la hiérarchisation. Pire encore, certaines techniques pour décider quel travail faire maintenant, comme MoSCoW, aggravent encore la situation. (MoSCoW signifie : Must, Should, Could, Would.)
Lorsque nous priorisons plusieurs éléments à la fois, nous pouvons nous retrouver dans une très mauvaise situation avec beaucoup trop de WIP (travail en cours / en-cours).
Il y a des années, l’un de mes clients a commencé avec Fort, Moyen et Faible. Mais Fort n’était pas assez élevé, alors ils ont ajouté « Vraiment Fort ». Puis, « Ultra Fort ». Oui, ils ont commencé à utiliser « Mega Fort » quand je suis arrivée.
Les managers l’ont fait parce que l’équipe avait tellement d’en-cours que leur débit était assez faible. Voir la newsletter Flow Metrics.
J’ai demandé à tous les managers de créer silencieusement une liste classée de tous ces fiches d’éléments de travail avec une seule liste de fiches sur la table. Ils n’ont pas pu se mettre d’accord. Je leur ai donné trois minutes, et quand Buzz a été en désaccord avec Woody pour la troisième fois, je les ai arrêtés. Nous avons discuté du problème, et je leur ai présenté l’ordre de classement.
Ils pouvaient tous s’entendre sur les trois premiers éléments de leur liste beaucoup trop longue. C’était suffisant pour que l’équipe commence à travailler et à livrer. Ils doivent classer le travail, pas le hiérarchiser.
Classement du travail
Certains de mes collègues agiles recommandent qu’une équipe puisse commencer à répartir le travail entre Fort, Moyen et Faible. Mais cela en vaut-il la peine alors que si peu d’équipes atteignent les niveaux Moyen et Faible ? (Ou l’un des autres termes de hiérarchisation employé ?)
Pire encore, le chef de produit ou l’équipe n’a pas vraiment la capacité de dire « non » à l’un ou l’autre des éléments de travail. Cela signifie que l’équipe n’a pas l’autonomie nécessaire pour décider.
C’est pourquoi je recommande à l’équipe de classer le travail. Vous pouvez utiliser le temps de cycle ou compter le nombre de stories que votre équipe termine généralement dans un sprint. Ne classez – et planifiez – que pour ce nombre d’histoires. Ensuite, l’équipe sait ce qu’elle est censée faire maintenant. Cela permet au chef de produit de réduire les options pour le travail suivant.
J’aimerais que le classement et la hiérarchisation signifient la même chose. Trop d’organisations ne traitent pas ces deux activités de la même manière. Au lieu de cela, classez le travail avec un élément #1, un élément #2, etc. car cela vous permettra de limiter le WIP et de terminer le travail.
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
partagez ce billet avec vos amis, collègues et relations professionnelles
Partagez votre réalité en faisant entendre votre voix.
Que vous soyez Business Analyst, Product Owner, Assistance à Maîtrise d’Ouvrage (AMOA), consultant(e) ou tout simplement impliqué(e) dans l’analyse du besoin, cette enquête a besoin de votre témoignage et de vos réponses.
L’IIBA France et IIBA Geneva ont lancé une grande enquête francophone pour dresser un état des lieux de la profession et s’efforcer de répondre à quelques questions vitales pour la profession :
Qui sont les analystes métier aujourd’hui ?
Quels outils, pratiques, méthodes utilisent-ils ?
Quelles sont leurs conditions de travail, leurs aspirations, leurs défis ?
Comment aider les décideurs à mieux comprendre ce métier et à le valoriser ?
Quels sont les besoins en formations et accompagnement des Business Analystes ?
100 % anonyme et seulement 10 à 12 minutes de votre temps.
« Tout est une question d’arriéré de produit (Product Backlog). Le Product Owner doit le gérer. Donnez-lui la priorité. Remplissez-le de User Stories. »
Cela vous semble familier ? À certains stades de la transformation agile, il est typique de se concentrer sur la construction d’un arriéré ou backlog de produit. Et d’utiliser Jira pour cela. Vous trouverez de telles listes linéaires de tâches dans presque toutes les organisations au début de leur parcours agile. Et bien que le Product Backlog soit un outil très important car il apporte de la clarté et aligne les gens autour des mêmes objectifs business, c’est aussi l’un des outils les plus mal compris et les plus mal utilisés.
Cela part souvent par une bonne intention, le Product Owner demandant aux clients ce qu’ils veulent. Et ils réfléchissent à toutes les fonctionnalités possibles que vous pouvez imaginer, dans une bonne intention. Et le backlog/contenu ne cesse de croître alors que les attentes en matière de délais restent les mêmes. C’est le début très fréquent d’une grande déception avec Agile.
« Cela ne nous a pas aidés. Ce n’est pas plus rapide ! » disent les gens, et ils ont raison.
L’agilité n’est pas le moyen de fournir plus de fonctionnalités plus rapidement. Bien au contraire. C’est un moyen d’obtenir plus rapidement une valeur business plus élevée, et ce sont là deux choses différentes.
Donc, si vous voulez obtenir plus de valeur business, commencez par le backlog.
Mais cette fois-ci, vous ne demandez pas ce que vous voulez mettre en œuvre, mais plutôt les besoins et recherchez une fonctionnalité minimale à mettre en œuvre pour satisfaire ces besoins. 80 % de la valeur réside dans 20 % de la fonctionnalité et c’est exactement ce qu’un bon Product Backlog doit identifier. Les objets de plus grande valeur en premier, le reste plus tard ou jamais.
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
Un bon Product Backlog est co-créé en collaboration avec le client, les parties prenantes et les membres de l’équipe. Ils doivent tous découvrir les besoins de l’entreprise. Ils doivent tous développer une empathie pour les clients. Dans la plupart des cas, le Product Backlog qu’ils créent ensemble n’est pas une liste linéaire qui s’adapterait à des outils traditionnels comme Jira ou Excel, mais très souvent, nous utilisons la technique du Story Mapping pour créer des cartes multidimensionnelles, ou la technique de cartographie d’impact pour créer une carte mentale, ou visualiser le produit sous forme d’arbre et élaguer les branches. Rien qui ressemblerait à une liste linéaire de choses à faire.
Toutes les techniques ont une chose en commun ; Elles se concentrent sur la valeur commerciale et les besoins du client. Elles ne décrivent pas la solution.
Le comment dans Scrum doit être découvert lors du Sprint en collaboration d’équipe. Alors :
Oubliez les exigences, arrêtez de demander à vos clients ce qu’ils veulent, et concentrez-vous plutôt sur la découverte de leurs besoins et visualisez ensemble la valeur dans votre Product Backlog.
partagez ce billet avec vos amis, collègues et relations professionnelles
Parfois, un travail inachevé n’est qu’une malchance ou un mauvais timing, mais certaines fois vous pourriez découvrir une chose qui est en train de tourner en mauvaise habitude.
#1 – Si vous voulez une garantie, achetez un grille-pain.
Mon premier conseil sur la façon de manager le travail inachevé est : Rappelez-vous que même les meilleures équipes agiles ratent parfois leurs objectifs. C’est OK et même souhaitable dans une certaine mesure.
Les objectifs de sprint ne sont pas garantis. (Comme le dit le personnage de Clint Eastwood, Nick Pulovski, dans The Rookie, « Si vous voulez une garantie, achetez un grille-pain ! »). Les dirigeants, les parties prenantes et même l’équipe elle-même peuvent avoir besoin d’un rappel occasionnel à ce sujet.
L’engagement d’une équipe envers un objectif de sprint est une promesse de faire de son mieux pour atteindre cet objectif. Si les membres de l’équipe sont perpétuellement contraints de donner une garantie, ils garantiront moins pour être en sécurité.
Parfois, une équipe a besoin de donner une garantie. Il peut arriver qu’un client ait besoin d’une fonctionnalité à une certaine date. Le groupe financier peut avoir besoin d’exécuter des rapports de fin d’année au début du mois de janvier, par exemple.
En général, cependant, nous ne voulons pas forcer une équipe à donner une garantie. Nous demandons à une équipe de s’engager dans quelque chose de raisonnable, puis nous comprenons si elle n’y parvient pas. Ne pas réussir occasionnellement n’est pas un échec, c’est généralement un signe de malchance ou d’une équipe qui s’efforce d’en faire trop.
#2 – Ne reportez pas le travail au prochain sprint automatiquement.
Mon deuxième conseil est : Résistez à l’envie de reporter automatiquement le travail inachevé au prochain sprint. Mettez-le plutôt dans le backlog du produit.
L’item peut être de retour dans le backlog du produit pendant une milliseconde, mais le product owner doit décider consciemment de continuer à travailler dessus.
(D’un point de vue logistique, je me fiche qu’il soit plus facile dans l’outil de votre choix de déplacer l’élément vers le sprint suivant plutôt que vers le backlog du produit en premier. L’essentiel est qu’il y ait une vraie décision de poursuivre le travail.)
Si le Product Owner décide que l’équipe doit travailler sur l’élément partiellement fini immédiatement lors du prochain sprint, importez l’élément du backlog de produit tel quel. Ne le réestimez pas. Ne le renommez pas. Ne prenez pas de crédit de vélocité partielle. Il suffit de mettre l’élément dans le sprint suivant et de prendre le crédit complet lorsqu’il est terminé.
Mais si l’article est reporté à plus tard, allez-y et divisez l’histoire en ce qui a du sens. Prenez un crédit partiel de vélocité pour le travail que vous avez effectué lors du dernier sprint, puis rédigez une nouvelle histoire qui décrit uniquement les fonctionnalités manquantes et estimez cette histoire.
#3 – Documentez la cause.
Mon dernier conseil pour manager le travail inachevé est le suivant : A chaque fois qu’un travail est inachevé à la fin d’un sprint, l’équipe doit prendre le temps de la rétrospective pour déterminer si ceci était évitable.
Parfois, un travail inachevé n’est qu’une malchance ou un mauvais timing, comme un membre de l’équipe malade ou un problème découvert tard dans le sprint qui n’aurait pas pu être détecté plus tôt. Parfois, c’est juste le résultat d’une cible trop élevée pour un sprint.
Mais vous pourriez découvrir quelque chose qui devient une mauvaise habitude.
Quelle qu’en soit la cause, il est toujours utile de se demander si quelque chose peut être fait pour éviter que cela n’affecte les sprints futurs afin que votre équipe puisse réussir avec l’agilité.
Bonjour, voici les billets du blog DantotsuPM qui furent les plus appréciés en Août 2024.
Les lectrices et lecteurs ont apprécié les sujets: Conduite du changement, Bien découper les User Stories et Réussir sa transformation Agile.
« La conduite du changement dans les projets de transformation, retour d’expérience autour de quelques incontournables » par Olivia LE JEUNE et Jean-Roch HOULLIER.
SPIDR : 5 façons simples mais puissantes de découper les histoires utilisateur / user stories.
PMO adaptatif : 13 pratiques qui fonctionnent pour une transformation Agile
Pensez d’abord à la valeur et aux coûts, puis tenez ensuite compte d’autres facteurs qui affectent la priorité d’un élément du product backlog : L’apprentissage, le risque et les dépendances.
Les arriérés de produits (product backlog) contiennent toutes les fonctionnalités connues qui finiront par se retrouver dans le produit. Qu’il s’agisse d’histoires utilisateur (user stories), d’histoires métier (job stories) ou d’une simple phrase ou deux, il est essentiel d’ordonner le backlog afin que les équipes construisent toujours les fonctionnalités les plus prioritaires. En plus de créer les bonnes fonctionnalités, il est important de les construire dans le bon ordre. Voici les 5 éléments clés à prendre en compte lorsque vous réfléchissez à la façon de hiérarchiser le backlog produit.
Facteur #1 : La Valeur
Commençons par le gros problème : la valeur. Et bien qu’il soit évident de considérer la valeur d’une fonctionnalité, « valeur » est un terme nébuleux.
La valeur est une mesure de l’utilité ou de l’impact sur un public particulier. La plupart des travaux qu’une équipe de développement agile entreprendra seront précieux pour les utilisateurs. Mais d’autres travaux peuvent être précieux seulement pour l’équipe elle-même. D’autres travaux seulement pour certains utilisateurs, parties prenantes et membres de l’équipe.
Par exemple, considérez la refactorisation ou réusinage de code ( le refactoring) : Améliorer la structure mais pas le comportement du code. Parce qu’elle rend le code plus facile à maintenir ou à modifier, la refactorisation est d’une grande valeur pour les développeurs.
Le coût de la refactorisation est généralement justifié, cependant, car il profite également aux utilisateurs. Si le code est plus facile à maintenir, les utilisateurs devraient rencontrer moins de bogues. De même, un code amélioré signifie que les utilisateurs devraient recevoir un peu plus rapidement les nouvelles fonctionnalités dans ce domaine du produit. (Pour plus de façons de justifier la priorisation de la refactorisation, voir « 4 Ways to Persuade a Product Owner to Prioritize Refactoring. »)
Lorsque l’on réfléchit à la valeur d’une fonctionnalité, il peut être important de réfléchir à la façon dont la valeur d’une fonctionnalité se dégrade au fil du temps. Une fonctionnalité peut être très précieuse aujourd’hui, mais beaucoup moins précieuse plus tard.
L’un des exemples les plus forts que j’ai vus de cela est survenu lorsque je travaillais avec une équipe créant des logiciels pour soutenir les ligues de sports. Certaines fonctionnalités devaient être présentes le jour du repêchage, lorsque tous les joueurs sélectionnaient leur équipe. Si la fonctionnalité n’était pas disponible le jour du repêchage, les joueurs formeraient probablement leur ligue sur une autre plateforme. Le coût du retard dans ce cas était énorme.
Facteur #2 : Le Coût
La deuxième chose à considérer lors de l’établissement des priorités est le coût. Le coût le plus important est généralement l’effort de l’équipe produit pour développer une fonctionnalité. La plupart des équipes utilisent des story points pour estimer l’effort des éléments du backlog produit. D’autres estiment cet effort en jours-personnes, en temps idéal ou en d’autres unités similaires.
Dans certains cas, il peut y avoir des coûts supplémentaires qui doivent être pris en compte. Une considération commune actuelle ? Le coût permanent de la fourniture de fonctionnalités qui reposent sur divers produits d’IA. Ces produits incluent souvent de petits frais à l’utilisation, mais ceux-ci peuvent certainement s’additionner à grande échelle.
Quelle que soit l’unité dans laquelle une équipe estime les éléments de son backlog produit, le coût de développement et de support d’une fonctionnalité doit être pris en compte dans la priorité d’un élément. Par exemple, un élément qu’une équipe estime à 5 doit être prioritaire par rapport à une fonctionnalité estimée à 20 si toutes choses sont égales par ailleurs. Cela est vrai quelle que soit l’unité d’estimation utilisée par l’équipe.
Facteur #3 : L’Apprentissage
Un troisième facteur à prendre en compte lors de l’établissement des priorités est le suivant : Qu’est-ce qu’une équipe apprendra en effectuant un élément particulier du backlog de produit ? Si vous apprenez quelque chose en développant un élément du backlog, vous voudrez probablement développer cet élément tôt afin d’avoir le temps d’agir sur ce que vous avez appris.
Si vous apprenez quelque chose trop tard, vous n’aurez pas le temps de profiter des nouvelles connaissances.
L’apprentissage peut prendre deux formes. Il peut s’agir du produit ou du projet.
Apprendre à connaître le produit
L’apprentissage du produit se produit lorsque l’équipe développe une fonctionnalité et reçoit des commentaires à son sujet.
Si les utilisateurs aiment la fonctionnalité, privilégiez l’amélioration de la fonctionnalité ou la création d’autres choses similaires. Si les utilisateurs ne l’aiment pas, envisagez de supprimer la fonctionnalité ou de réduire la priorité des fonctionnalités associées.
En savoir plus sur le projet
L’apprentissage du projet fait référence aux connaissances que les membres de l’équipe acquièrent sur la façon de développer le produit ou la solution. Par exemple, supposons qu’une équipe ait l’intention de construire une partie d’un produit à l’aide d’une technologie que ses membres n’ont jamais utilisée auparavant.
Lorsque les membres de l’équipe développent le premier élément du backlog de produit à l’aide de cette nouvelle technologie, ils apprennent des choses à ce sujet, telles que :
La technologie fonctionne-t-elle comme promis ?
Les estimations relatives à l’utilisation de la nouvelle technologie devraient-elles être révisées ?
La technologie peut-elle être utilisée dans d’autres parties du produit ou du projet ?
N’oubliez pas le fait d’apprendre lorsque vous pensez à la hiérarchisation agile du backlog. Le potentiel d’une fonctionnalité à enseigner à l’équipe et à ses parties prenantes quelque chose sur les besoins des utilisateurs ou les réalités du projet peut être une raison suffisante pour en faire une priorité absolue.
Facteur #4 : Le Risque
Le quatrième facteur à prendre en compte lors de l’établissement des priorités est le risque inhérent à l’élaboration de l’élément du backlog produit. Si quelque chose est risqué et que vous devez le faire, faites-le tôt. Vous voulez savoir si ce risque va se matérialiser.
D’un autre côté, si une fonctionnalité est risquée et que vous n’avez peut-être pas besoin de la développer, retardez le travail dessus jusqu’à ce qu’il devienne clair que vous devez la faire.
Facteur #5 : Les Dépendances
Le dernier facteur que vous devez prendre en compte lors de la hiérarchisation des priorités est les dépendances entre les éléments du backlog produit. Certains items ne sont peut-être pas prioritaires en soi, mais ils sont nécessaires à la livraison d’autres articles. Lorsque c’est le cas, l’élément d’activation mais moins prioritaire doit être déplacé plus haut dans le backlog afin d’être terminé avant que l’élément n’en dépende.
À titre d’exemple, considérez un camp d’été où j’ai aidé à utiliser Scrum. Parmi les éléments de l’arriéré de produits, il y avait « peindre tous les canots ». C’était une priorité élevée, car ils voulaient montrer des photos de canoës brillants et nouvellement peints dans leur marketing.
Mais peindre les canots dépendait d’un autre élément de l’arriéré de produit : Poncer et réparer les canoës qui en avaient besoin.
Techniquement, la réparation des canoës n’avait pas besoin d’être effectuée avant un jour ou deux avant l’ouverture du camp d’été, mais cet élément était prioritaire dans le backlog des produits car les photos marketing des canoës devaient être prises bien avant cela.
Techniques formelles de hiérarchisation de l’arriéré
Il existe de nombreux cadres de travail pour la hiérarchisation afin de vous aider à comparer ces facteurs les uns par rapport aux autres de manière plus granulaire, notamment le modèle de Kano, le modèle de notation RICE et la pondération relative. Même avec ces méthodes formelles, lors de la création d’une feuille de route de produit, les facteurs que j’ai énumérés ici doivent être pris en compte, même s’ils ne font pas explicitement partie de ces modèles.
Cependant, vous pouvez obtenir un classement des éléments du backlog de produit en réfléchissant simplement à ces cinq facteurs. Lorsque vous faites cela, je ne vous recommande pas de les combiner avec une formule sophistiquée.
La valeur d’une fonctionnalité et son coût, c’est-à-dire nos premier et deuxième facteurs, sont les plus importants. Établissez donc d’abord les priorités en fonction du coût et de la valeur, en utilisant les trois autres facteurs (apprentissage, risque et dépendances) pour ajuster les priorités et résoudre les conflits.
Par exemple, supposons qu’un propriétaire ou un chef de produit ait hiérarchisé un élément de sorte qu’il ne soit pas terminé avant trois ou quatre autres itérations en fonction de sa valeur et de son risque. À ce stade, tenez compte de l’apprentissage, des risques et des dépendances. Avancez l’élément d’une itération ou deux si l’un de ces facteurs est significatif.
5 facteurs pour une hiérarchisation efficace des priorités
Dans les équipes agiles et Scrum, les product owners sont chargés de tenir le backlog produit ordonné par priorité. Une façon simple d’aborder cela, sans utiliser de techniques formelles de hiérarchisation du backlog de produit, est de garder cinq facteurs à l’esprit. Pensez d’abord à la valeur et au coût. Tenez ensuite compte d’autres facteurs qui affectent la priorité d’un élément du backlog produit : L’apprentissage, le risque et les dépendances.
Lorsque vous le faites dans le cadre de vos efforts de planification agile , vos équipes ne se contenteront pas de construire les bonnes choses, elles les construiront dans le bon ordre.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
partagez ce billet avec vos amis, collègues et relations professionnelles
Avec le passage aux licences logicielles par abonnement, il est plus important que jamais pour les utilisateurs de voir la valeur d’un produit. Les meilleurs chefs de produit utilisent l’adoption des fonctionnalités pour mesurer et améliorer la valeur de leur produit. Cette enquête benchmark vise à évaluer la façon dont les fonctionnalités sont reçues par les utilisateurs.
Qu’est-ce que l’adoption d’une fonctionnalité ?
L’adoption des fonctionnalités vise à répondre à une question fondamentale : Les utilisateurs découvrent-ils vraiment la valeur de votre produit et de ses outils de base ?
En comprenant comment (ou si) les clients utilisent des fonctionnalités spécifiques, vous aurez une idée claire de si ces fonctionnalités atteignent leurs objectifs.
Combien d’utilisateurs utilisent les nouvelles fonctionnalités ?
Notre enquête comparative a révélé que le taux moyen d’adoption des fonctionnalités pour les produits est de 6,4%. Ainsi, pour 100 fonctionnalités que votre équipe analyse, construit et livre, seules 6,4 d’entre elles génèrent 80% du volume de clics. Pour les produits du top 10 %, l’adoption des fonctionnalités augmente de 15,6%, soit 2,5 fois plus que la moyenne.
Nous avons constaté que même les meilleures équipes produit se concentrent sur des fonctionnalités qui ne sont pas utilisées par leurs utilisateurs finaux. Alors que 6,4% des fonctionnalités génèrent 80% des clics, près de 94 % des fonctionnalités sont intactes et ignorées.
Adoption des fonctionnalités par industrie
À première vue, l’industrie peut ne pas sembler importante en rapport à l’adoption de la fonctionnalité. Cependant, de petits détails tels que le public cible, la saturation du marché et les nuances de l’industrie s’additionnent pour avoir un impact sur vos benchmarks de produits. Un produit de service aux entreprises avec un taux d’adoption de 7% peut être un succès retentissant. Cependant, l’adoption par 7% des utilisateurs de la nouvelle fonctionnalité de messagerie d’une application de médias sociaux pourrait tirer la sonnette d’alarme.
En moyenne, les produits de l’industrie manufacturière et des biens de consommation ont le taux d’adoption de fonctionnalités le plus élevé. Les produits dans les médias sont légèrement plus faibles, à 4,9%. En fonction de l’adoption moyenne des fonctionnalités de votre secteur d’activité, il peut être important de vous concentrer sur l’amélioration de l’adoption de vos outils les plus importants.
Adoption des fonctionnalités par taille d’entreprise
En moyenne, les entreprises de moins de 200 employés ont le taux d’adoption de leurs fonctionnalités le plus élevé, soit 7,4%. Cela peut s’expliquer par le fait que les petites entreprises n’en sont qu’aux premiers stades de l’expansion de leur produit et que leurs fonctionnalités majeures constituent souvent une plus grande partie de leur produit. D’autre part, les grandes entreprises disposent d’un écosystème tentaculaire de produits, avec plus de ressources pour développer et améliorer les fonctionnalités.
Pourquoi l’adoption des fonctionnalités de suivi est-elle importante ?
Mesurez et comprenez le succès.
Le suivi de l’adoption des fonctionnalités révèle si les utilisateurs trouvent votre produit utile ou non. Associé à votre voix du client (Voice of Customer), vous pouvez comprendre le « pourquoi » d’une adoption plus faible ou plus élevée.
Sachez comment améliorer l’engagement du produit.
Comprenez quelles fonctionnalités vos utilisateurs apprécient réellement et lesquelles ils ignorent. Ceci est fondamental pour fidéliser et fidéliser vos utilisateurs. Utilisez l’adoption de fonctionnalités pour guider vos priorités : Que devez-vous améliorer et que devez-vous supprimer de votre produit ?
Éliminez le gaspillage des ressources.
Une mauvaise adoption des fonctionnalités entraîne un gaspillage des ressources, mais de nombreux produits souffrent d’une prolifération des fonctionnalités. Une fois que vous avez évalué l’adoption des fonctionnalités, vous pouvez avoir une meilleure idée de ce dont vos utilisateurs ont besoin et de ce dont ils n’ont pas besoin.
Améliorez vos résultats finaux.
Des fonctionnalités inutilisées peuvent nuire à vos résultats à plus d’un titre. Payer pour des fonctionnalités inutilisées réduit la valeur perçue d’un client et, en fin de compte, affecte sa volonté de renouveler au niveau de prix actuel, voire de renouveler tout court.
Quatre façons d’améliorer l’adoption des fonctionnalités
Simplifiez l’adoption grâce à des procédures pas à pas.
Annoncez de nouvelles fonctionnalités dans l’application.
Indiquez clairement la valeur et l’action souhaitée.
Ciblez vos communications.
Simplifiez l’adoption grâce à des procédures pas à pas : Il doit être aussi facile que possible pour les clients de trouver et d’utiliser les fonctionnalités. Une fois que vous avez annoncé une nouvelle fonctionnalité, créez des procédures pas à pas au sein même de votre produit pour guider les utilisateurs à travers les étapes souhaitées, en particulier pour les fonctionnalités qui nécessitent plusieurs étapes dans le flux de travail.
Annoncez de nouvelles fonctionnalités dans l’application : L’un des meilleurs outils pour promouvoir des fonctionnalités est votre produit lui-même. Lorsque vous annoncez des fonctionnalités dans l’application à l’aide de guides ou d’ infobulles, vous atteignez les utilisateurs au moment et à l’endroit où le message est le plus pertinent.
Indiquez clairement la valeur et l’action souhaitée : Lorsque vous créez des messages dans l’application ou d’autres contenus sur les fonctionnalités, utilisez un langage simple qui communique clairement la valeur. Ensuite, dirigez les utilisateurs vers la prochaine action que vous souhaitez qu’ils entreprennent (comme visionner une démonstration guidée).
Ciblez vos communications : Toutes les fonctionnalités ne sont pas pertinentes pour tous les utilisateurs. Créez des segments au sein de votre plateforme d’expérience produit par rôle, autorisations et compétences techniques.
Tracez l’adoption des fonctionnalités de votre produit par rapport à vos pairs dans Mind the Product.
partagez ce billet avec vos amis, collègues et relations professionnelles
Nishita Hathi, chef de produit, partage des stratégies pour augmenter l’utilisation des fonctionnalités du produit et améliorer la fidélisation des clients.
Overcoming the 20% feature usage challenge par Nishita Hathi
Beaucoup d’entre nous dans la communauté des produits sont confrontés au défi de l’utilisation limitée des fonctionnalités du produit. Une enquête Pendo a révélé que la plupart des utilisateurs de produits n’utilisent pas 80 % des fonctionnalités du produit. Microsoft a également observé qu’un utilisateur moyen de PowerPoint utilise moins de 10 % des fonctionnalités PowerPoint disponibles. Ma propre expérience s’aligne également sur les résultats de l’enquête Pendo. Pourtant, l’augmentation de l’utilisation des fonctionnalités est cruciale pour fidéliser vos clients et favoriser votre croissance grâce à la vente incitative.
Dans cet article, je partage mes observations sur les motivations derrière l’introduction de nouvelles fonctionnalités, pourquoi les utilisateurs finaux sous-utilisent les fonctionnalités, quel en est l’impact potentiel et je décris les approches que j’ai utilisées pour augmenter l’utilisation des fonctionnalités.
Motivations pour l’introduction de nouvelles fonctionnalités
En tant que chef de produit, vous introduisez de nouvelles fonctionnalités et capacités dans vos produits pour plusieurs raisons :
Vous assurer que le produit est aligné sur les tendances du marché et de la technologie.
Vous assurer que le produit présente des caractéristiques uniques et différenciatrices.
Répondre aux demandes et défis spécifiques de vos clients.
Vous assurer que le produit est comparable à celui d’un concurrent.
Dans le monde B2B, les équipes des achats privilégient souvent les produits riches en fonctionnalités. La plupart des appels d’offres exigent de fournir une gamme complète de fonctionnalités, ce qui oblige les fournisseurs à les prendre en charge dans leurs produits afin de remporter le marché. De plus, dans des secteurs tels que les télécommunications mobiles, les normes technologiques évoluent constamment, ce qui oblige également les fournisseurs à prendre en charge les nouvelles technologies en fonction de l’évolution des normes.
Observations sur l’utilisation des fonctionnalités
Malgré la disponibilité de fonctionnalités complètes, les utilisateurs finaux n’en utilisent souvent qu’un petit sous-ensemble.
D’après mon expérience, cela est attribué à plusieurs facteurs :
Se concentrer sur les besoins immédiats : Les utilisateurs finaux utilisent des fonctionnalités qui les aident à accomplir leurs tâches actuelles.
Manque de temps : Les utilisateurs manquent souvent de temps pour explorer des fonctionnalités supplémentaires, même si celles-ci peuvent apporter une valeur supplémentaire.
Manque de notoriété : Parfois, les utilisateurs ne sont pas au courant ou ont oublié ce qui est disponible dans le produit.
D’autres facteurs limitent également l’utilisation des fonctionnalités, notamment l’inertie à apprendre quelque chose de nouveau ou à faire quelque chose de différent. Avec des fonctionnalités complexes, la facilité de configuration ou le temps nécessaire à l’exécution de tâches spécifiques peuvent également dissuader de les utiliser.
Impact d’une faible utilisation des fonctionnalités
Une faible utilisation des fonctionnalités peut entraîner les conséquences suivantes :
Réduction des opportunités de vente incitative : Une utilisation limitée rend plus difficile la vente de fonctionnalités supplémentaires.
Risque accru de désabonnement : Si les utilisateurs n’utilisent que des fonctionnalités de base ou très limitées, ils peuvent plus facilement se tourner vers des concurrents offrant la même chose.
Approches pour stimuler l’utilisation des fonctionnalités
Afin d’augmenter l’utilisation des fonctionnalités, les utilisateurs finaux doivent être conscients de la valeur des fonctionnalités supplémentaires et doivent être en mesure de les utiliser avec très peu de friction.
Voici les approches que j’ai utilisées ces dernières années pour faire bouger l’utilisation des fonctionnalités :
Engagement régulier des utilisateurs – Apprendre, informer et éduquer
Un engagement régulier avec vos clients vous permet de comprendre leurs besoins et vous donne l’occasion de présenter des fonctionnalités qui peuvent apporter une valeur ajoutée dans le contexte de votre client.
Dans mes interactions avec les clients, j’ai rencontré des situations où le client essaie de résoudre un problème et n’est pas conscient de la capacité du produit à résoudre le problème, comme des moyens plus simples de configurer le produit pour leur cas d’usage ou la possibilité d’effectuer des types de modélisation spécifiques.
En plus d’informer et d’éduquer, ces interactions régulières peuvent également conduire à de nouveaux cas d’utilisation des capacités existantes.
Mises à jour fréquentes des fonctionnalités et accès facile aux informations
La présentation des fonctionnalités dans le cadre d’un atelier aide vos utilisateurs à comprendre l’étendue des capacités. Cependant, il est probable qu’ils ne se souviendront pas de tout ce que vous avez présenté. Par conséquent, il est important de fournir des mises à jour fréquentes. Il peut être difficile d’avoir du temps en face à face avec vos clients sur une base régulière et cela peut devenir écrasant. Il est important d’exploiter différents formats pour promouvoir les fonctionnalités de vos produits.
L’une des approches que j’ai utilisées consiste à partager de brèves vidéos explicatives (2 à 3 minutes) sur une base mensuelle par e-mail et sur les plateformes de médias sociaux. Chaque vidéo se concentre sur un aspect très spécifique du produit. Il peut s’agir d’un ensemble de fonctionnalités d’utilisabilité qui entraînent une réduction du nombre de clics ou d’une fonctionnalité technologique qui leur permet de modéliser une nouvelle technologie. L’objectif est de démontrer et d’informer l’utilisateur de la valeur ajoutée que votre produit peut créer.
La disponibilité de plateformes de synthèse vocale telles que Synthesia facilite la création de vidéos explicatives.
Mise en œuvre simplifiée
Une fois que l’utilisateur est convaincu qu’une fonctionnalité ou une capacité particulière peut apporter une valeur ajoutée, il est important de s’assurer qu’il y a très peu de frictions lors de la configuration et de l’exécution de cette capacité. Lorsqu’il s’agit de fonctionnalités complexes, les utilisateurs s’abstiennent souvent de les utiliser car elles sont complexes à configurer. Même si le produit peut disposer d’un ensemble complet de documents de support tels que des guides d’utilisation, des guides techniques, des vidéos explicatives, il est souvent difficile de s’y retrouver dans un volume élevé d’informations.
Plus récemment, j’ai exploré l’utilisation de l’IA générative pour changer la façon dont les utilisateurs interagissent avec les différents supports de produit. Au lieu de rechercher dans des documents individuels, l’utilisateur peut poser des questions spécifiques et obtenir une réponse cohérente, ce qui rend le processus beaucoup plus fluide.
Culture interne d’apprentissage continu
En plus de faire référence aux garanties, vos utilisateurs auront parfois besoin d’un soutien supplémentaire de la part des équipes en contact avec les clients. Il est important d’établir une culture interne d’apprentissage continu afin de s’assurer que vos équipes en contact avec votre clientèle peuvent promouvoir et défendre les capacités de votre produit.
Voici quelques-unes des approches que j’ai mises en œuvre :
Un webinaire interne mensuel régulier sur un sujet ou une fonctionnalité spécifique.
Une plateforme LMS (Learning Management System) interne pour héberger le matériel de formation sur les produits.
Un programme d’évaluation interne qui mène à une certification et à d’autres récompenses.
Réflexions finales
À l’avenir, l’IA offre des opportunités pour accroître drastiquement l’utilisation de toutes vos fonctionnalités. Lors du lancement de Microsoft Office 365 Copilot, son vice-président principal, Sumit Chauhan, s’est demandé :
Et si les outils pouvaient apprendre comment vous travaillez, plutôt que l’inverse ?
Cela signifierait que les utilisateurs seraient automatiquement informés des fonctionnalités qui généreraient plus de valeur pour eux et guidés sur la façon d’exploiter les fonctionnalités, ce qui entraînerait une utilisation beaucoup plus élevée de celles-ci !
partagez ce billet avec vos amis, collègues et relations professionnelles
L’opposé d’une usine à fonctionnalités est une équipe responsabilisée qui se concentre sur les résultats et qui est impatiente de montrer ses livrables et de s’adapter en permanence en fonction des retours des utilisateurs.
Releasing new features nobody cares about par David Pereira
Quelle est votre expérience lors de la sortie de nouvelles fonctionnalités ? Peut-être est-ce un peu aléatoire. Malheureusement, de nombreuses équipes tombent dans le piège de devenir des usines à fonctionnalités. Dans son livre, David Pereira, coach produit et auteur, aide les équipes à surmonter ces pièges dangereux et à créer des produits que les clients aiment vraiment.
Vous trouverez ci-dessous un court extrait de son livre sur la sortie de fonctionnalités dont personne ne se soucie. Si vous aimez ce que vous lisez, vous pouvez obtenir le livre complet ici.
Comment fonctionnent les entreprises « Feature Factory » (usines à fonctionnalités) ?
Après des mois de travail acharné et une coordination exhaustive, l’équipe produit publie enfin une nouvelle fonctionnalité. Tout le monde dans l’équipe et dans l’entreprise l’adore. La nouvelle fonctionnalité brillante est prête pour les clients, mais quelque chose d’inattendu se produit. Les clients qui interagissent avec la nouvelle fonctionnalité ne comprennent pas son objectif et n’en tirent pas de bénéfices. Confus, les clients rejettent la nouvelle fonctionnalité brillante tant appréciée des parties prenantes de l’entreprise, et inévitablement, tout le monde est frustré.
Construisez-vous des fonctionnalités dont les clients n’ont pas besoin ?
Ce n’est pas la raison d’être des équipes produit que de créer des solutions que leur entreprise adore mais dont les clients se moquent. Pourtant, cela se produit plus souvent qu’il ne le devrait. J’appelle cela un bug, pas une fonctionnalité. Comme pour tous les bogues critiques, il nécessite un correctif.
Le remède : Des équipes responsabilisées grâce à des flux collaboratifs.
Si l’usine à fonctionnalités est un bogue, qu’est-ce qui résoudrait cela ? Vous ne pouvez pas vous attendre à une solution simple, mais la promotion d’équipes autonomes avec des flux collaboratifs transformera la situation.
Marty Cagan, partenaire SVPG, définit les équipes responsabilisées comme suit :
« Les grandes équipes sont composées de gens ordinaires qui sont responsabilisés et inspirés. Ils sont habilités à résoudre des problèmes difficiles d’une manière que leurs clients aiment, tout en travaillant pour leur entreprise. Ils sont inspirés par des idées et des techniques pour évaluer rapidement ces idées afin de découvrir des solutions qui fonctionnent : elles sont précieuses, utilisables, réalisables et viables. »
Comment les méthodes de travail courantes piègent-elles ou libèrent-elles les équipes ?
Les équipes responsabilisées ont beaucoup plus de chances de créer de la valeur que les équipes d’usine à fonctionnalités. Pourtant, il n’est pas facile de responsabiliser les équipes. Pour l’instant, concentrons-nous sur les défis de la collaboration.
Flux de développement de produits coordonnés ou collaboratifs
Au fil des ans, j’ai remarqué 2 flux standard de développement de produits dans les entreprises, quel que soit leur cadre :
Flux de coordination : Les membres de l’équipe passent beaucoup de temps à coordonner les activités entre eux, les parties prenantes et les autres équipes. La majeure partie de leur énergie est consacrée à l’organisation de la façon de faire le travail. Cette approche vise à éviter les erreurs et les échecs, obligeant les équipes à être rigides dans leur flux de développement. Cela devient un contrat « strict » parce que quelqu’un est blâmé lorsque quelque chose ne va pas.
Flux collaboratif : Les membres de l’équipe se concentrent sur la collaboration pour utiliser leurs connaissances actuelles afin de découvrir des opportunités prometteuses. L’objectif ultime est de créer de la valeur pour les clients et l’entreprise. L’équipe est flexible dans la façon dont elle fait le travail tout en se concentrant sur la création de valeur. La confiance est à la base de l’approche collaborative. Lorsque quelque chose déraille, l’équipe prend ses responsabilités et trouve ensemble une solution.
Le flux coordonné : Une façon logique de travailler avec des résultats inattendus
Comment transformer une idée en quelque chose de précieux ? C’est l’une des questions les plus importantes pour les entreprises. Une mauvaise réponse conduit au gaspillage et à la démotivation.
Les étapes d’un flux coordonné
Priorisation : Le flux de coordination commence par la hiérarchisation, visant à trouver l’idée la plus prometteuse. Cependant, c’est plus facile à dire qu’à faire car plusieurs tours de discussion auront lieu. Lorsque vous dites oui à une idée, vous dites non à de nombreuses autres, et presque aucune partie prenante de l’entreprise n’accepte facilement cette réponse
Conception : La phase de conception commence une fois que vous avez défini ce sur quoi l’équipe va travailler. Le résultat est souvent un prototype haute-fidélité que les parties prenantes de l’entreprise approuvent. Cette approche est dangereuse car les ingénieurs logiciels et les clients ont tendance à être laissés à l’écart. Malheureusement, la solution devient l’objectif, et non le résultat.
Test utilisateur : Après beaucoup de coordination, les parties prenantes de l’entreprise approuvent finalement la conception et il est temps de la tester avec des clients potentiels. Les résultats sont probablement biaisés car tout le monde aime déjà la solution. Malheureusement, être la proie du biais de confirmation n’est pas l’exception, mais plutôt le résultat typique. Compte tenu de leur passion pour la solution, les concepteurs de produits recherchent des signes positifs et, sans surprise, ils les trouvent. Ils peuvent accepter des ajustements mineurs de la solution, mais aucun pivot ou abandon de solution ne se produira dans cette phase.
Développement : Une fois que les concepteurs de produits ont confirmé que le prototype haute-fidélité a du sens pour les utilisateurs finaux, il est temps de développer la solution. Les concepteurs de produits jettent les spécifications par-dessus le mur et espèrent que les ingénieurs logiciels font le bon travail. Bien sûr, il est peu probable que les ingénieurs logiciels accueillent la solution à bras ouverts, car ils n’ont pas participé aux étapes précédentes. Malgré cela, c’est à eux de transformer le prototype haute-fidélité en une solution fonctionnelle.
Lancement : Compte tenu de la quantité de coordination nécessaire, il faut des mois pour transformer une idée en solution. Vous ne devriez pas être surpris quand quelque chose prend six mois. Chaque phase est strictement définie et comporte de nombreuses étapes pour assurer une solution parfaite à la fin de celle-ci. Pourtant, quelque chose d’inattendu se produit lorsque vous lancez la solution. Malgré tout l’enthousiasme interne et l’amour pour la nouvelle solution sophistiquée, les clients ne s’y intéressent pas, et vous ne savez pas pourquoi.
Ce qui me choque, ce n’est pas de me retrouver dans cette situation tragique. J’y suis allé plus de fois que je ne peux compter, mais j’ai appris la leçon. La question est de savoir ce que vous faites après avoir été confronté à un résultat indésirable. La réponse la plus courante n’a guère de sens pour moi. Revenez à la hiérarchisation, choisissez une autre idée et recommencez. Lorsque vous suivez la même approche, il y a de fortes chances que vous soyez à nouveau confronté aux mêmes résultats. Le flux de coordination oblige les équipes à se concentrer sur les résultats plutôt que sur les résultats, ce qui les réduit au rang d’usines.
9 idées sur 10 échoueront
Notre taux de réussite est pire que ce que nous pouvons imaginer. Regardez les start-up : 90% d’entre elles ne tiennent pas plus de cinq ans. Les idées subissent à peu près le même sort. Curieusement, cela passe inaperçu car les équipes investissent beaucoup de temps à trouver comment réduire le temps de développement. Je vois de la valeur dans cette affaire, bien que je perçoive une autre question comme plus urgente : « A quelle vitesse pouvez-vous laisser tomber les mauvaises idées ? »
Nous supposons que nos idées sont bonnes, mais la réalité nous montre le contraire. Pourtant, nous insistons pour suivre la même approche à plusieurs reprises. Pas étonnant que nous soyons confrontés à des résultats indésirables.
Un bon management de produit nécessite de s’adapter en apprenant. C’est OK de se tromper. Il n’est pas bon d’ignorer la réalité. La collaboration plutôt que la coordination est le principe qui peut vous sortir de ce piège. Au lieu de rendre votre flux de développement rigide et complexe, vous bénéficierez d’une simplicité et d’une flexibilité accrues. Explorons une autre méthode de travail qui augmente les chances de générer de la valeur plus rapidement.
Flux collaboratif : Une méthode de travail simple qui apporte des résultats exceptionnels.
Personne ne mérite de perdre du temps. Après de nombreuses années d’expérience, j’ai appris que les échecs sont inévitables. Au lieu d’ajouter des étapes pour prévenir les échecs, il est plus logique d’identifier et d’abandonner rapidement les mauvaises idées. Contrairement au flux coordonné, le flux collaboratif se concentre sur des itérations plutôt que sur des phases.
Les étapes d’un flux collaboratif
Évaluez : Le début d’un flux collaboratif est le même que pour un flux coordonné. Vous avez plein d’idées, et tout le monde veut que tout soit terminé d’hier. L’astuce n’est pas d’identifier les idées les plus prometteuses dès le départ, mais plutôt de les évaluer toutes et de laisser tomber celles qui ne conviennent pas. Laisser tomber des idées vous donne de la liberté parce que vous avez moins d’attentes à gérer.
Apprenez : L’itération d’apprentissage commence par des idées adaptées à votre stratégie, mais cela ne signifie pas qu’il faille passer directement à la mise en œuvre. Vous devriez laisser tomber les idées que vos clients ne désirent pas, que l’entreprise ne peut pas soutenir, que vous n’avez pas la technologie pour développer ou qu’il est contraire à l’éthique de poursuivre. Restez simple et posez les questions suivantes sur chaque idée restante :
À quel point les clients veulent-ils ceci ? (Désirabilité)
Quels sont les bénéfices pour l’entreprise ? (Fiabilité)
Dans quelle mesure pouvons-nous le faire ? (Faisabilité)
À quel point est-il bien de le faire ? (Éthique)
Expérimentez : Après avoir compris les aspects clés de vos idées, il est temps de mener des expériences plus robustes. Vous voulez tester les solutions qui peuvent donner les résultats potentiels. Il est essentiel d’explorer quelques alternatives et de s’en tenir aux plus prometteuses. Il est trop courant de choisir une solution et de se lancer à fond. Je vous décourage de suivre cette voie, car elle augmente rapidement l’engagement. En tant qu’êtres humains, plus nous sommes investis dans quelque chose, plus nous y investissons volontiers.
Déployez : Les idées qui survivent à l’itération de l’expérience sont les plus importantes. Dans l’itération précédente, vous avez construit pour apprendre. Maintenant, vous créez pour évoluer. Il est fondamental de rembourser la dette technologique avant de mettre la solution à la disposition de l’ensemble de votre public ou de passer à votre prochaine opportunité
Principaux points à retenir
La première étape pour libérer votre équipe consiste à examiner votre situation actuelle. Comprendre la dynamique peut révéler des opportunités pour simplifier votre flux de développement.
Les symptômes d’une usine à fonctionnalités comprennent l’absence d’objectifs, l’obsession de la production, la fourniture de solutions qui ne résolvent aucun problème, une direction peu claire, une réticence à laisser tomber des idées et un manque d’attention aux résultats. L’opposé d’une usine à fonctionnalités est une équipe responsabilisée qui se concentre sur les résultats et qui est impatiente d’examiner ses livrables et de s’adapter en permanence.
Plus vous vous rapprochez d’un flux de développement coordonné, plus il faut de temps pour générer de la valeur et plus vous créez de déchets. Les flux coordonnateurs transforment involontairement les plans en objectifs.
Plus vous vous rapprochez d’un flux de développement collaboratif, plus tôt vous créez de la valeur et moins vous produisez de déchets. La collaboration vous aide à adapter vos plans pour atteindre vos objectifs lorsque la réalité rend votre plan obsolète.
Lorsque vous comprenez parfaitement le flux de développement d’un produit, vous pouvez favoriser les changements étape par étape. La première étape consiste à collaborer avec les parties prenantes de l’entreprise et les membres de l’équipe pour reconnaître ce qui est inutilement complexe. Équipé de cette compréhension, vous pouvez obtenir du soutien et collaborer pour simplifier votre travail.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
partagez ce billet avec vos amis, collègues et relations professionnelles
L’une des difficultés les plus courantes rencontrées par les équipes agiles est la nécessité de découper des histoires utilisateur. Je suis sûr que vous avez aussi eu du mal avec cela. C’est certainement ce que m’est arrivé au début.
En fait, quand j’ai commencé à utiliser Scrum, dans certains de nos arriérés de produit, les histoires étaient si grosses que nous avons parfois opté pour des sprints de six semaines. Avec un peu plus d’expérience, cependant, cette équipe et moi avons vu suffisamment de façons de décomposer le travail pour que nous puissions faire des sprints d’une journée si nous l’avions voulu.
Mais décomposer les histoires a été difficile au début. Vraiment dur.
J’ai de bonnes nouvelles pour vous. Non seulement j’ai compris comment découper des histoires par moi-même, mais j’ai aussi appris à expliquer comment le faire afin que tout le monde puisse rapidement devenir un expert. (Si vous voulez jeter un coup d’œil dans les coulisses de vraies histoires d’utilisateurs de certains de mes premiers backlogs de produits, avec des commentaires sur ce que je ferais différemment aujourd’hui : Télécharger 200+ exemples de User Story).
Ce que j’ai découvert, c’est que presque toutes les histoires peuvent être divisées avec l’une des cinq techniques suivantes. Apprenez ces cinq techniques simples et vous êtes prêt.
Mieux encore, les cinq techniques forment un acronyme facilement mémorisable : SPIDR.
Je présente chaque technique ci-dessous, et cette vidéo les montre en action.
Technique SPIDR pour diviser les histoires
Il y a quelques années, je créais le cours « Better User Stories ». Parce que ce cours couvrirait tout ce que quelqu’un doit savoir pour travailler efficacement avec des histoires, je savais qu’il fallait d’un module sur le fractionnement.
Pour créer ce module, j’ai imprimé plus d’un millier d’histoires ‘utilisateur que j’avais rassemblées pendant 15 ans. Pour chaque histoire, j’avais l’histoire originale et les sous-histoires dans lesquelles elle avait été divisée. J’ai collé chaque histoire sur le mur, en les regroupant en fonction de la façon dont elles avaient été divisées. Je cherchais les approches communes utilisées pour découper toutes ces histoires. Je suis passé par une variété de regroupements, en essayant de trouver le plus petit ensemble d’approches possible. Je savais qu’il serait plus facile de se souvenir de 5 techniques de fractionnement plutôt que de 20.
Les cinq que j’ai obtenues forment l’acronyme SPIDR : S, P, I, D et R (spider sans E).
Jetons un coup d’œil aux cinq techniques de fractionnement des user stories qui composent l’acronyme SPIDR, avec des exemples de la façon dont votre équipe pourrait les utiliser.
#1 – Diviser les User Stories à l’aide d’un Spike
S comme Spike. C’est un problème que la plupart des équipes agiles connaissent. Un spike est une activité de recherche qu’une équipe entreprend pour en savoir plus sur un élément de l’arriéré. Les spikes peuvent également donner aux équipes les connaissances dont elles ont besoin pour diviser une histoire complexe. Considérez-le comme une activité de recherche, mais il peut inclure du prototypage ou du codage expérimental.
Au cours d’un spike, une équipe n’essaie pas de développer la nouvelle fonctionnalité, mais plutôt de développer de nouvelles connaissances qui l’aideront à développer la fonctionnalité plus tard.
Prenez YouTube par exemple. Remontez dans le temps, à l’époque où YouTube ajoutait le sous-titrage automatique. L’équipe qui s’est chargée de cela aurait peut-être été confrontée à une décision de construction ou d’achat. Utilisent-ils un logiciel disponible dans le commerce pour générer les sous-titres ? Ou leurs besoins sont-ils si uniques qu’ils doivent développer quelque chose à partir de zéro ? La façon de régler cela serait un spike pour tester un ou plusieurs produits de sous-titrage disponibles dans le commerce.
L’extraction d’un spike réduit la taille de l’article d’origine, car une partie ou la totalité des recherches incluses dans l’article d’origine est supprimée. C’est absolument un moyen essentiel de diviser les histoires. L’extraction d’un spike est donc l’une des cinq techniques de fractionnement que vous devriez utiliser. Mais normalement, ce ne sera pas la première technique que vous utiliserez.
#2 – Diviser les User Stories par Path (chemin)
P comme Path. Si un utilisateur peut faire quelque chose de plusieurs façons (par exemple, payer avec une carte ou Apple Pay), c’est un excellent domaine pour diviser.
Pour diviser une histoire en chemins, recherchez d’autres chemins d’accès à travers l’histoire.
Pour rester sur YouTube, utilisons l’histoire : « Je peux partager une vidéo avec mes amis ».
Lorsque je clique sur le bouton « Partager » sur YouTube aujourd’hui, on me montre 14 boutons sur lesquels je peux cliquer pour partager directement sur divers réseaux sociaux. On me montre également un lien que je peux copier. Et j’ai la possibilité de personnaliser ce lien pour démarrer la lecture de la vidéo partagée à un moment précis de la vidéo.
Il s’agit de 16 chemins différents à travers l’histoire « Je peux partager une vidéo ». Je ne sais pas si cette histoire a besoin d’être divisée en autant de sous-histoires plus petites. C’est à l’équipe de décider en fonction de l’effort impliqué. Mais, avec la seule technique du chemin, nous avons identifié 16 chemins à travers l’histoire originale.
#3 – Diviser les User Stories par Interfaces
I est pour Interfaces : Diviser votre histoire par navigateur ou matériel, ou fournir une interface complexe par itérations. Par exemple, vous pouvez proposer une version qui ne fonctionne que dans Chrome dans cette itération et prévoir Safari pour une autre itération.
Dans d’autres cas, le découpage par interface signifie la création d’une version simple de l’interface et d’une version plus complexe en tant qu’histoires distinctes. Cela s’applique généralement à l’interface utilisateur.
En appliquant cela à notre exemple de partage de vidéos YouTube, au lieu de diviser cette histoire par des chemins, nous aurions pu séparer une histoire de partage de base telle que : « En tant que spectateur de vidéos, je peux obtenir une URL que je peux partager ». Cela pourrait être mis en œuvre sans autre interface utilisateur qu’un bouton de partage sur la page vidéo. La fenêtre contextuelle avec les 16 différentes façons de partager ne serait pas nécessaire si la seule façon de partager est avec une URL.
Une histoire ultérieure pourrait être : « En tant que spectateur, je peux partager une vidéo sur divers sites de médias sociaux. » Cela pourrait être fait avec une interface utilisateur très simple au début – pas de fantaisie de faire défiler une liste de logos, peut-être juste une liste déroulante de texte avec les noms des sites sociaux.
L’histoire finale pourrait alors ressembler à quelque chose comme : « En tant que spectateur, je peux choisir le réseau social sur lequel partager en faisant défiler une liste montrant les logos de chacun. »
La division par interface fonctionne parce que la fonctionnalité finalement souhaitée peut être atteinte par des interfaces de plus en plus détaillées et meilleures.
#4 – Diviser les User Stories par Data / Données
Le D de l’acronyme SPIDR signifie Données. Pour diviser une histoire par données, demandez-vous si vous pouvez apporter de la valeur dans une itération en simplifiant ou en limitant les données prises en charge. Peut-être pouvez-vous faire une version initiale d’une histoire qui ne traite qu’un sous-ensemble des données qui devront finalement être prises en charge. Par exemple, n’autorisez pas les soldes bancaires négatifs dans la première itération. Ajoutez la prise en charge de ceux avec une histoire utilisateur différente dans la prochaine itération.
Pour revenir à l’exemple de YouTube, YouTube vous permet de télécharger une vidéo dans l’un des 16 formats de fichiers différents. Si nous construisons un concurrent de YouTube, oublions les 16 formats de fichiers. Commençons par 1. Nous allons prendre en charge un type de données. Pour l’instant, tous les téléchargements doivent être au format MP4. Nous ajouterons tous les autres plus tard en tant qu’histoires distinctes.
Le fractionnement par données est une approche efficace. Souvent, il y a quelques types de données qui ajoutent beaucoup de complexité. Eh bien, faites une mise en œuvre initiale qui ignore les données les plus complexes. Faites en sorte que cela fonctionne, puis ajoutez la prise en charge des données plus complexes. Vous ne pouvez probablement pas mettre en production la version la plus simple, mais vous pouvez toujours la construire dans cet ordre.
J’ai travaillé sur un système de ressources humaines qui faisait exactement cela. Le système suivait qui était le manager pour chaque employé et faisait des choses comme acheminer les demandes de congé à ce manager. La plupart des employés ont un manager, mais certains employés en ont plusieurs. Nous devions supporter le fait d’avoir plusieurs managers, mais certaines histoires ont été simplifiées au départ en supposant que chaque employé avait uniquement un manager.
#5 – Diviser les User Stories par des Règles / Rules
R comme Règles. Le relâchement temporaire de l’implémentation de règles qu’un article devra au final prendre en charge peut réduire la taille des grandes histoires.
Si l’on s’en tient à YouTube, par exemple, YouTube a des règles strictes concernant l’inclusion de musique protégée par des droits d’auteur dans les vidéos. Si nous construisons un concurrent à YouTube, la première histoire de notre équipe sera : « Je peux télécharger une vidéo pour que d’autres puissent la regarder. » Cette histoire semble probablement simple, mais il y a déjà beaucoup de choses à faire.
Donc, dans la première itération, ignorons la règle selon laquelle les vidéos ne peuvent pas contenir de musique protégée par des droits d’auteur. De toute façon, nous n’annonçons pas notre nouveau concurrent à YouTube au monde après une seule itération. Nous aurons tout le temps après ce premier sprint de nous conformer à notre règle interne interdisant les vidéos contenant de la musique protégée par des droits d’auteur.
Comme cet autre exemple lié à YouTube, supposons que nous voulions empêcher certains textes d’apparaître dans les commentaires. Il peut s’agir de jurons ou de commandes SQL qui peuvent être des tentatives de piratage. Bonne idée : Protégeons nos utilisateurs et notre système de ce type de texte dans les commentaires. Mais une première histoire du type « En tant qu’utilisateur, je peux entrer un commentaire sur une vidéo » peut ignorer cette règle. Cela rend l’histoire plus petite afin qu’elle puisse s’intégrer dans une itération. Et la prise en charge de la règle peut être ajoutée quelques itérations plus tard.
S’améliorer dans le fractionnement des histoires
S’améliorer dans le découpage des histoires d’utilisateurs est une compétence importante. Avec les courtes itérations utilisées en agile, il est utile d’avoir de petites unités de travail. Les cinq techniques que nous avons abordées ici (fractionnement par Spikes, Paths, Interfaces, Données et Règles) devraient vous permettre de fractionner n’importe quelle histoire.
Les techniques SPIDR sont faciles à retenir, mais leur mise en pratique peut nécessiter un peu d’entraînement et beaucoup de pratique. C’est pourquoi j’ai mis en place un cours vidéo « Better User Stories » qui inclut la méthode SPIDR pour diviser les histoires, et bien plus encore.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
partagez ce billet avec vos amis, collègues et relations professionnelles
La session d’affinement de l’arriéré de produit n’est pas un événement Scrum obligatoire, mais une pratique complémentaire très utile qui aide l’équipe Scrum et ses parties prenantes à parvenir à une compréhension commune de l’arriéré de produit, de l’objectif produit et des priorités.
La session d’affinement de l’arriéré de produit (Product Backlog Refinement) n’est pas un événement Scrum officiel, mais c’est une activité cruciale qui aide les équipes Scrum à parvenir à une compréhension commune des éléments de l’arriéré de produit en préparation à la planification du sprint. Les équipes qui adoptent l’amélioration de l’arriéré de produit comme pratique complémentaire ont tendance à avoir des événements de planification de sprint plus fluides. Le nombre de sessions de raffinement au sein d’un sprint dépend de divers facteurs tels que l’état de l’arriéré de produit, la maturité du produit, la disponibilité et l’expérience de l’équipe Scrum.
Il y a de nombreuses de façons de faciliter une session d’affinement de l’arriéré de produit, mais je présente ici certaines des activités que j’attendrais d’une équipe Scrum dans l’une de ces sessions. Celles-ci ne sont pas présentées dans un ordre particulier.
Ventiler les éléments de l’arriéré de produit (Product Backlog Items / PBI)
Dans la session d’affinement de l’arriéré de produit, l’équipe Scrum doit chercher à décomposer les PBI jusqu’à ce qu’ils soient suffisamment petits pour tenir dans le sprint.
La définition de terminé (done) doit être utilisée comme guide pour discuter du travail à accomplir pour chaque PBI du sprint.
Il y a de nombreuses techniques qui peuvent être utilisées pour décomposer les PBI, mais je préfère le découpage vertical des PBI, car l’équipe Scrum a une plus grande probabilité de fournir un incrément utilisable à partir d’un PBI, lorsque le PBI est découpé verticalement.
Estimer les PBI
Les équipes Scrum qui pratiquent l’estimation en tant que pratique complémentaire doivent fournir une prévision de l’effort requis pour fournir des PBI en utilisant la définition de terminé (done) pour le produit comme guide.
Pour ces équipes, l’estimation des PBI aide l’équipe Scrum à sélectionner des éléments de l’arriéré de produit jusqu’à la pleine capacité des développeurs. Si des estimations ont déjà été fournies pour les PBI, l’animateur de la session d’affinement de l’arriéré de produit doit reconfirmer que chaque développeur reste à l’aise avec l’estimation qui a été précédemment enregistrée sur le PBI.
Les critères d’acceptation devraient être revus pour en vérifier la clarté et l’exhaustivité lors de la séance d’amélioration de l’arriéré de produit. L’animateur doit inviter les participants à la session d’amélioration de l’arriéré de produit à poser des questions et à demander des éclaircissements si nécessaire. Il y a des cas où l’équipe n’arrive pas à s’entendre sur les critères d’acceptation, en particulier pour un PBI complexe ; L’équipe Scrum pourrait alors trouver utile de réexaminer le « pourquoi ? ». Le Product Owner doit être en mesure d’exprimer clairement la valeur du PBI ; D’après mon expérience, une fois que la valeur est transparente pour tous les participants, les développeurs peuvent s’autogérer pour déterminer les détails de ce qui doit être fait et comment le travail serait accompli.
Discutez des dépendances et des blocages
Attention aux dépendances croisées qui s’emmêlent et créent des nœuds inextricables.
Cela n’aurait aucun sens d’intégrer une histoire utilisateur / story avec des dépendances et des blocages dans un sprint, car cette story ne sera probablement pas terminée dans le sprint. L’équipe Scrum doit discuter de toutes les dépendances et de tous les bloqueurs pour s’assurer que tout le monde a une compréhension commune des dépendances et des blocages ; L’équipe Scrum doit mettre en place un plan pour résoudre ces dépendances et ces blocages. Le cas échéant, ces dépendances et blocages doivent être représentés dans l’arriéré de produit et attribuées aux personnes qui travaillent à les supprimer. À titre indicatif, l’équipe Scrum ne doit PAS présenter d’éléments avec des dépendances et des blocages non résolus pour la planification du sprint, sauf s’il existe un plan pour résoudre ces obstacles au sein du sprint.
Priorisez l’arriéré de produit
Le Product Owner est responsable de la priorisation de l’arriéré de produit et il existe un certain nombre de raisons qui peuvent être prises en compte telles que la Valeur, la Priorité, la Cohérence Business, la Cohérence Technique, etc. Le Product Owner doit prendre l’habitude de garder l’arriéré produit ordonné à tout moment et une session telle que la session d’affinement de l’arriéré de produit est un bon moment pour examiner et mettre à jour l’ordre des PBI dans l’arriéré de produit.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
Comme indiqué dans l’introduction, la session d’amélioration de l’arriéré de produit n’est pas un événement Scrum obligatoire, mais une pratique complémentaire très utile qui aide l’équipe Scrum et ses parties prenantes à parvenir à une compréhension commune de l’arriéré de produit, de l’objectif produit qu’il contient et des éléments de l’arriéré de produit qui ont émergé pour atteindre l’objectif produit.
Sam Adesoga
Sam Adesoga
Coach Agile Principal et Formateur Principal at Valuehut, un cabinet de conseil en coaching et formation agile, qui aide les organisations à explorer les méthodes de travail agiles. Sam a beaucoup d’expérience dans le soutien aux dirigeants et à leurs équipes en matière d’agilité d’entreprise avec un objectif ambitieux : Aider les organisations à développer un état d’esprit agile nécessaire pour continuer à garder une longueur d’avance sur la concurrence et les marchés.
partagez ce billet avec vos amis, collègues et relations professionnelles
La plupart des méthodologies agiles prévoient l’application d’un Technical Spike pour explorer une nouvelle technologie ou les zones à risque d’un produit. La méthodologie SAFe (Scaled Agile Framework) définit le Spike comme un type d’histoire d’exploration et de catalyseur.
Il existe un certain nombre d’approches qui ont été recommandées pour les Technical Spike.
Il s’agit notamment de :
Estimation et dimensionnement d’une histoire de Technical Spike
Limiter dans le temps (Timeboxing) un Technical Spike.
Le Technical Spike est de nature exploratoire et il est contradictoire d’essayer d’estimer la complexité d’un travail qui n’est pas bien compris. D’après mon expérience, la plupart des équipes préféreraient limiter dans le temps les efforts nécessaires pour réaliser un Technical Spike.
Il y a quelques semaines, j’ai eu une conversation avec un développeur qui était à mi-chemin d’un spike et j’ai eu un moment « ah-ha », et cet article est une tentative d’expliquer ce qui pourrait être une approche alternative aux Technical Spikes.
Je suggérerais au Product Owner / Business Analyst en collaboration avec unmembre technique de l’équipe, par exemple un architecte, un responsable technique, de définir les exigences de haut niveau à l’aide de la méthodologie de développement axée sur le comportement.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
Les avantages de la spécification des exigences axée sur le comportement dès le départ sont les suivants.
L’objectif du Technical Spike est clairement défini à l’avance et, en tant que tel, le développeur est clair sur ce qu’est le livrable.
La définition de DONE pour le Technical Spike est dès que toutes les exigences spécifiées sont satisfaites.
Le développeur ou un testeur peut automatiser le script de développement axé sur le comportement en exigences exécutables.
Le risque de consacrer trop de temps/d’efforts au Technical Spike est minimisé.
Une ligne de base d’exigences pour la mise en œuvre réelle évolue à partir du Technical Spike.
Comme pour tout le reste, il n’y a pas de solution miracle, mais il faut veiller à ne pas aller trop loin avec les exigences. Étant donné qu’il s’agit d’un Technical Spike, il est nécessaire de s’assurer que l’exigence est à un niveau très élevésuffisant pour décrire les objectifs du Technical Spike et qu’elle ne soit pas prescriptive.
Cela semble bien fonctionner pour ce projet, alors n’hésitez pas à l’essayer.
Sam Adesoga, Principal Coach and Lead Trainer
Praticien agile et agnostique ainsi qu’un formateur professionnel Scrum avec Scrum.org
L’expérience professionnelle de Sam comprend Développeur, Développeur de logiciels, Test and Release Manager, Scrum Master et récemment coach Agile d’entreprise
Sam utilise des approches agiles comme fondation, et s’intéresse à aider les individus, les équipes et l’ensemble des organisations à développer l’état d’esprit et la culture nécessaires pour réussir dans un monde VUCA.
Nombre total d’années d’expérience dans le développement et la livraison de produits à l’aide de cadres de travail agiles – 17 ans.
partagez ce billet avec vos amis, collègues et relations professionnelles
Le paysage concurrentiel actuel est en évolution rapide, caractérisé par l’arrivée de nouveaux acteurs dans des domaines d’activité établis, l’évolution des besoins des utilisateurs et l’introduction de nouvelles technologies à un rythme très rapide. La plupart des organisations ne peuvent suivre ce rythme et l’agilité organisationnelle est une capacité essentielle pour votre réussite.
Les leaders sont souvent désireux de comprendre l’impact de l’adoption de méthodes de travail agiles et, dans cet article, nous explorons 5 indicateurs clés qui aident les leaders à suivre l’amélioration des équipes et des produits dans l’ensemble de l’organisation. Ces métriques sont d’excellents indicateurs pour ouvrir la voie à l’innovation, à la résilience et à une croissance soutenue.
#1 – Fréquence de livraison (de sortie)
Une mesure de la fréquence à laquelle une organisation délivre des mises à jour de son ou ses produits est l’un des principaux indicateurs du développement de ses capacités d’agilité business. Les approches agiles telles que Scrum aident les organisations à livrer fréquemment de la valeur aux utilisateurs. Avant même qu’un produit ne soit construit, la valeur qu’il apporte à ses utilisateurs cibles est estimée et les organisations valident les hypothèses lorsque le produit est finalement mis à la disposition du client. Une organisation dont la fréquence de sortie est plus rapide recueille potentiellement plus fréquemment les commentaires de ses utilisateurs.
L’organisation doit s’efforcer d’augmenter la fréquence de mise sur le marché de ses produits au fil du temps. Une fréquence de sortie plus élevée améliore l’agilité de l’entreprise en permettant une innovation plus rapide, une réactivité aux besoins des clients et une adaptabilité aux changements du marché.
Il y a un certain nombre de facteurs que nous pourrions prendre en compte pour augmenter la fréquence de sortie de ses produits :
Tests fonctionnels et non fonctionnels automatisés.
Amélioration des capacités de management de produits, y compris la capture et l’analyse des commentaires des utilisateurs.
Créer des équipes inter-fonctionnelles dans le cadre des efforts de conception de l’organisation.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
#2 – Incidents par période
Les équipes produit sont responsables de la livraison de produits utilisables à leurs clients et les incidents, lorsqu’ils se produisent, nuisent à la convivialité de vos produits. Les incidents font référence aux temps d’arrêt du produit, aux pannes du produit et aux défauts non détectés du produit, entre autres. Les leaders doivent encourager et soutenir l’équipe produit afin de réduire le nombre d’incidents rencontrés par les utilisateurs par période. Les entreprises doivent investir dans des capacités techniques qui permettent de capturer automatiquement ce type de problèmes à partir des relevés d’incidents et, en outre, de fournir aux utilisateurs un moyen de signaler ces problèmes.
Les entreprises gagnent beaucoup de bonne volonté de la part de leurs clients si ces problèmes peuvent être détectés et corrigés avant qu’ils ne soient visibles par les utilisateurs. Pour s’assurer qu’un produit conserve sa valeur pour ses utilisateurs, le nombre d’incidents par période doit avoir tendance à diminuer au fil du temps.
Voici quelques facteurs qui pourraient contribuer à réduire le nombre d’incidents par période :
Capturez la dette technique en tant qu’éléments de premier ordre de l’arriéré de produit.
Augmentez les tests automatisés autour des fonctionnalités sujettes aux incidents.
Obtenez l’engagement de l’équipe produit à réduire la dette technique sur une période donnée.
Améliorez les capacités d’analyse des logs des utilisateurs pour repérer les problèmes potentiels.
La construction d’un produit est coûteuse et jusqu’à ce qu’un produit soit mis à la disposition de ses utilisateurs, le budget dépensé jusque-là pourrait être assimilé à un « stock d’invendus » comme dans le cas d’une entreprise traditionnelle.
Le délai d’exécution est le temps écoulé entre l’idée et le produit fonctionnel entre les mains du client.
Souvent, l’équipe produit trouve qu’il est plus facile de mesurer le temps de cycle, c’est-à-dire le temps écoulé entre le moment où une tâche est en cours et le produit entre les mains du client. Le temps de cycle peut être mesuré à la place du délai d’exécution, mais en fin de compte, l’équipe produit doit améliorer son système de management du backlog (l’arriéré de produit) pour calculer le délai d’exécution.
Il convient de souligner que l’effort visant à augmenter la fréquence de livraison devrait réduire le délai d’exécution. Cependant, la mesure et la visualisation du délai d’exécution apportent une valeur ajoutée à part entière.
Les facteurs qui améliorent les délais sont les suivants :
Réduire et, éventuellement, éliminer les temps d’attente dans le système.
Dans notre travail avec les clients, nous avons observé que les leaders n’accordent pas suffisamment d’attention à une mesure très importante : Le niveau de satisfaction des personnes qui font réellement le travail. Il semble que les leaders supposent au fil du temps que les employés qui ne montrent pas de signes visibles d’insatisfaction doivent certainement être heureux et notre travail a montré que ce n’est certainement pas le cas
Les employés qui ne sont pas satisfaits au travail et ont des niveaux de moral en baisse ne sont pas en mesure de fournir des produits de valeur que les utilisateurs adorent. Lors d’un récent engagement de transformation de l’organisation où nous avons remarqué que le moral des employés était en baisse, les leaders avaient demandé à l’équipe d’augmenter la fréquence des livraisons et de réduire le temps de cycle, mais les équipes ne pouvaient pas améliorer ces mesures sans l’adhésion des leaders à la prise de certaines décisions qui impliquaient d’investir dans l’automatisation et de restructurer les équipes. Les leaders ont également supposé qu’il était facile pour les équipes de s’améliorer. La seule façon d’obtenir l’engagement des leaders a été de mener une enquête sur la satisfaction des employés, qui a donné des résultats négatifs.
Nous avons pu cocréer un certain nombre d’initiatives avec les équipes produit, notamment :
Des méthodes de travail qui ont donné de l’autonomie et du sens aux équipes.
Le leader s’est engagé à financer des changements d’infrastructure afin de réduire la durée des cycles et d’augmenter la fréquence des livraisons.
Les employés engagés et heureux sont plus susceptibles d’accepter le changement, d’apporter des idées innovantes et de collaborer efficacement, alimentant ainsi l’agilité et le succès de votre organisation.
#5 – Satisfaction du client
Il faut beaucoup de travail pour créer des produits qui apportent continuellement de la valeur à leurs utilisateurs et les organisations capables de créer des produits de valeur peuvent s’attendre à ce que la satisfaction des clients s’améliore au fil du temps.
Les 4 indicateurs : Fréquence de livraison, Incidents par période, Délai d’exécution et Satisfaction des employés, contribuent tous à améliorer la satisfaction client.
Il existe un certain nombre de techniques qui ont été utilisées pour mesurer la satisfaction des clients, notamment le Net Promoter Score (NPS)et le taux d’attrition des clients.
L’équipe produit peut également envisager le déploiement de données de télémétrie qui fournissent des informations sur les comportements des utilisateurs au sein du produit.
Les mesures de satisfaction client fournissent des informations précieuses sur la façon dont le produit répond aux attentes des clients et va même plus loin. En écoutant activement vos clients et en adaptant vos produits, services et expériences en conséquence, votre équipe produit favorise la fidélité, établit des relations durables et garde une longueur d’avance sur un marché concurrentiel.
Sam Adesoga
Sam Adesoga
Coach Agile Principal et Formateur Principal at Valuehut, un cabinet de conseil en coaching et formation agile, qui aide les organisations à explorer les méthodes de travail agiles. Sam a beaucoup d’expérience dans le soutien aux dirigeants et à leurs équipes en matière d’agilité d’entreprise avec un objectif ambitieux :Aider les organisations à développer un état d’esprit agile nécessaire pour continuer à garder une longueur d’avance sur la concurrence et les marchés.
partagez ce billet avec vos amis, collègues et relations professionnelles
Connaissez-vous la loi de Little en management de projets Agile et en Management de Portefeuille de projets ?
La loi de Little porte le nom de son inventeur, John Little, qui a établi la théorie des files d’attente dans les années 1950s.
Au départ, la loi avait pour objectif de fournir une formule très simple pour juger de l’efficacité d’un système de gestion de file d’attente.
En 1961, Little a énoncé son théorème :
Le nombre de clients dans une file d’attente est égal au taux d’arrivée moyen des clients multiplié par le temps nécessaire pour les traiter.
Puis, cette loi fut souvent utilisée dans les approches Lean pour réduire les délais. Elle permet de calculer le temps moyen passé dans un système de production entre le début et la fin d’une tâche. L’objectif est bien sûr d’augmenter la capacité de production.
De nos jours, la loi de Little est utilisée dans les approches Agile, en particulier avec Kanban, car elle établit un lien très clair entre le WIP (Work In Progress – Travail en cours), le Lead Time LT (temps moyen pour exécuter une tâche) et le Taux de production T (le débit).
Cette formule est souvent exprimée ainsi :
WIP = T x LT
ou encore
LT = WIP / T
Toute augmentation des travaux en cours WIP augmente automatiquement les délais.
Dans les faits, certaines entreprises ont tendance à faire l’inverse. Elles augmentent les travaux en cours dans l’espoir d’augmenter la production et il en résulte souvent un total désastre en ce qui concerne le respect des délais.
De même, si une entreprise a du mal à exécuter tous les projets en cours, en lancer de nouveau a peu sinon aucune chance d’améliorer la situation. Or, c’est encore trop souvent ce qui se produit.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
La loi de Little dans le cadre du management de projet
Nous pouvons utiliser cette loi pour mieux comprendre pourquoi nous avons de meilleures chances de les mener à bien en manageant plus efficacement les projets en cours plutôt qu’en lançant d’autres projets.
Lancer trop de projets engorge les processus, surcharge les horaires de travail des développeurs et allonge considérablement le temps de réalisation.
Prenez un exemple :
Si, à ressources constantes, vous lancez en parallèle 3 projets d’une durée moyenne de 1 an, il vous faudra 3 ans pour compléter chacun d’entre eux.
Alors que si vous lancez les projets 1 par 1, vous aurez le premier au bout d’une année, le second au bout de 2 et le troisième de 3.
Avec l’approche « séquentielle », vous pouvez donc commencer à récolter les bénéfices de votre premier projet 2 ans plus tôt qu’avec le lancement de tous les projets en parallèle et les avantages du second une année plus tôt.
Ces bénéfices peuvent être ce qui fera ou défera le succès de votre organisation tant vos capacités d’auto-financement sont de plus en plus importantes.
Bien sûr, tout n’est pas si linéaire…
En fait, si le premier projet est délivré après 12 mois, il vous faudra supporter sa mise en production, corriger les erreurs, écouter les retours des utilisateurs, effectuer quelques ajustements impératifs…
Même avec un plan de mise en production accompagné de ressources additionnelles dédiées au support en sus des développeurs, il y aura probablement des impacts non négligeables sur leur charge de travail.
Donc, en réalité, je ne pense pas que vous terminerez systématiquement le second projet 24 mois après la date de début. Et je suis quasiment certain que le troisième projet ne sera pas fini dans la période cible de 3 ans.
Mais, en revanche, il est certain que vous obtiendrez des bénéfices des projets numéros 1 et 2 beaucoup plus tôt que si vous lancez les 3 en parallèle.
Prenez aussi en compte les dégradations de performance dues au multi-tâches permanent.
Il est clair que plus vos employés ont de projets sur lesquels ils travaillent en parallèle, plus les délais d’exécution de chacun de ces projets seront longs.
Le temps de passage d’un projet à l’autre en cours de journée ou de semaine, leswitching time, est à ajouter à vos délais. En effet, cela consomme du temps que de poser votre crayon sur un sujet, vous remettre dans le contexte de votre autre tâche ou projet, puis être à nouveau pleinement productif sur celui-ci. C’est l’une des raisons pour lesquelles le multi-tâches est fortement déconseillé en approche Agile où toute l’équipe doit travailler ensemble.
En limitant le nombre de projets en cours, les ressources nécessaires sont disponibles et davantage focalisées. Le résultat est un achèvement du projet bien plus tôt.
Et pour le management de Portefeuille de Projets (PPM) ?
La loi de Little est un excellent principe à suivre dans le management des portefeuilles de projets (PPM) car elle vous permet de conserver une vue d’ensemble tout en optimisant la mise en œuvre opérationnelle.
Il vous reste cependant (encore et toujours) à bien travailler les business cases pour être certains de choisir le bon ordre de séquencement des projets !
Plus spécifiquement sur les projets Agiles
Que l’approche de développement soit Agile ou prédictive, il est critique dans chaque projet sélectionné de bien travailler sur la liste des fonctionnalités souhaitées et les prioriser en fonction des bénéfices attendus de chacune d’entre elles.
C’est en Agile en grande partie la responsabilité du Product Owner.
Et c’est, selon moi, aussi là qu’un intérêt majeur des approches Agiles va se matérialiser : Savoir quand s’arrêter !
En effet, en plus de livrer au plus tôt les fonctionnalités les plus critiques, en approche Agile vous pouvez et devez décider quand dire stop.
En arrêtant votre projet dès que les bénéfices additionnels ne justifient plus de mobiliser les ressources allouées, vous allez les libérer pour le projet suivant qui apportera davantage de bénéfices à l’entreprise.
Il y a là bien sûr un fort risque de ne jamais terminer un projet à 100% par rapport à son business case originel. Mais ceci est-il réellement un problème ?
J’ai vu dans tous les projets que j’ai suivi des fonctionnalités très prometteuses sur le papier n’être que faiblement voire jamais utilisées alors qu’elles nous avaient coûté un bras. C’était rarement dû à une pauvre qualité du livrable. Il s’agissait plutôt de besoins qui avaient évolués pendant la durée de développement du projet, ou bien dus à des changements dans les processus ou les organisations qui étaient parfois encore plus « Agiles » que nos développeurs.
Quelle est votre expérience de cette Loi de Little ?
partagez ce billet avec vos amis, collègues et relations professionnelles
Les projets CRM sont complexes et nécessitent un Product Owner dédié et compétent pour assurer leur succès. Un Product Owner est chargé de combler le fossé entre les besoins de l’entreprise et les équipes de développement, tout en optimisant le système pour réussir.
Laissez-moi vous parler des avantages à avoir un Product Owner sur un projet CRM.
Comprendre les besoins et les exigences de l’entreprise
Le Product Owner travaille en étroite collaboration avec les utilisateurs et les parties prenantes pour comprendre leurs besoins et leurs exigences. En cartographiant les processus métier et les parcours des utilisateurs, le Product Owner comprend mieux comment le CRM peut être adapté pour répondre aux besoins spécifiques de l’entreprise. Cela permet de s’assurer que le système est conçu et construit de manière à s’aligner sur les processus métier et les besoins des utilisateurs, tout en offrant une réelle valeur ajoutée.
Guider le processus de développement
Une fois les processus métier définis, le product owner collabore avec l’équipe de développement pour concevoir et mettre en œuvre la solution CRM. Cela implique de définir les histoires et les exigences des utilisateurs, de hiérarchiser les fonctionnalités en fonction de la valeur business et de travailler en étroite collaboration avec l’équipe de développement pour s’assurer que le système est conçu et construit d’une manière qui s’aligne sur les processus métier et les besoins des utilisateurs. Tout au long du processus de développement, le Product Owner fournit des conseils et des commentaires pour s’assurer que le système répond aux exigences qui ont été définies avec les utilisateurs et les parties prenantes.
Trouver l’équilibre entre les besoins de l’entreprise et la convivialité
Trouver le bon équilibre entre les besoins des uns et des autres.
L’un des rôles les plus importants du Product Owner est d’équilibrer les besoins de l’entreprise avec les besoins des utilisateurs. Bien que le Product Owner soit chargé de s’assurer que le système répond aux besoins de l’entreprise et apporte une réelle valeur ajoutée, il donne également la priorité à la facilité d’utilisation pour s’assurer que le système est intuitif et facile à utiliser pour les utilisateurs.
Cet équilibre entre les besoins de l’entreprise et la facilité d’utilisation peut parfois être un défi.
Par exemple, une entreprise peut exiger que certaines données soient saisies dans un certain format à des fins de reporting, tandis que les utilisateurs peuvent trouver ce format fastidieux et long à utiliser. Le product owner doit travailler à la fois avec l’entreprise et les utilisateurs pour trouver une solution qui réponde aux besoins de chacun. Il peut s’agir de trouver un compromis satisfaisant pour les deux parties, ou de trouver une solution de contournement qui répond aux exigences de l’entreprise tout en facilitant la saisie des données par les utilisateurs.
Communiquer avec les parties prenantes
En plus de travailler avec l’équipe de développement, le Product Owner communique régulièrement avec les parties prenantes de l’entreprise. Il s’agit notamment de fournir des mises à jour sur l’état d’avancement du projet, de solliciter des commentaires sur les conceptions et les fonctionnalités, et de s’assurer que le système répond aux besoins de toutes les parties prenantes. Cela permet de s’assurer que toutes les personnes impliquées dans le projet sont tenues au courant et ont leur mot à dire dans le processus de développement.
Assurer le succès du lancement et de l’adoption
Enfin, le Product Owner est responsable de s’assurer que le CRM est lancé et adopté avec succès par l’entreprise. Il s’agit de contribuer à des activités de formation et de soutien aux utilisateurs afin de s’assurer qu’ils sont à l’aise avec le nouveau système et qu’ils sont en mesure de tirer pleinement parti de ses capacités. En optimisant le système pour qu’il réussisse et en comblant le fossé entre les besoins de l’entreprise et le développement, le propriétaire du produit peut assurer le succès du projet CRM.
En conclusion, avoir un Product Owner sur un projet CRM offre de nombreux avantages.
Le Product Owner apporte la plus grande valeur possible, aussi rapidement que possible.
Un Product Owner s’assure que le système répond aux besoins de l’entreprise et apporte une réelle valeur, fournit des conseils et des commentaires tout au long du processus de développement, équilibre les besoins de l’entreprise avec les besoins des utilisateurs, communique régulièrement avec les parties prenantes et veille à ce que le système soit lancé et adopté avec succès par l’entreprise.
Si vous vous lancez dans un projet CRM, il est essentiel d’investir dans un Product Owner solide et expérimenté pour en assurer le succès.
Mohamed Michael Kazak
Mohamed Michael Kazak
Mohamed Michael Kazak dispose de plus d’une décennie d’expérience à travers diverses industries et plusieurs pays, avec un riche parcours en transformation technologique, gestion de projet, et excellence commerciale. Actuellement, Mohamed Michael occupe le poste de Salesforce Service Product Owner chez Imerys SA, où il dirige les initiatives liées à la digitalisation des activités Service Client Salesforce. Il a lancé plusieurs produits Service Cloud réussis qui ont nettement amélioré l’efficacité du service client et la satisfaction client. Ayant travaillé pour des organisations telles qu’EY et Deloitte, il a géré des équipes diverses et dirigé des projets de transformation avec un focus sur la création de valeur et la satisfaction des besoins des utilisateurs. En tant qu’Administrateur Certifié Salesforce, Mohamed Michael apporte une compréhension approfondie de la manière dont la technologie apporte des résultats commerciaux optimaux.
« Merci pour votre commentaire Serge Amon. Vous soulignez un défi crucial dans la gestion Agile des projets CRM : L’engagement profond et la disponibilité des équipes métier, souvent compliqués par un manque d’acculturation au mode projet Agile. »
Permettez-moi de partager avec vous le processus que je suis pour comprendre les besoins des entreprises et explorons les différents outils et techniques que j’utilise pour y parvenir.
N’oubliez pas qu’il s’agit surtout d’art dans un cadre de travail défini.
Interrogez les principales parties prenantes
La première étape pour comprendre les besoins et les exigences de l’entreprise consiste à interroger les principales parties prenantes. Il peut s’agir de chefs de service, d’utilisateurs finaux et de cadres exécutifs.
L’objectif de ces entretiens est de comprendre les processus métier, les flux de travail et les points faibles que votre projet Agile va résoudre.
Le Product Owner doit préparer une liste de questions à l’avance pour guider la discussion et s’assurer que tous les sujets pertinents sont couverts.
Faites vos devoirs
À la suite des entretiens avec les parties prenantes, une chasse aux informations supplémentaires commence. L’une des tâches clés du Product Owner est de bien connaître la situation actuelle et d’identifier les domaines à améliorer ou à optimiser.
Voici quelques-uns des éléments que le Product Owner examinera :
Cartes ou diagrammes des processus métier actuels
Manuels ou guides d’utilisation existants
Résultats de précédents sondages (ou lancement d’un nouveau)
Commentaires des utilisateurs ou tickets de demandes d’assistance
Données historiques ou rapports sur l’utilisation du système actuel et performances des processus
En examinant ces documents et ces données, et en recueillant les informations des parties prenantes, le Product Owner peut mieux comprendre l’état actuel des processus métier et identifier les domaines à améliorer ou à optimiser. Cela permettra au Product Owner de travailler plus efficacement dans la phase d’atelier et plus tard avec l’équipe de développement pour concevoir et mettre en œuvre de manière Agile des solutions qui répondent aux besoins spécifiques de l’entreprise.
Animez des ateliers
Une fois que les principales parties prenantes ont été interrogées et que le Product Owner s’est formé, il ou elle peut animer des ateliers pour approfondir les exigences. Les ateliers peuvent être utilisés pour identifier les lacunes dans les processus métier actuels, hiérarchiser les caractéristiques et les fonctionnalités nécessaires, et définir les histoires utilisateurs.
Voici quelques-unes des meilleures pratiques pour assurer le succès des ateliers :
Préparez-vous et soyez ouverts d’esprit,
Posez des questions ouvertes,
Les ateliers ne doivent pas durer plus de 1h30,
Permettez aux participants de discuter des désaccords, mais rappelez-leur aussi ce qu’ils ont en commun.
Voici une liste d’ateliers qui peuvent être réalisés avec une proposition d’ordre du jour. Veuillez noter que ces séances peuvent être ajustées en fonction des besoins et des objectifs spécifiques du projet, et que l’ordre du jour peut être affiné en fonction des retours des principaux intervenants.
Atelier 1 : Introduction et examen des processus métiers et business
L’objectif de cet atelier est de cartographier les processus métier et les flux de travail de l’organisation, et d’identifier les opportunités d’automatisation et d’optimisation à l’aide de votre nouvelle solution. Cela permettra de s’assurer que le nouveau système est adapté aux besoins spécifiques de l’organisation et qu’il apporte une réelle valeur ajoutée. Bien que le Product Owner ait recueilli pas mal d’informations à partir d’entretiens et de données existantes, la réalité est souvent différente de ce qui est sur papier.
Accueil et présentations (10 min)
But et objectifs de l’atelier (10 min)
Revue des processus métiers actuels (30 min)
Identification des principaux défis et points faibles de l’entreprise (20 min)
Discussion sur les améliorations potentielles des processus existants (20 min)
Atelier 2 : Cartographie du parcours utilisateur
L’objectif de cet atelier est de comprendre les besoins et les difficultés des utilisateurs, et de cartographier leur parcours tout au long des processus de l’organisation. Cela permettra de s’assurer que le nouveau système est conçu de manière intuitive et conviviale, améliorant ainsi l’adoption et l’efficacité par les utilisateurs.
Accueil et présentations (10 min)
Rappel des principaux points à retenir de l’atelier précédent (10 min)
Identification des personas d’utilisateurs clés (20 min)
Cartographie des parcours utilisateurs pour chaque persona (40 min)
Discussion sur les points faibles et les possibilités d’amélioration dans chaque parcours (20 min)
Atelier 3 : Hiérarchisation et définition des fonctionnalités
Cet atelier consiste à définir et à hiérarchiser les fonctionnalités et les exigences nécessaires à la nouvelle solution, en fonction de l’évaluation de l’état actuel, de la cartographie des processus métier et des exercices de cartographie du parcours utilisateur. L’objectif est de définir le Produit Minimum Viable (MVP) qui peut être livré aux utilisateurs le plus rapidement possible tout en répondant à leurs besoins. Cela permettra de s’assurer que le système est conçu et construit de manière à s’aligner sur les besoins de l’organisation et à apporter une réelle valeur ajoutée.
Accueil et présentations (10 min)
Rappel des principaux points à retenir de l’atelier précédent (10 min)
Hiérarchisation des fonctionnalités en fonction de la valeur business et des besoins des utilisateurs (20 min)
Définition des fonctionnalités clés et des exigences pour chaque fonctionnalité prioritaire (40 min)
Discussion sur les concessions et compromis potentiels (20 min)
Atelier 4 : Exigences techniques et récapitulatif
Les problèmes complexes ont souvent de multiples solutions et chemins pour les atteindre.
Cet atelier se concentre sur la définition des exigences techniques du produit en fonction des fonctionnalités prioritaires et des contraintes identifiées. L’objectif est d’identifier les défis techniques potentiels et les solutions qui doivent être prises en compte au cours du processus de développement. Les contraintes, telles que le budget, l’échéancier et la disponibilité des ressources, doivent être discutées, ainsi que les solutions potentielles pour y remédier. L’atelier se termine par un résumé du processus de collecte des exigences et un plan pour aller de l’avant avec le développement.
Accueil et présentations (10 min)
Rappel des principaux points à retenir de l’atelier précédent (10 min)
Identification des exigences ou contraintes techniques (30 min)
Discussion sur les solutions potentielles pour répondre aux contraintes techniques (30 min)
Récapitulatif des principaux points à retenir de la série d’ateliers (10 min)
Mesures à prendre et prochaines étapes (20 min)
Documentez les exigences
Comment décomposer les niveaux d’exigence Agile (précédent billet à relire)
Une fois les ateliers terminés, le Product Owner doit documenter les exigences. Cela inclut la création d’histoires utilisateur, la définition de critères d’acceptation et la création d’un arriéré de produit (product backlog). Le Product Owner doit travailler avec les parties prenantes pour s’assurer que les exigences sont exactes, complètes et alignées sur les besoins de l’entreprise.
Hiérarchisez les exigences
Une fois les exigences documentées, le Product Owner doit les hiérarchiser en fonction de la valeur business. Cela implique de travailler avec les parties prenantes pour comprendre le niveau d’effort requis pour chaque exigence et l’impact qu’elle aura sur l’entreprise. L’objectif est de s’assurer que les exigences les plus critiques sont traitées en premier et que le système apporte une réelle valeur ajoutée.
Affinez les exigences (Précisez les besoins)
Le Product Owner doit travailler en étroite collaboration avec l’équipe de développement pour s’assurer que les exigences sont correctement comprises. Le travail avec l’équipe de développement doit être anticipé le plus tôt possible. Tout changement ou mise à jour des exigences doit être communiqué aux intervenants afin de s’assurer que tout le monde est sur la même longueur d’onde.
Anticipez les difficultés auxquelles le product owner sera confronté
Imaginez une entreprise avec plusieurs divisions, chacune avec son propre processus de vente unique. L’équipe de vente de la division A a besoin d’un ensemble d’informations différent de celui de l’équipe de vente de la division B pour collecter un ensemble d’informations différent de celui de l’équipe de vente de la division B. Cependant, l’entreprise souhaite maintenir une instance de votre solution unifiée à des fins de reporting et d’analyse.
Dans ce cas, le propriétaire du produit peut travailler avec l’équipe de développement pour créer des flux personnalisés ou des pages dynamiques qui capturent les exigences uniques en matière de données pour chaque division. Ces personnalisations peuvent être conçues de manière à maintenir la cohérence des données, ce qui permet d’obtenir des rapports et des analyses précis tout en répondant aux besoins spécifiques de chaque équipe commerciale.
En tirant parti de cette flexibilité, le Product Owner peut combler efficacement le fossé entre les différents processus métier de chaque division et s’assurer que la solution globale est optimisée pour la réussite dans l’ensemble de l’entreprise.
La compréhension des besoins et des exigences de l’entreprise est essentielle à la réussite de votre projet quel qu’il soit.
Le Product Owner doit interviewer les principales parties prenantes, organiser des ateliers, documenter les exigences, hiérarchiser celles-ci, et examiner et affiner les besoins tout au long du processus de développement.
En suivant ces étapes, le Product Owner peut s’assurer que le système répond aux besoins de l’entreprise et des utilisateurs finaux et qu’il apporte une réelle valeur ajoutée.
Mohamed Michael Kazak
Mohamed Michael Kazak
Mohamed Michael Kazak dispose de plus d’une décennie d’expérience à travers diverses industries et plusieurs pays, avec un riche parcours en transformation technologique, gestion de projet, et excellence commerciale. Actuellement, Mohamed Michael occupe le poste de Salesforce Service Product Owner chez Imerys SA, où il dirige les initiatives liées à la digitalisation des activités Service Client Salesforce. Il a lancé plusieurs produits Service Cloud réussis qui ont nettement amélioré l’efficacité du service client et la satisfaction client. Ayant travaillé pour des organisations telles qu’EY et Deloitte, il a géré des équipes diverses et dirigé des projets de transformation avec un focus sur la création de valeur et la satisfaction des besoins des utilisateurs. En tant qu’Administrateur Certifié Salesforce, Mohamed Michael apporte une compréhension approfondie de la manière dont la technologie apporte des résultats commerciaux optimaux.
CertYou est partenaire de DantotsuPM, allez voir les formations et certifications Agile dont celles de Product Owner
partagez ce billet avec vos amis, collègues et relations professionnelles
Grâce à des outils pratiques, des conseils d’experts et un apprentissage basé sur des scénarios fondés sur des défis du monde réel, découvrez comment les équipes de projet et de produit peuvent tirer le meilleur parti d’une approche synergique pour générer ensemble une plus grande valeur organisationnelle.
Une fois les exigences documentées, le Product Owner doit les hiérarchiser en fonction de la valeur business. Cela implique de travailler avec les parties prenantes pour comprendre le niveau d’effort requis pour chaque exigence et l’impact qu’elle aura sur l’entreprise. L’objectif est de s’assurer que les exigences les plus critiques sont traitées en premier et que le système apporte une réelle valeur ajoutée.
Le Product Owner doit travailler en étroite collaboration avec l’équipe de développement pour s’assurer que les exigences sont correctement comprises. Le travail avec l’équipe de développement doit être anticipé le plus tôt possible. Tout changement ou mise à jour des exigences doit être communiqué aux intervenants afin de s’assurer que tout le monde est sur la même longueur d’onde.
Dans ce cas, le propriétaire du produit peut travailler avec l’équipe de développement pour créer des flux personnalisés ou des pages dynamiques qui capturent les exigences uniques en matière de données pour chaque division. Ces personnalisations peuvent être conçues de manière à maintenir la cohérence des données, ce qui permet d’obtenir des rapports et des analyses précis tout en répondant aux besoins spécifiques de chaque équipe commerciale.
DantotsuPM.com 