La septième édition du Guide PMBOK® définit une structure de répartition du travail (WBS) comme une « décomposition hiérarchique de la portée totale du travail à effectuer par l’équipe projet pour atteindre les objectifs du projet et créer les livrables requis ».
Bien que cette définition permette de bien comprendre ce qu’est une WBS, elle ne fournit pas de conseils sur la façon d’organiser la structure d’une WBS. Ceci est utile car cela donne aux équipes la flexibilité nécessaire pour déterminer quel est le moyen le plus approprié de le faire dans le contexte de leur projet.
Bien qu’il existe une variété infinie de projets, j’ai trouvé 3 approches utilisées par la plupart des équipes qui développent des WBS.
Axée sur les livrables – Chacun des composants de niveau supérieur de la WBS représente un livrable clé, et les niveaux suivants se concentrent sur la décomposition de ces livrables à un niveau de détail approprié.
Axée sur les phases – Chacune des composantes de niveau supérieur de la WBS représente une phase ou une étape du cycle de vie du projet, et les niveaux suivants se concentrent sur la décomposition des extrants de chacune de ces phases ou étapes.
Axée sur la responsabilité – Chacune des composantes de haut niveau de la WBS représente une partie prenante contribuant à l’exécution du projet, et les niveaux suivants se concentrent sur la décomposition des extrants produits par chacune de ces parties prenantes.
Une approche axée sur les livrables
Aide à concentrer l’équipe sur tout ce qui est nécessaire pour réaliser chaque livrable sans se soucier à ce stade de qui le fait ou quand cela serait fait. Cela peut bien fonctionner pour les projets où toute la portée d’un projet peut être décomposée dès le début, mais peut être difficile lorsqu’une approche par vagues (rolling waves) est adoptée, à moins qu’il n’y ait une identification claire des parties de planification qui doivent être élaborées à une date ultérieure.
Une approche axée sur les phases
Livre sur Amazon
Fonctionne bien avec une approche par vagues, car l’équipe n’a qu’à se concentrer sur ce qui sera achevé dans la phase à venir.
Cependant, il existe un risque que l’équipe manque des éléments clés de la portée pour des livrables spécifiques, car elle ne se concentrera pas sur la décomposition d’un seul livrable à la fois.
Une approche axée sur la responsabilité
Fonctionne bien lorsqu’il y a plusieurs parties prenantes et qu’il est nécessaire d’avoir une séparation claire des responsabilités en matière de planification et d’exécution. Elle présente le même risque que l’approche axée sur les phases, mais en plus grave, car il est possible que des livrables sous-composants soient assumés par chaque partie prenante comme étant la responsabilité d’une autre partie prenante.
Sondage auprès des professionnelles et professionnels du management de projet
57 % utilisaient une ventilation axée sur les livrables
28 % une approche axée sur les phases
9 % une approche axée sur la responsabilité
Les 6 % restants ont indiqué qu’ils utilisaient une autre approche, mais lorsque j’ai examiné les commentaires que ces participants avaient soumis, il semble qu’ils utilisent simplement une combinaison de ces méthodes plutôt que quelque chose d’entièrement nouveau.
Bien que le WBS soit un outil couramment utilisé avec des projets suivant un cycle de vie prédictif, cela ne signifie pas que ceux qui suivent un cycle adaptatif ne peuvent pas en bénéficier. Si nous considérons une user story map*, il s’agit simplement d’une WBS limitée entre deux et quatre niveaux et élaborée de manière progressive. Avec une Story Map, la structure peut être orientée persona (rôle des utilisateurs) ou thème/capacité.
Quelle que soit la façon dont votre équipe choisit de décomposer la portée du travail sur ses projets, une WBS ou une variante de celle-ci doit être considérée comme un instrument précieux dans sa boîte à outils.
Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes
* Une user story map est un outil puissant qui permet à une équipe agile de préparer son backlog de produit et de planifier plus efficacement les versions de produits. Une user story map capture le parcours d’un client avec le produit, y compris les activités et les tâches qu’il effectue avec le système.
partagez ce billet avec vos amis, collègues et relations professionnelles
En 2003, Barry Boehm et Richard Turner ont inventé l’acronyme C.R.A.C.K. pour nous rappeler les caractéristiques clés d’un Product Owner efficace !
Collaboratif – Est-il capable et disposé à négocier avec les parties prenantes sur les besoins, les souhaits et les priorités afin de définir un contenu de produit optimal ?
Livre référence sur Amazon
Représentatif – Est-il capable de « se mettre dans les chaussures » d’une partie prenante donnée pour aider les membres de l’équipe et d’autres personnes à comprendre le contexte derrière un besoin particulier ?
Autorisé – Est-il habilité à prendre la majorité des décisions de priorisation sur le produit sans avoir besoin de demander l’approbation de ses supérieurs ?
Comitted (engagé) – A-t-il pleinement adhéré à la vision du produit et a-t-il une capacité suffisante pour s’acquitter de ses responsabilités en tant que Product Owner ?
Knowledgeable (Connaissance) – Possède-t-il une connaissance suffisante du domaine du produit, mais aussi a-t-il le savoir-faire organisationnel pour savoir qui engager, influencer ou persuader ?
Cet acronyme me semble s’appliquer également fort bien aux responsables de Project Management Office (PMO), les bureaux de projets, ainsi qu’aux portefeuilles de projets (PPM) !
Visitez le site de notre partenaire Virage Group
partagez ce billet avec vos amis, collègues et relations professionnelles
Voici un billet que j’ai trouvé très intéressant sur la réelle valeur des story points et les raisons pour lesquelles ils créent des conflits dans vos projets Agiles.
L’estimation du travail agile fait l’objet de débats dans les organisations depuis des années. Il existe plusieurs techniques d’estimation, mais les story points, en particulier, peuvent être un mystère pour beaucoup. Bien qu’il s’agisse d’une méthode couramment utilisée, certains peuvent questionner son efficacité. Cet article décrit le but des story points et pourquoi ils peuvent être sujets à controverse.
Qu’est-ce qu’un Story Point ?
Un story point est une unité de mesure d’une user story basée sur des facteurs tels que la complexité, l’effort, l’incertitude et le risque. Les story points peuvent être utilisés dans des approches agiles comme Scrum lors de la planification du sprint en attribuant une valeur en points à une user story.
Le story-pointing est un moyen rapide d’estimer le travail à l’aide d’outils tels que Planning Poker ou le modèle de Fibonacci. Par exemple, l’équipe peut attribuer un 1 ou un 2 à une histoire qu’elle considère comme nécessitant peu d’effort. L’objectif est d’aider les équipes Scrum à avoir un dialogue ouvert pour acquérir une compréhension commune du travail relatif à toutes les histoires utilisateurs dans l’arriéré de produit, le product backlog.
Relisez ce billet sur « pourquoi Fibonacci ? »
Toute l’équipe (ceux qui font le travail) discute des éléments et des composants impliqués dans le développement de l’histoire utilisateur et parvient à un consensus sur l’estimation en story points. Certaines équipes établissent une base de référence convenue pour l’histoire d’effort le plus faible avec le nombre de story points le plus bas. Si une user story a un nombre très élevé de points, l’équipe décompose l’histoire en histoires plus petites puis les estime.
Comment les story points sont-ils utilisés dans les sprints ?
Une fois que la planification du sprint est terminée et que l’équipe a décidé de ce à quoi elle peut s’engager dans le sprint, elle a alors son nombre total de points d’histoire, de story points, engagés. À la fin du sprint, l’équipe aura consommé tous les story points qui répondent à leur définition de terminé, done. Toutes les histoires qui ne sont pas complètes sont alors soit déplacées dans le backlog, peut-être affinées et ré-estimées, soit reportées au sprint suivant : c’est une décision d’équipe.
L’équipe répète ce processus pour chaque sprint. Au fil du temps, les membres développent leur vélocité, qui est une moyenne du nombre total de story points complétés à la fin de chaque sprint. Les story points terminés peuvent varier à chaque sprint en fonction de la capacité de l’équipe (temps disponible pour chaque sprint). Les facteurs qui pourraient avoir une incidence sur la capacité comprennent le nombre de membres de l’équipe travaillant dans le sprint en raison d’un congé personnel ou d’une maladie, d’une formation ou de conférences, d’événements imprévus, de distractions externes ou peut-être d’un sprint lourd en réunions (pensez aux réunions de département ou d’organisation).
Pourquoi les story points peuvent-ils être sujets à controverse ?
Étant donné que les story points sont une valeur nébuleuse et arbitraire, certaines organisations peuvent ne pas comprendre l’unité réelle de cette mesure des histoires utilisateur. Elles peuvent mal interpréter leur objectif, et il est difficile d’associer systématiquement les points d’histoire au délai de livraison. Prenons la vélocité, par exemple. Elle est considérée comme une mesure clé dans Agile, mais elle peut être utilisée à mauvais escient lors de la mesure de la productivité d’une équipe. Les dirigeants peuvent poser des questions sur la vélocité de l’équipe et vouloir savoir combien de points d’histoire ils achèvent à chaque sprint. Cet état d’esprit de la vélocité en tant que mesure de productivité utilisant des story points ne donne pas une bonne idée de la productivité ni du temps qu’il faudra à l’équipe pour livrer une fonctionnalité.
Disons que l’équipe prend en charge et complète 20 story points dans le sprint 1. Dans le sprint 2, ils prévoient 40 story points mais ne complètent que 30 story points. Dans le sprint 3, ils embarquent et complètent 30 points d’histoire. Cela ne signifie pas que l’équipe est plus ou moins productive de sprint en sprint. Cela fait partie du processus de planification de l’équipe pour déterminer ce qu’elle peut engager dans chaque sprint compte tenu de son expérience du dernier sprint. Étant donné que les user stories présentent différents degrés de complexité et d’incertitude, l’équipe a peut-être appris que ses estimations lors de la planification du sprint étaient trop élevées ou trop basses et s’ajuste en conséquence à chaque sprint.
La capacité de l’équipe est une autre raison pour laquelle les story points peuvent fluctuer. Peut-être qu’ils n’ont pas pu en terminer autant qu’ils l’avaient prévu en raison d’une personne malade dans l’équipe ou d’un autre événement inattendu.
Les story points sont également utilisés à mauvais escient comme métrique pour comparer une équipe à une autre. L’équipe A peut avoir une moyenne de 40 story points tandis que l’équipe B peut avoir une moyenne de 80 story points. Le management peut mal interpréter cela comme signifiant que l’équipe A est deux fois plus productive que l’équipe B. Il n’y a pas deux équipes égales. Leurs membres peuvent avoir des compétences différentes, la taille des équipes peut être différente et les définitions d’un story point peuvent varier. La comparaison des équipes nuit à leur processus d’estimation, crée des estimations gonflées et démoralise l’équipe.
Trouvez un équilibre
Il est compréhensible que les organisations aient besoin de savoir à quel point les équipes sont productives et elles ont besoin de quelque chose de tangible pour mesurer leur performance. Cependant, il est erroné de supposer que les story points et la vélocité sont des mesures d’évaluation de la productivité. Les story points sont utilisés par l’équipe Scrum à des fins de planification et ne doivent pas être considérés comme une unité de productivité par la direction. La vélocité en tant que métrique doit être utilisée par l’équipe Scrum comme point de référence pour les aider dans leur prise de décision pour les engagements de sprint.
Les apprentissages continus et l’expérience de l’équipe donnent la possibilité à l’équipe Agile d’améliorer ses estimations au fil du temps.
Grâce à l’inspection et à l’adaptation, les membres de l’équipe deviennent plus prédictifs et capables de prévoir les délais pour les fonctionnalités. Ce qui compte dans l’agilité, c’est un dialogue ouvert et productif sur le travail, la progression vers l’objectif du produit et la création fréquente de valeur pour les clients.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
Nous savons que l’agilité n’est pas une méthodologie ni un ensemble de processus ou de techniques. L’agilité est le comportement et les attitudes qui permettent aux individus et aux organisations de se déplacer rapidement et facilement.
Au niveau individuel, cette capacité conduit à l’innovation, à la créativité, à l’adoption rapide de nouvelles méthodes de travail.
Au niveau organisationnel, ce comportement est démontré par des améliorations continues, la recherche de nouveaux apprentissages, la volonté d’adopter de nouvelles approches et, en fin de compte, une mise sur le marché de nouveaux produits et services aux clients plus rapide et plus créative.
Les comportements agiles sont soutenus par de nouvelles façons de planifier et de hiérarchiser le travail, mais ils ont besoin d’un environnement qui encourage et récompense leur utilisation.
Les leaders sont les principaux acteurs dans la création de cet environnement.
Les leaders ne sont pas limités à ceux qui ont un pouvoir hiérarchique au sein de leurs organisations.
Un leader est quelqu’un que les autres suivent volontiers.
Je travaille avec de nombreuses organisations à différentes étapes dans l’agilité, et j’ai observé un groupe central de comportements travaillant ensemble, qui permettent aux processus et techniques agiles de s’épanouir :
Imaginez l’état futur
Faites évoluer votre vision
Identifiez les petites étapes
Vivez dans l’incertitude
Prenez des décisions
Sollicitez l’avis des autres
Abandonnez le contrôle
Si vous occupez un poste de leadership, j’ai écrit un document qui vous donnera l’occasion de comparer votre propre comportement à l’excellence agile et d’identifier les domaines à améliorer.
Si vous êtes manager de projet/programme, PMO ou Product Owner, cela vous donnera beaucoup d’idées sur ce dont il faut discuter avec votre sponsor.
Le Sprint est l’un des concepts de base de Scrum. En fait, c’est l’un des cinq événements de Scrum (avec Daily Scrum, Sprint Planning, Sprint Review et Sprint Retrospective).
Beaucoup de gens bloquent sur essayer de comprendre quand un sprint est vraiment terminé. Pour le comprendre, vous devez comprendre le but d’un sprint et pourquoi il est timeboxé (réalisé sur une période de temps limitée).
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
Qu’est-ce qu’un sprint ?
Un sprint est l’unité de temps fondamentale dans Scrum. Il s’agit d’une timebox (une durée spécifique et forcée) pendant laquelle une équipe Scrum tente de créer un ou plusieurs incréments de produit. Tous les événements Scrum (Daily Scrum, Sprint Planning, Sprint Review et Sprint Retrospective) se déroulent au sein d’un sprint.
Il n’y a pas d’activité en dehors du sprint.
Une fois qu’un sprint se termine, le sprint suivant commence immédiatement et le cycle de sprint recommence. Il n’y a pas de sprints spéciaux comme « sprint zéro », ou « sprint de consolidation » ou « sprint de release ». A chaque sprint, l’équipe est destinée à déplacer certains éléments du backlog produit vers Done (Terminé) et à livrer un incrément de produit.
Et surtout, un sprint est strictement limité dans le temps, généralement deux semaines, bien qu’il puisse durer jusqu’à un mois.
Pourquoi est-il timeboxé ?
La limite de temps de sprint est très importante. Les équipes doivent accepter la timebox et la respecter, c’est-à-dire mettre fin au sprint et commencer un nouveau sprint une fois la timebox terminée.
Il est parfois tentant pour une équipe de laisser un sprint « traîner » un ou deux jours de plus, pour essayer de finaliser certains éléments, mais cela va à l’encontre de l’essentiel !
Si une équipe commence à faire cela, elle peut continuer à le faire, et le faire de plus en plus. Cela remonte à l’époque des méthodes prédictives dites en cascades, où les livraisons sont repoussées toujours plus tard car les équipes veulent mettre tout le contenu de leur périmètre fonctionnel dans une unique livraison ou release. Avant que vous ne vous en rendiez compte, vous pouvez revenir à une release tous les 6 mois !
La timebox stricte garantit qu’il existe un modèle régulier simple, une cadence, où une équipe s’arrête et inspecte son dernier livrable (dans la revue de sprint) et l’équipe elle-même (dans la rétrospective de sprint).
Quand un sprint est-il terminé ?
La réponse courte et simple est qu’un sprint est terminé lorsque la timebox de sprint se termine ! (Quelle que soit la cadence choisie par l’équipe pour les sprints, c’est-à-dire deux semaines, un mois, une semaine, etc.).
Une équipe peut choisir de changer la durée de ses sprints (c’est-à-dire que l’équipe peut choisir de passer de sprints de deux semaines à des sprints d’une semaine ou vice versa), mais ce n’est pas un changement ponctuel. Cette nouvelle timebox devient la timebox standard pour tous les sprints à partir de là (jusqu’à la prochaine fois que l’équipe voudra changer la timebox).
Un sprint n’est pas terminé lorsqu’un incrément de produit est créé ou livré. L’équipe continue simplement à travailler sur d’autres éléments de l’arriéré de produit ou product backlog. Elle peut même produire un autre incrément de produit dans ce sprinte (Il n’y a rien dans Scrum qui dit que vous ne puissiez livrer qu’un seul incrément de produit par sprint !).
Un sprint n’est pas non plus terminé lorsque l’objectif de sprint a été atteint. Dans la situation heureuse où il reste encore un peu de temps dans le sprint, l’équipe peut choisir d’effectuer le travail qu’elle veut dans le temps restant. Il peut s’agir de travailler sur d’autres éléments du product backlog, rembourser une dette technique, examiner certains éléments d’amélioration continue, etc.
L’important est que la timebox régulière soit respectée.
De quelles autres façons un sprint peut-il se terminer ?
Il n’y a que deux autres façons dont un sprint peut se terminer.
La première est si le Product Owner décide d’annuler le sprint en cours. C’est un cas extrême qui ne devrait arriver que très rarement. La seule raison donnée pour cela dans le Guide Scrum est que l’objectif de sprint est devenu obsolète. Cela peut se produire pour diverses raisons, mais elles ne devraient pas arriver souvent. Il est presque toujours plus bénéfique pour l’équipe de continuer et de terminer le travail qu’elle a prévu pour ce sprint.
Il n’y a pas d’autres moyens mentionnés dans le Guide Scrum. Le seul auquel je puisse penser est un exemple encore plus extrême et, espérons-le, rare. C’est si le produit ou l’équipe elle-même cesse d’exister. Si une équipe est au milieu d’un sprint et que, pour une raison quelconque, l’organisation décide d’arrêter tout travail sur le produit ou d’arrêter de financer l’équipe, alors évidemment ce sprint se termine.
L’organisation peut vouloir financer l’équipe pour le reste du sprint, mais si le produit lui-même est obsolète ou n’est plus financé, elle peut vouloir économiser de l’argent en ne terminant pas le travail en cours dans le sprint.
partagez ce billet avec vos amis, collègues et relations professionnelles
Les équipes Scrum se réunissent pour décider des éléments de travail de leur prochain sprint lors de la réunion de planification du sprint. Mais est-ce le début de la conversation pour le sprint à venir, ou y a-t-il des choses à faire avant ?
Priorisez le Product Backlog, l’arriéré de produit
La première et la plus importante considération est d’avoir un product backlog vivant qui est à jour et hiérarchisé pour suivre l’évolution des besoins de l’entreprise. Le propriétaire de produit doit avoir un œil constant sur l’ajout, la suppression, la modification et la mise à jour d’éléments dans le product backlog. Lorsque le temps vient de planifier le sprint suivant, le chef de produit doit apporter à la table une liste des éléments de valeurs les plus élevées que l’équipe puisse choisir.
Détaillez les fonctionnalités
Étant donné que la plupart des exigences agiles sont courtes, soit sous la forme d’histoires utilisateur (User Stories) ou simplement de phrases listant les fonctionnalités nécessaires, elles nécessitent d’être détaillées pour pouvoir être implémentées. Le propriétaire de produit doit passer du temps à rechercher chacune des fonctionnalités et à essayer de présenter en termes simples le besoin réel que chacune exprime. Utilisez des listes à puces ou des phrases simples, pour expliquer la fonctionnalité en détail. Nous voyons cela se produire principalement pendant ou après la réunion de planification du sprint, mais si des exigences sont connues avant la réunion, le propriétaire de produit peut avoir une longueur d’avance.
Décidez d’une définition de done
Au cours d’une réunion de planification de sprint, l’équipe choisit généralement ce qu’elle fera et livrera à la fin de cette itération de sprint. Il est impératif que les membres de l’équipe connaissent et conviennent d’une définition de done pour chaque histoire utilisateur ainsi que chaque tâche de chacune. Qu’il s’agisse d’une tâche de développement, d’une tâche de conception ou d’exécution de test ou d’une tâche de revue de livrable, tout le monde doit s’accorder sur une compréhension commune de ce que signifie « done » afin d’assurer une livraison fluide et aucun conflit à la fin du sprint.
Soignez les user stories
Chaque histoire utilisateur qui est mise en avant pour la planification du sprint doit être soignée, développée et détaillée avec les connaissances et les commentaires de l’équipe entière.
Lorsque les testeurs, les développeurs et le propriétaire de produit s’assoient ensemble et discutent d’une nouvelle fonctionnalité, de nombreuses nouvelles questions peuvent survenir de la part de l’équipe. Les questions portent souvent sur l’intégration avec les fonctionnalités existantes, le comportement de la fonctionnalité dans des cas spécifiques ou la manière dont le comportement doit être adapté pour différents types d’utilisateurs. Les cas spéciaux font également partie des critères d’acceptation définis dans l’histoire utilisateur pour la rendre complète.
Quelles que soient les questions, il est préférable de les poser au plus tôt et d’y répondre avant de choisir l’histoire utilisateur. Fondamentalement, cela signifie qu’une conversation doit avoir lieu pour chaque user story, afin que l’équipe puisse se comprendre et décider des critères d’acceptations définis et agréés par tous.
Ces sessions de « toilettage d’histoires » doivent avoir lieu avant la réunion de planification du sprint afin que pendant la planification, l’équipe sache exactement ce qui est requis de cette fonctionnalité et puisse donner de meilleures estimations et story points en fonction de sa complexité.
Commencez par le design
De nombreuses histoires utilisateur ont besoin de storyboards visuels ou de maquettes de l’interface utilisateur, et dans ces situations, les concepteurs d’expérience utilisateur ou UX designers peuvent avoir besoin d’être impliqués. Ces histoires doivent être sélectionnées un sprint à l’avance et allouées d’abord aux UX designers, afin qu’ils puissent construire les maquettes ou les images d’écran prêtes avant que la fonctionnalité ne soit sélectionnée pour le développement dans le sprint suivant. Cette approche facilite la communication et évite les retards pendant le développement.
De même, certaines histoires utilisateur peuvent nécessiter une recherche sur une nouvelle approche, une nouvelle technologie ou un nouvel outil avant de commencer, ou il peut être nécessaire de créer un design d’architecture complet pour une certaine partie avant de se lancer dans sa mise en œuvre. Dans de tels cas, la tâche de conception ou de R&D doit être créée et démarrée dans un sprint précédent, puis allouée au développeur ou à l’architecte principal au sein de l’équipe pour préparer les designs et résultats de recherche pertinents. Ils peuvent ensuite partager ces informations avec l’équipe afin que tout le monde soit prêt à commencer à travailler sur la mise en œuvre dans le sprint suivant.
Un propriétaire de produit doit être constamment à l’affût des histoires utilisateur qui peuvent nécessiter un travail de conception ou de recherche avant de les commencer, et avoir ces user stories distribuées aux personnes concernées avant le sprint pour s’assurer que la mise en œuvre sera fluide et que la livraison pourra avoir lieu à temps.
Nishi est une formatrice en entreprise, une passionnée agile et une testeuse dans l’âme ! Avec plus de 11 ans d’expérience dans l’industrie, elle travaille actuellement chez Sahi Pro en tant qu’évangéliste et responsable des formations. Elle est passionnée par la formation, l’organisation d’événements et de rencontres pour une communauté de test, et a été conférencière lors de nombreux événements et conférences de test.
Consultez son blog où elle écrit sur les derniers sujets dans les domaines Agile et Testing.
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Le terme MoSCoW est un acronyme tiré de la première lettre de chacune de 4 catégories de priorisation : Must have, Should have, Could have, et Won’t have.
Notre équipe se donne des objectifs trimestriels, que nous décomposons en exigences dans des sprints bimensuels. En tant que paradev (un paradev iest quiconque dans une équipe de développement ne fait pas que programmer) dans mon équipe, je travaille étroitement avec notre Product Owner pour écrire et déterminer la priorité de ces exigences.
Nous avons à l’origine commencé par utiliser la méthode de MoSCoW pour déterminer la priorité de nos exigences : Le terme MoSCoW est un acronyme tiré de la première lettre de chacune de 4 catégories de priorisation : Must have, Should have, Could have, et Won’t have.
Nous avons rapidement commencé à remarquer que la terminologie (Must have, Should have, Could have, et Won’t have) ne marchait pas idéalement dans notre contexte et nous pensions que cela causait beaucoup de frictions sur comment nous donnions la priorité et la communiquions à l’équipe. Il ne semblait pas naturel de classifier des choses comme, Must, Should, Could, Won’t car non corrélées à ce sur quoi nous devrions (Should) travailler.
En quelques sessions nous avons inventé nos propres groupements pour nos exigences en nous basant sur quand nous voudrions les voir dans notre produit : Maintenant, Ensuite, Plus tard, Jamais. Nous avons continué à utiliser ces quatre termes et nous avons constaté qu’ils ont été très bien adoptés par l’équipe car il est très naturel pour nous de penser avec ces groupements.
Le plus grand avantage à utiliser Maintenant, Ensuite, Plus tard, et Jamais, est qu’ils se transfèrent naturellement dans notre plan de produit et dans la planification de sprint.
J’ai fait quelques recherches en écrivant ce billet et j’ai trouvé Maintenant, Ensuite, Plus tard comme une approche de ThoughtWorks datant de 2012, mais je n’ai pas trouvé de lien qui contienne Jamais que nous avons trouvé très utile pour lister ce que nous reconnaissons que nous ne ferons pas.
Comment abordez-vous l’établissement de la priorité de vos exigences ?
La tendance à supposer avec confiance que les autres partagent notre mode de pensée, nos attitudes et nos croyances est connue sous le nom de biais de projection.
Un effet connexe que nous avons déjà abordé sur ce blog est le biais de faux consensus qui pousse cette tendance un peu plus loin en nous faisant croire que les autres « sont également d’accord » avec nos points de vue.
Ce biais nous laisse de plus penser que nos habitudes et préférences resteront les mêmes au fil du temps. Nous projetons nos préférences actuelles dans l’avenir comme si nos goûts futurs correspondraient à nos goûts actuels.
En quoi sommes-nous concernés dans nos projets ?
Il y a des moments dans nos projets où il devient important de décider pour l’avenir. Et nous ne prenons pas toujours la meilleure décision. Le biais de projection devient un problème lorsque nous laissons les décisions prises en fonction de nos ressentis et préférences actuels affecter nos objectifs à long terme.
Lorsque vos commanditaires définissent leurs exigences impératives au début du projet, ils doivent anticiper à quel point celles-ci auront probablement évolué d’ici la fin du projet dans 3, 6 ou 18 mois par exemple. Se sont-ils projetés dans le futur ? En sont-ils capables ?
Le biais de projection peut aussi amener ces personnes à demander plus de fonctionnalités et de changements qu’elles ne peuvent en absorber sur la période. Cela revient à commander leurs desserts (des fonctionnalités non impératives) en début de repas alors qu’elles n’auront plus faim bien avant la fin du plat de résistance (les fonctionnalités critiques).
Comment éviter le plus possible ce travers ?
La priorisation des besoins et exigences est critique, que ce soit en approche prédictive comme en approche Agile. Il s’agit de ne pas prévoir plus de travail que réellement nécessaire, de prioriser le livrable qui va vraiment apporter des bénéfices concretsrapidement sur d’autres plus annexes. Il reste vrai qu’avoir la vue à long terme des changements que va apporter le projet est absolument critique et va guider le séquencement des travaux et l’échelonnement des livrables.
Ce biais peut-il nous être utile ?
Votre expérience de manager de projet peut vous aider grandement à utiliser les faiblesses de ce biais pour faire réfléchir vos clients et futurs utilisateurs de vos livrables ou votre product owner. De simples questions de votre part peuvent les amener à reconsidérer leur priorisation et à réfléchir à leur future situation.
Par exemple :
J’entends bien que cette fonctionnalité dans le portail client est aujourd’hui impérative car c’est notre principal parcours pour les utilisateurs Business to Business (B2B). Mais ne pensez-vous pas que l’arrivée des Application Programmable Interfaces (APIs) et des interfaces vocales pourraient changer la donne d’ici 12 mois ? Quels en seraient les impacts sur le parcours du client B2B ?
Nos processus de vente sont aujourd’hui très centrés sur des rencontres en face à face entre nos prospects et clients et nos vendeurs. La priorisation du déploiement de couteuses tablettes à notre force de vente est donc aujourd’hui particulièrement attractive pour accroitre leur productivité. Si la pandémie devait durer plusieurs semestres ou années et que les rencontres en face à face soient de moins en moins fréquentes, investiriez-vous toujours autant sur ces technologies ?
FDF est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Si vous saviez qu’il existe une approche structurée pour essayer des améliorations possibles, obtenir des retours rapidement et le faire d’une façon qui vous permette d’apprendre dans un environnement contrôlé et de construire sur vos succès, vous seriez probablement intéressés, non ?
Et bien cette approche existe ! Et c’est quelque chose que vous pouvez facilement apprendre et enseigner à votre entourage.
J’ai souvent rencontré des équipes qui aiment les longues Histoires Utilisateur. Pourquoi dépenser du temps à rédiger, planifier et évaluer une pile de courtes histoires quand vous pouvez écrire, planifier et évaluer une unique une grande histoire ? Les histoires plus grosses signifient une meilleure efficacité, non ? Pas nécessairement.
la propriétaire de produit comprend le métier et les taches des utilisateurs du futur produit.
Quand on parle de direction du développement d’un produit et de garantir que vous construisez ce dont l’utilisateur a en réalité besoin, le propriétaire de produit est la personne la plus importante pour l’équipe. Trouver la bonne personne pour ce rôle est crucial au succès du produit.
Il y a juste un problème : un bon propriétaire de produit peut être vraiment difficile à trouver. Les caractéristiques qui font un bon propriétaire de produit sont insaisissables, mais voici cependant trois qualités auxquelles vous devriez donner la priorité dans votre recherche.
Hexagon est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Les caractéristiques qui font un propriétaire de produit de qualité sont difficiles à lister, mais voici trois compétences ou attitudes auxquelles donner la priorité dans votre recherche.
Quand il s’agit de diriger le développement d’un produit et de s’assurer de vous construisez ce dont l’utilisateur a réellement besoin, le/la propriétaire de produit est la personne la plus importante pour l’équipe. Il y a juste un problème : un bon product owner peut être vraiment difficile à trouver. Les caractéristiques qui font un bon propriétaire de produit sont insaisissables, mais voici trois qualités auxquelles vous devriez donner la priorité dans votre recherche.
Cela peut sembler excessivement simpliste, mais généralement les produits réussissent ou échouent en fonction de l’efficacité du propriétaire de produit dans l’équipe. Cela arrive principalement parce que nous sous-estimons l’importance (et la difficulté) des différents aspects du Product Ownership dans le processus de création de produit.
Le rôle d’un propriétaire de produit couvre tout le spectre, de la découverte à la livraison et plus et donc le choix de la bonne personne pour ce rôle est beaucoup plus important que le coach Agile ou autres membres d’équipe.
la propriétaire de produit comprend le métier et les taches des utilisateurs du futur produit.
Cependant, nous avons tendance à penser aux logiciels comme étant des objectifs principalement techniques. Notre focus est trop souvent placé sur la qualité et la capacité des ingénieurs, l’architecture et la conception et nous dépensons un temps disproportionné sur les processus, l’optimisation et l’efficacité. Nous avons tendance à oublier que l’échec le plus commun et le plus répété de tous les produits logiciels (peu importe leur qualité, optimisation et efficacité, ou combien les ingénieurs sont qui les ont construits sont doués) est que si vous construisez le mauvais article, ce sera un échec.
Un produit parfaitement conçu mais inutilisé n’est d’aucune valeur.
L’histoire est pleine de grands produits qui ont raté l’objectif. Combien d’applications avez-que vous téléchargées sur votre téléphone que vous avez arrêté d’utiliser après les trente premières secondes ? Sans mentionner les innombrables produits qui échouent à jamais d’atteindre les mains de clients et dont nous n’avons jamais entendu parler.
Les produits de l’informatique interne de l’entreprise sont souvent coupables d’une idée erronée: L’assomption semble être que comme les clients seront forcés d’utiliser le produit, nous ne devons pas vraiment leur demander ce qu’ils veulent ni comment ils l’utiliseront. Aussi, nous finissons souvent par construire de « bons » produits qui ne répondent pas au besoin réel de l’utilisateur.
CertYou est partenaire de DantotsuPM
Considérez cette citation de Peter Drucker : “Il n’y a sûrement rien d’aussi inutile que de faire avec une grande efficacité ce qui ne devrait pas être fait du tout.”
Quand on parle de direction du développement d’un produit et de garantir que vous construisez ce dont l’utilisateur a en réalité besoin, le propriétaire de produit est la personne la plus importante pour l’équipe. Trouver la bonne personne pour ce rôle est crucial au succès du produit.
Il y a juste un problème : un bon propriétaire de produit peut être vraiment difficile à trouver. Les caractéristiques qui font un bon propriétaire de produit sont insaisissables, mais voici cependant trois qualités auxquelles vous devriez donner la priorité dans votre recherche.
1. La capacité à différencier ce qui est nécessaire de ce qui est voulu
Une partie significative du rôle de propriétaire de produit est d’identifier ce qui est nécessaire pour résoudre les problèmes des utilisateurs, répondre à leurs besoins, leur permettre d’être meilleurs dans leur travail, ou maximiser leur amusement ou relaxation. Le rôle consiste avant tout en la compréhension du problème et la création d’une vision de comment ce problème pourrait être résolu. Pas la solution technique, mais le vrai besoin.
La raison pour laquelle cette compétence est si complexe est que les utilisateurs savent rarement de quoi ils ont besoin. Typiquement la vision d’un utilisateur est contrainte par ce qu’il fait actuellement. En conséquence, beaucoup de produits reviennent à retravailler un système papier existant ou une vieille approche.
Un faible propriétaire de produit donne aux clients ce qu’ils veulent ou ce qu’ils ont demandé mais un bon propriétaire de produit écoute et observe et peut mélanger veut et doit pour résoudre le problème du client et lui donner ce dont il a vraiment besoin.
Ce point nous mène à une citation intéressante par Henry Ford : “si j’avais demandé aux gens ce qu’ils voulaient, ils auraient répondu des chevaux plus rapides.”
Nous voyons souvent des arriérés de produits pleins d’histoires utilisateur qui sont vraiment juste des demandes client non filtrées. Il est plus facile de faire ce que le client demande que de trouver ce qui est en réalité nécessaire. Car cela exige typiquement de l’expérimentation, des retours utilisateurs, des conversations et de l’observation.
Cela peut aussi se produire quand les managers de département décident ce dont leur équipe a besoin ou veut sans impliquer les membres dans la discussion. Mais un bon propriétaire de produit passera du temps avec les utilisateurs du produit et verra comment ils l’utilisent. Un propriétaire de produit avec créativité, initiative et vision pour créer un grand produit vaut son pesant d’or.
2. La compréhension de ce qui exigée pour créer une application réussie
Peut-être à cause de l’accent placé sur le point numéro un, les sociétés choisissent souvent quelqu’un du côté business ou métier pour devenir le propriétaire de produit, car on voit leur connaissance du business comme primordiale et, dans des nombreux cas, la seule et unique qualification pour le rôle. Et pire encore, on leur demande souvent de tenir ce rôle en plus de leur travail habituel.
Cependant, les excellents propriétaires de produit comprennent quoi construire, mais sont aussi familiers avec le processus de développement. Ils comprennent les flux, les implications de la dette technique, l’automatisation et les tests. Ils comprennent aussi à quel point il est crucial de mettre le logiciel entre les mains d’utilisateurs aussitôt que possible.
En général, des propriétaires de produit « business » manquent souvent de cette connaissance et de cette expérience et ils suivront par erreur le désir d’un produit entièrement fonctionnel plutôt que d’apprécier la valeur de retours rapides. Beaucoup essaient d’inclure chaque fonction imaginable plutôt que de travailler vers un jeu de fonctions minimal pour obtenir des retours et tirer de la valeur le plus tôt possible.
Que préfèreriez-vous avoir ? Un propriétaire de produit expérimenté avec zéro connaissance business, ou un expert business avec zéro expérience de livraison de logiciel ? Avant que vous ne répondiez, considériez ceci : la connaissance business peut être obtenue par une discussion efficace, l’observation et les retours. Cependant, la compréhension d’un bon cycle de développement logiciel agile est beaucoup plus difficile à apprendre et il n’y a rien qui remplace l’expérience.
Typiquement les meilleurs produits résultent d’expériences, de tests et de retours, avec une volonté à être flexibles dans les réponses. Les propriétaires de produit posent des priorités et interprètent la vision, donc ils ont plus d’influence sur la création de produit que qui que ce soit d’autre. Leurs choix de priorités peut profondément impacter la valeur et la qualité du produit. S’ils manquent de compréhension sur l’importance des tests, des retours utilisateurs et des bons principes de développement logiciel, ils peuvent entrer en conflit et semer le désaccord dans une équipe.
Hexagon est partenaire de DantotsuPM
3. Une communication efficace avec les parties prenantes tant techniques que business
Pour terminer, il y a un énorme besoin de communication efficace. L’importance ne peut pas en être exagérée.
Les excellents propriétaires de produit écoutent, observent, explorent et réfléchissent. Ils demandent des retours, lisent entre les lignes et observent le langage corporel. Quand il s’agit de comprendre l’utilisateur, ils portent une grande attention aux détails et recherchent attentivement des points de douleur et de satisfaction. Ils cherchent les meilleures façons de servir leurs utilisateurs.
La plupart d’entre nous pensent à la communication comme à une conversation, mais pour un propriétaire de produit, l’observation et l’écoute sont aussi très importantes. Avoir de l’empathie avec l’utilisateur et le client est critique. Il est impératif de comprendre leur domaine et d’utiliser leur vocabulaire pour communiquer. Si vous ne comprenez pas certains termes, il est essentiel de développer une attitude attentive et de poser des questions pour montrer votre intérêt, votre envie d’apprendre et votre engagement.
Un grand propriétaire de produit apprend à dire non avec respect et d’une manière qui indique qu’il comprend ce qui est demandé. Grâce à cela, on ne devrait pas voir un bon propriétaire de produit comme un obstacle ou une barrière, mais un guide vers de bonnes décisions. Le mot « Non » devrait être délivré d’une façon qui laisse le client confiant que cette décision est juste, même si ce n’est pas ce qui a été initialement voulu et que le propriétaire de produit livrera le meilleur produit en fonction de tous les paramètres.
Au contraire, si le propriétaire de produit choisit de dire oui, il devrait être capable d’en transmettre les implications. Les propriétaires de produit devraient avoir un certain nombre d’outils qui peuvent aider les gens à comprendre leurs décisions.
Le propriétaire de produit doit aussi communiquer avec l’équipe de développement et doit comprendre des termes techniques de développement pour qu’ils puissent avoir une pleine compréhension de la mise en œuvre technique, même s’ils n’ont pas d’autorité sur comment les choses sont faites. Autrement dit, ils devraient avoir un fort intérêt dans la compréhension du processus.
Ils doivent aussi être capables de communiquer des besoins business et des termes métier d’une façon qui donne du sens à l’équipe de développement. Être respectés et compris tant par le business que l’équipe technique est un exploit majeur et comme nous le savons, tout groupe parle dans le jargon que seuls ses membres comprennent. Ces signes verbaux que l’on doit expliquer à un étranger peu familier peuvent démoraliser l’équipe. Il est important de ne pas sous-estimer cette capacité.
Les propriétaires de produit ont aussi besoin de créativité pour communiquer des idées de design, ou, si les idées viennent d’autres, la capacité de comprendre cette créativité et de la transmettre aux équipes business et techniques. Il en va de même pour les parties prenantes principales (mis à part les utilisateurs). Ce groupe finance généralement le produit et ils veulent voir la progression et un bon management de leur investissement, donc ils peuvent demander des prévisions et insister même sur des engagements fermes.
Et si un produit doit être vendu, il est probable que le propriétaire de produit devra être impliqué avec les ventes et le marketing, ce qui amène tout un train d’autres compétences et de problèmes de communication, y compris la compréhension des implications sur le marché.
En prenant tout ceci en considération, nous avons maintenant chargé notre propriétaire de produit du besoin de communiquer avec les gens expérimentés qui prennent des décisions financières, d’exprimer les risques et les prévisions de façon concise, mais significative et transparente, informative et confiante. Un propriétaire de produit devrait tenir bon sur sa position et parler vrai face aux autorités et au pouvoir.
Bref, un grand propriétaire de produit est un maître communicateur, a un désir insatiable de connaissance et cherche toujours à comprendre et à être compris.
Recherchez et appréciez les bons Propriétaires de Produit
Le jeu de compétences d’un bon propriétaire de produit est large et diversifié, cependant les bons font paraître cela facile. Si vous avez un état d’esprit de propriétaire de produit, il est probable que vous avez déjà de bonnes compétences de communication et que vous aimez en apprendre davantage dans de nombreux domaines.
Il est aussi probable que vous êtes le genre de personne qui donne tout pour livrer un produit et se délecte des réactions, aime la flexibilité et le changement et ne se démotive pas à la pensée de devoir refaire quelque chose pour l’améliorer.
La résolution de problèmes est un challenge et être capable de voir au-delà de l’évident, d’aller chercher l’information chez les utilisateurs et présenter ensuite quelque chose de grand peut être une joie. Cela ne signifie pas, cependant, que ce n’est pas incroyablement difficile, accablant de temps en temps, tristement inapprécié et peut-être sous-payé. Mais un grand propriétaire de produit réussira malgré ces points douloureux.
Le propriétaire de produit est la clé de voute d’un grand produit et nous devrions les rechercher et les utiliser convenablement. Vous serez stupéfié de ce qui peut être réalisé avec la bonne personne dans ce rôle.
FDF est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Quand nous manageons des projets en une approche de livraison prédictive, l’identification des dépendances et leur suivi est fait lors de la grande planification amont en utilisant les activités après décomposition des tâches et la sagesse collective des membres de notre équipe et des principales parties prenantes. Si un changement majeur d’approche ou de portée de solution est identifié, on considère les impacts et nouvelles dépendances lors de l’analyse de la demande de changement.
Matchware est partenaire de DantotsuPMVoici le diagramme du Modèle Scrum
Mais sur ces projets qui suivent un cycle de vie adaptatif, cela devient un peu plus compliqué. Étant donné la nature émergente des exigences et du design, nous sommes seulement capables de voir les dépendances dans la lumière « des phares » de notre équipe et ceux-ci pourraient seulement nous montrer les deux semaines à venir de travail. Une équipe pourrait avoir considéré “Toutes les dépendances ont-elles été identifiées et capturées ?” dans sa définition de Ready (prêt) mais cela ne signifie pas toujours qu’il est possible de satisfaire cette dépendance dans les temps.
CertYou est partenaire de DantotsuPM
Nous nous efforçons toujours de construire une équipe qui possède toutes les compétences et l’autorité nécessaire pour délivrer la pleine portée du produit ou du projet.
Mais parfois, nous avons besoin d’un expert du sujet pour un petit sous-ensemble des fonctionnalités du livrable et si nous n’identifions pas ce besoin assez tôt, nous ne serons pas capables de livrer ces fonctions au bon moment. De plus, construire une équipe complète dans de grandes organisations est souvent difficile car il y a des équipes en place avec lesquelles travailler pour construire et livrer des fonctionnalités spécifiques, mais elles ne seront pas nécessairement disponibles à la demande.
Une façon de réduire les risques associés aux dépendances qui seraient identifiées trop tard est une combinaison de revue des User Stories avec une planification avancée.
La revue des User Stories fournit une occasion de rassembler les partenaires clés de livraison et de contrôle pour considérer les histoires à un haut niveau avec le Product Owner et l’équipe de développement. Cette revue donne aux partenaires externes une chance d’indiquer quelles histoires les intéressent et aidera l’équipe à savoir avec qui elle doit se synchroniser pour compléter l’une de ces histoires. En fonction de combien ces histoires remontent dans la Story Map, ils comprendront comment elles pourraient devoir être engagées. Les membres de l’équipe peuvent aussi commencer à identifier et capturer les interdépendances entre plusieurs histoires individuelles pour aider le Product Owner dans la priorisation du Product Backlog.
Comme les histoires avec des dépendances commencent à remonter dans le product backlog priorisé, l’équipe peut activement entrer en contact avec les partenaires externes pour demander leur participation un sprint ou deux à l’avance.
La planification est une activité récurrente dans les approches adaptatives car sans cela, un partenaire externe dont votre équipe a besoin va probablement répondre par le vieux cliché : “un manque de planification de votre part ne constitue pas un cas d’urgence de ma part.”
partagez ce billet avec vos amis, collègues et relations professionnelles
Négocier sur le séquencement des livrables est souvent préférable à dire non d’emblée à une nouvelle demande de changement.
Idem au niveau du portefeuille de projets
Est-ce le bon moment pour lancer un nouveau projet ? Devrions-nous renoncer à un projet ? Ou devrions-nous temporiser un peu et positionner ce projet dans le portefeuille de projets à venir ?
Hexagon est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Je ne sais pas pour vous, mais j’ai remarqué que nous indiquons rarement une date ou raison de péremption sur nos besoins utilisateurs et autres user stories…
Hors, il n’est pas si rare qu’après une certaine date, jalon projet ou événements internes ou externes, certains des besoins précédemment exprimés (et toujours en attente dans le product backlog) ne soient plus d’actualité.
Qu’en pensez-vous et comment traitez-vous ce problème ?
Est-ce en amont, en indiquant sur la user story une date ou les raisons pour lesquelles elle pourrait devenir inutile ?
Est-ce périodiquement lors de grands « ménages » saisonniers ?
Ou bien, serait-ce plutôt de manière opportuniste, lors par exemple d’un changement d’application de gestion du product backlog ? Ou d’arrivée d’un nouveau product owner, scrum master… ?
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
1,2,3… Scrum.org ajoute un nouveau niveau de test d’évaluation de certification de propriétaire de produit Scrum professionnel : Professional Scrum Product Owner
PMGS est partenaire de DantotsuPM
La semaine dernière, Scrum.org a annoncé des changements aux évaluations de certification PSPO.
Une nouvelle évaluation de PSPO II et des modifications sur le PSPO II actuel pour qu’elle devienne PSPO III.
Cela complète la famille d’évaluations et de certifications du PSPO en ajoutant un niveau distinguished en plus des niveaux fondamentaux et avancés fournis par le PSPO I et le PSPO II.
En restructurant ses évaluations et certifications Professional Scrum Product Owner (PSPO), et en ajoutant un niveau supplémentaire, Scrum.org permet aux professionnels de démontrer leur compréhension, leur connaissance et leur pratique du rôle du propriétaire de produit Product Owner avec Scrum.
Ces certifications attestent de leur capacité à maximiser la valeur offerte par le produit.
Je vous l’accorde volontiers, il ne s’agit pas avec Agile d’oublier que la complexité est bien réelle ni de l’ignorer…
Mais, il faut savoir commencer petit puis apprendre en marchant si l’on veut tirer rapidement bénéfice des avancées même modestes.
Par exemple, vous pouvez trouver acceptable d’avoir des paramétrages codés en dur dans la première version du logiciel, ou bien des capacités réduites de personnalisation, ou encore un seul profil/persona utilisateur…
Ou des choix de coloris limités pour vos premières productions.
CSP est partenaire de DantotsuPM
Devrions-nous adopter certaines des approches de « triage » utilisées dans les services des urgences des hôpitaux pour définir nos MVPs ?
Livre sur Amazon
Darria Long, médecin urgentiste, explique les principales leçons tirées des urgences de l’hôpital sur la gestion du stress, du chaos et de la vie.
Le Dr. Darria Long Gillespie est un médecin d’urgence formé à Yale et Harvard, auteur du livre à succès « Mom Hacks ».
partagez ce billet avec vos amis, collègues et relations professionnelles
Ne pas savoir ce qui est attendu de nous est stressant. Ceci est d’autant plus vrai que nous évoluons de plus en plus souvent dans des équipes transverses et multi disciplinaires. Il n’est pas rare que les membres de l’équipe projet aient peu d’occasions de se rencontrer en face à face pour faire connaissance. Voici une source de stress que la ou le manager de projet peut attaquer de front.
Il n’est jamais facile d’être confronté au négativisme. Mais en plus, cela peut être carrément toxique et nuisible, favorisant une mentalité de cynisme, de fatalisme et même de défaitisme.
Si vous êtes entourés d’énergie négative qui provienne d’un collègue, associé, ami, ou membre de votre famille, vous devez apprendre à vous protéger et à ne pas vous y laisser emporter.
Voici six stratégies que vous pouvez utiliser pour vous protéger !
Commencez dès aujourd’hui à développer les habitudes et les stratégies qui vous maintiendront bien campé sur vos deux pieds quand tout autour de vous chavire. Nous travaillons tous toujours plus longtemps et stressons davantage, plus occupés que jamais. Mais il est vraiment possible de manager tout ce qui arrive, de rester les deux pieds sur terre même quand tout autour de nous semble échapper à tout contrôle.
Livrer souvent un produit certes incomplet mais utilisable et de valeur c’est Agile !
Personnellement, je ne connaissais ni MVE ni MMF et je trouve que ces concepts sont utiles pour préciser ce que l’on cherche à réaliser et surtout ce que l’on peut ou pas livrer aux clients et utilisateurs. L’idée des spikes sur une journée pour préciser les besoins me parait également très intéressante.
partagez ce billet avec vos amis, collègues et relations professionnelles
Un challenge très commun chez les managers de produit de tous niveaux d’expérience est de comprendre et mettre en œuvre une certaine forme de processus répétable autour de la priorisation.
Certaines personnes prennent une approche très légère, elles font des décisions basées sur leur propre expérience, données et conviction sur la direction du produit. D’autres prennent une approche beaucoup plus rigoureuse, appliquant des scorecardset autres mesures « objectives » à travers une pléthore de différentes métriques potentielles.
Je dois ici vous dire qu’il n’y a rien de mauvais avec n’importe laquelle de ces approches, mais il m’est aussi apparu clairement au cours de mes années de manager de produit qu’il n’y a aucune solution miracle pour vous assurer que vos décisions de priorisation seront bonnes plus souvent que mauvaises.
Trop compter sur des systèmes et des scores aboutit souvent seulement à un faux sentiment de sécurité que « le processus » était bon, quand en creusant vous constaterez que ces “scores objectifs” ne sont rien plus qu’un système avec lequel jouer.
Il y a cependant 3 choses dont je pense que chaque système de priorisation devrait tenir compte. Aussi, sans plus de cérémonie, discutons valeur, difficulté et instinct…
#1 – Prioriser c’est prendre en compte la valeur
Si nous pensons au problème racine que nous essayons de résoudre avec nos efforts de priorisation, ce devrait être que nous essayons de livrer la plus grande valeur possible, aussi rapidement que possible, en apportant des bénéfices à nos utilisateurs finaux et clients. Si c’est votre but (et si ça ne l’est pas, honte à vous !), alors l’un des facteurs les plus importants à considérer dans vos efforts de priorisation est la valeur que cette chose apportera vraiment.
Apporter la plus grande valeur possible, aussi rapidement que possible à nos clients.
Certains lui donnent une valeur numérique, d’autres utilisent une valeur monétaire — quoique ce soit qui marche, tant que vous considérez combien de valeur vos efforts vont délivrer. Cependant, baser vos décisions seulement sur la valeur marchande peut souvent aboutir à une dépriorisation de la dette technique et des investissements d’infrastructure. S’il vous plaît, pour l’amour de toute puissance supérieure en laquelle vous croyez, n’en soyez pas la victime. Bien que la dette technique et l’infrastructure pourraient ne pas avoir la valeur évidente pour le client, échouer à investir le nécessaire dans celles-ci causera l’échec de votre produit à un certain point critique pour un certain client critique. Si vous utilisez la valeur pour le client comme unique ou principale métrique, assurez-vous s’il vous plaît que vous avez un groupe de taches séparé pour le travail qui vous permet de rembourser votre dette technique et investir dans des améliorations d’infrastructure. Ayez confiance en moi, vous respirerez beaucoup plus librement en sachant qu’il n’y a pas un certain item technique inconnu qui va causer un effondrement général au plus mauvais moment possible.
#2 – Prioriser c’est prendre en compte la difficulté
Alors que la valeur pour le client est importante, il est également important que nous comprenions la quantité de travail qui va entrer dans toute nouvelle fonctionnalité ou amélioration de notre produit. Peu importe combien la valeur client est incroyablement élevée, si vous ne parviendrez jamais en réalité à compléter le travail à temps pour capitaliser sur cette opportunité. Trop souvent, des managers de produit décident seuls de la difficulté de quelque chose sans impliquer quelqu’un côté développement, support, ou équipes de livraison : C’est une erreur de débutant que même les managers de produit avec plus de 10 années d’expérience font tout le temps (oui, je la fais aussi parfois).
Attention au mirage venu de la seule imagination du manager de produit sans réelle prise en compte de la faisabilité.Évaluer l’effort exigé pour ajouter une fonctionnalité ou une capacité est plus précis quand réalisé en impliquant les gens qui feront effectivement le travail. Ils connaissent leurs capacités mieux que vous, ils connaissent la technologie mieux que vous, ils connaissent le code existant mieux que vous, etc. Cela ne signifie pas que vous devez tout décomposer en tâches, ou même en histoires utilisateur mais cela veut dire que vous devez consulter vos équipes techniques pour avoir une meilleure idée de combien une fonctionnalité est « grande », ou combien de temps il leur faudrait pour la produire. Quand nous devons évaluer la difficulté de résoudre un problème, assurons-nous que nous nous basons sur des experts et n’utilisons pas simplement nos propres opinions qui seront plus souvent fausses que correctes.
#3 – Prioriser c’est aussi suivre son instinct
Des données objectives et quantitatives sont des apports épatants dans tout processus de priorisation et plus de données vous pouvez obtenir, meilleures vont probablement être vos décisions. Mais il y a aussi un aspect inexprimable à la priorisation qui fait de ce processus tout entier plus un art qu’une science. Franchement, si tout ce qu’il fallait était des données objectives déposées dans un tableau qui donne un score alors vous n’auriez pas vraiment besoin de managers de produit pour mener vos efforts de priorisation. Vous auriez un système basé sur l’Intelligence Artificielle qui considère vos idées, prend toute les données disponibles et vous dit exactement que faire et précisément quand le faire. Heureusement pour ceux d’entre nous qui avons choisi le Management de Produit pour carrière, ce n’est pas le cas.
Il y aura toujours une partie d’analyse subjective quand on regarde les données et prend des décisions sur si vraiment la direction que nous indiquent les données signifie réellement quelque chose dans le schéma d’ensemble. J’ai travaillé dans des environnements où les décisions ont été prises par des résultats d’étude Six Sigma, des tableaux, un processus « objectif » de collecte de données et celles-ci ont poussé des fonctionnalités que personne ne voulait ni ne se souciait et en gaspillant des ressources techniques. L’équipe de Management de Produit savait qu’il y avait de meilleures options, savait qu’il y avait d’autres données subjectives pour soutenir ces efforts, mais a été forcée de se taire et de “laisser marcher le système”. Mais il n’a pas fonctionné, parce qu’il a ignoré l’expérience globale que de bons managers de produit apportent à la table. Un bon manager de produit sait quand insérer l’instinct et l’expérience dans l’équation et changer ou réarranger des choix basés seulement sur des données « objectives ».
Sans instinct, sans le ressenti dans ses tripes, seuls les choix apparemment les plus sûrs seront adoptés et l’innovation jetée par la fenêtre.
partagez ce billet avec vos amis, collègues et relations professionnelles
Les gens me demandent souvent : “Bonjour, j’ai une idée de produit. Puis-je vous l’envoyer et avoir votre avis ?”
Bien sûr, je réponds positivement.
Ils m’exposent l’idée et c’est d’habitude “une chose technique pour une sorte d’équipe.”
Et ma réponse est, “Bien, cela semble intéressant, mais…” et ensuite je pose quelques questions. Les réponses à ces questions me disent si l’idée est bonne.
Quelles sont ces questions?
A qui est destiné ce produit?
Pourquoi le veulent-ils ? Quel problème résout-il pour eux ?
Comment résolvent-ils ce problème aujourd’hui ?
Qu’est-ce qui ne va pas avec leur solution actuelle ?
Pourquoi votre produit est-il une meilleure solution pour eux ?
Tout d’abord, ils doivent connaitre les réponses à ces questions. Et, idéalement, ils ont parlé à de vrais gens qui rencontrent ce problème pour obtenir ces réponses.
Ces questions les concentrent sur “l’espace problème”. Avant de créer une solution, ils doivent s’assurer qu’il y a bien des personnes qui ont ce problème et qui payeront pour le résoudre.
Avant de dépenser des ressources sur un nouveau produit, assurez-vous qu’il y a de vraies personnes qui sont confrontées au problème que vous voulez résoudre et qu’ils payeront pour une solution.
Mais que je découvre d’habitude qu’ils ne connaissent pas les réponses à ces questions et que les réponses qu’ils fournissent ont été composées par eux-mêmes.
Ce qu’ils ont est “une solution à la recherche d’un problème”. Malheureusement, c’est la meilleure façon de créer une société qui échouera.
Que faire si vous avez une brillante idée de nouveau produit ?
Ma recommandation à quiconque a une idée de nouveau produit : Sortez et obtenez des réponses du monde réel à ces questions.
partagez ce billet avec vos amis, collègues et relations professionnelles
Livrer souvent un produit certes incomplet mais utilisable et de valeur c’est Agile !
Personnellement, je ne connaissais ni MVE ni MMF et je trouve que ces concepts sont utiles pour préciser ce que l’on cherche à réaliser et surtout ce que l’on peut ou pas livrer aux clients et utilisateurs. L’idée des spikes sur une journée pour préciser les besoins me parait également très intéressante.
La promesse des approches agiles est de livrer quelque chose souvent. Nous livrons, ainsi nous pouvons obtenir des réactions et discuter du reste à faire avec notre client (ou le Propriétaire de Produit / Product Owner). Et, donc nous pouvons évaluer notre processus et notre travail d’équipe tout le temps.
Trop souvent, les gens pensent aux fonctionnalités comme la somme de tout ce qui pourrait être dans ce périmètre. Cependant, nous en avons des alternatives à ce « tout » avec une variété de minimums.
Définissez les divers Minimums
Nous avons beaucoup de « minimums » possibles quand nous pensons aux histoires et plans de travail :
MVE, Minimum Viable Experiment – Expérience Viable Minimale : une histoire fournit des réactions pour l’équipe et le propriétaire de produit.
MVP, Minimum Viable Product – Produit Viable Minimal : une histoire ou un jeu d’histoires qui apportent assez de fonctionnalités pour que le client puisse les utiliser, même si ce ne sont pas les pleines fonctionnalités.
MMF, Minimum Marketable Feature – Fonction Commercialisable Minimale : le plus petit morceau de fonctionnalité qui le client considère de valeur.
Les MVEs peuvent être utiles quand vous voulez savoir si vous devriez même songer à cette partie d’un jeu de fonctionnalités.
Une équipe à la société Acme se débattait avec l’ensemble de fonctionnalités appelé « Rapports ». La fonctionnalité couvrait plusieurs grands rapports : ventes par géographie, par type de produit, agrégées par plusieurs clients et autres.
L’équipe savait qu’elle avait besoin d’une base de données, d’un système de production configurable et de sécurité/protection des données, parce que les clients pourraient accéder directement à certains de ces rapports. Et, chaque client devait avoir ses données protégées. Aucun client ne pourrait voir des données d’autres clients. Ils savaient qu’ils auraient besoin d’au moins deux niveaux de protection pour les clients et en interne à leur organisation.
En essayant d’écrire l’histoire dressant la liste de fonctionnalités des rapports, ils avaient créé plus de 20 histoires, juste pour les rapports client. Ils ont alors décidé qu’ils avaient besoin d’un MVE pour voir ce quels étaient les besoins minimaux pour les rapports clients. Peut-être sur-analysaient-ils le jeu minimal de rapports clients.
Comme ce produit exigeait de la sécurité, tant le MVP que le MMF nécessitaient une base de données avec des fonctionnalités de management de la sécurité. L’équipe savait que pour la base de données, ils auraient probablement besoin de données avant de créer un schéma pour cette base.
Ils ont finalement choisi d’expérimenter avec des données simulées pour voir de quoi les clients auraient vraiment besoin. Puis, ils pourraient élaguer l’arriéré d’histoires.
Les expérimentations créent un accord commun sur ce qui est important
Quand l’équipe a créé son histoire utilisateur originale pour des rapports clients, les membres avaient identifié trois niveaux de sécurité : le vendeur chez le client, le directeur commercial du client (ou tout autre membre de la direction) et les personnels internes de gestion de produit et commercial. Acme avait besoin d’informations sur ses clients et les clients de la sécurité nécessaire pour l’un et l’autre, c’est pourquoi il y aurait des niveaux différents de sécurité.
L’expérimentation initiale était simple : Sur un petit jeu de produits, comment les clients avaient-ils besoin de visualiser les données ?
L’équipe a pensé à simuler les rapports dans un fichier informatique. Puis, un testeur a suggéré qu’ils créent plutôt les prototypes sur papier car ils seraient faciles à changer instantanément, si nécessaire.
L’équipe (incluant le Product Owner) a passé une heure à créer une variété de prototypes papier et de flux de travail qu’ils pensaient que le client voudrait. Ils ont appelé le chef de produit qui avait rencontré un client la semaine précédente. Ils lui ont déroulé les flux.
Le chef de produit a accepté le premier flux et a rejeté les trois suivants et a expliqué pourquoi. Les explications ont surpris tant le Product Owner que le reste de l’équipe. Ils ont appris beaucoup de cette expérimentation et furent capables de reporter à plus tard un certain nombre d’histoires utilisateurs sur les Rapports – le tout en un seul jour de travail.
Puis, ils ont eu besoin de considérer le schéma de la base de données. Ils savaient qu’ils n’auraient pas de MVP sans la sécurité nécessaire. Cela signifiait qu’ils devaient embarquer non seulement la sécurité, mais aussi sa performance.
Les Spikes ont aidé toute l’équipe à apprendre ensemble
Ndlt : Les Spikes sont une invention de la méthode Extreme Programming (XP). C’est un type spécial d’histoire utilisateur qui est utilisé pour acquérir les connaissances nécessaires afin de réduire les risques sur un choix technique, de mieux comprendre une exigence, ou d’accroitre la fiabilité d’une estimation. Une spike a une taille maximale en durée car elle doit tenir dans le sprint qui la contient. À la fin du sprint, la spike sera déterminée comme done ou pas comme toute autre histoire utilisateur. Une spike est un excellent moyen de réduire rapidement les risques et elle permet à l’équipe d’obtenir des retours utilisateurs et de mieux appréhender la complexité.
Copyright 2000 Don Wells
Cette équipe avait essayé les spikes dans le passé et les avait appréciées.
Ils avaient un flux typique
L’équipe entière se rencontre 20 minutes maxi le matin (à 9 :00) pour passer en revue l’histoire. L’équipe a souvent besoin de seulement 5 minutes, mais on y alloue 20 minutes.
L’équipe décide comment travailler ensemble. Dans ce cas spécifique, deux développeurs travaillent en paire sur le schéma, deux autres membres de l’équipe sur les tests automatisés et l’autre développeur s’assure qu’il créée des outils pour que les testeurs puissent vérifier les résultats dans la base de données. Ils décident de développer et tester directement dans la base avant l’interface utilisateur.
L’équipe est séparée en ses sous-groupes et travaille pendant une heure.
Toutes les heures, ils se réunissent 5minutes pour un point rapide. Quelqu’un a-t-il été bloqué ? Tout se passe-t-il comme prévu ? Quelqu’un aurait-il besoin d’aide ? Quelqu’un a-t-il terminé et pourrait aider les autres ?
Leurs réunions n’étaient pas des standups traditionnels, où trop souvent, l’équipe se concentre sur la personne. Ces rencontres ont permis aux membres d’équipe de se concentrer sur le travail.
Au point rapide, l’équipe décide si elle a besoin de modifier les sous-équipes pour améliorer le flux du travail. Ils font ceci à chaque heure (avec une pause déjeuner) jusqu’à 16:00 ou quand ils ont terminé, le premier des deux.
L’équipe s’ arrête à 16:00 pour plusieurs raisons
Ils sont fatigués. Ils se sont concentrés toute la journée sur du travail difficile.
S’ils ne peuvent pas « finir » le spike dans la journée, le travail nécessitait probablement plus que même deux journées. Ils ont besoin de se regrouper et de replanifier.
S’ils ont terminé, ils peuvent expliquer ce qu’ils ont découvert au Product Owner.
À la fin de la première journée, ils se sont rendus compte qu’ils auraient besoin d’autres scénarios pour la performance et la sécurité. Il était le temps de discuter de comment ces aspects fonctionnaient ensemble et séparément avec le Product Owner.
Que pourraient-ils reporter en matière de performance, d’autant plus qu’ils n’allaient pas encore exécuter ces rapports sur de gros volumes ?
Les MVPs fournissent des retours à l’équipe
Produit Viable Minimum (MVP)
Le Product Owner mène la discussion d’équipe sur ce qui constitue un réel MVP. Un MVP signifie que les clients devaient être capables d’utiliser ce que l’équipe a livré. Ils choisissent cinq histoires et créent ce premier MVP centré seulement sur le vendeur interne à la compagnie. L’équipe s’attend à recevoir des réactions du personnel commercial sur les fonctionnalités et la performance. Ils utilisent ces retours pour prévoir les MVPs suivants à destination du personnel commercial de la société.
Dans ce cas, le Product Owner décide quel persona est le plus important à quel moment, pour séquencer les MVPs de manière logique. Il faut trouver la balance entre manager les retours de l’équipe et délivrer de la valeur pour les clients.
Les MVPs permettent de créer un produit commercialisable ou MMF
Il faut plusieurs MVPs pour créer une MMF, une Minimum Marketable Feature (Fonction Commercialisable Minimale). Ce MMF fournit assez de valeur (et de cohérence produit) pour trois personae clés : le personnel commercial interne et leurs managers, ainsi que l’équipe de ventes.
Plus petit votre MMF, plus rapide le flux de travail pour le produire.
Vos minimums sont-ils assez petits ?
Je travaille régulièrement avec des équipes qui pensent qu’un MVE est la même chose qu’un MVP et qu’un MMF. Même s’il est possible que les trois soient identiques, le plus souvent ils sont différents.
Je constate que quand les équipes utilisent des spikes d’un jour, apprenant ensemble pendant cette journée, elles sont mieux à même de faire la différence entre ces divers minimums.
A quel point pouvez-vous minimiser votre travail et en maximiser la valeur pour vos clients ?
Livre sur Amazon
Cet article a été écrit parJohanna Rothman. Johanna, est connue comme la “Pragmatic Manager” qui fournit des avis honnêtes sur vos problèmes.
Cela peut bien fonctionner pour les projets où toute la portée d’un projet peut être décomposée dès le début, mais peut être difficile lorsqu’une approche par vagues (rolling waves) est adoptée, à moins qu’il n’y ait une identification claire des parties de planification qui doivent être élaborées à une date ultérieure.
Elle présente le même risque que l’approche axée sur les phases, mais en plus grave, car il est possible que des livrables sous-composants soient assumés par chaque partie prenante comme étant la responsabilité d’une autre partie prenante.
Sur les 141 réponses combinées :
DantotsuPM.com 