3 qualités difficiles à trouver et qui font un(e) excellent(e) Propriétaire de Produit (Product Owner)

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.

3 Elusive Qualities of a Great Product Owner

https://www.agileconnection.com/article/3-elusive-qualities-great-product-owner par John Yorke

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

Dans mon projet, j’ai suivi exactement la recette et ça n’a pas marché !

Il est plus facile de critiquer la recette que de réellement l’appliquer à la lettre.

Rationalizing your project

https://seths.blog/2019/04/rationalizing-our-project/ par Seth Godin

“J’ai suivi exactement la recette et ça a échoué.”

C’est ainsi que débutent bien des commentaires sur les recettes en ligne. Puis le commentateur explique qu’il a remplacé la crème aigre par du yaourt (c’est ce qu’il avait dans le réfrigérateur), qu’il a remplacé la farine de blé par de la farine de riz (c’est sans gluten) et qu’il a utilisé le grille-pain au lieu d’un vrai four…

Une fois que vous êtes profondément investi dans un projet, c’est le vôtre. Il est en route. Vous y avez investi tout votre cœur, votre âme et votre fierté.

Face au conseil utile, il est facile de répondre: “bien sûr, c’est ce que je fais déjà”. Et de triturer ensuite votre description du projet actuel pour le faire correspondre, enfin presque, à un semblant de suivi de la nouvelle approche suggérée.

Mais ce n’est pas vrai. Vous gaspillez simplement du temps et des efforts à feindre d’utiliser cette nouvelle façon de faire de quelque chose.

Et si, pendant juste une semaine ou même un jour, vous agissiez « et si » ?

Et si vous refaisiez votre plan, ou vos perceptions du monde ou votre approche d’une façon totalement nouvelle, d’une manière qui respecte et embrasse la chose que vous avez juste apprise. Et si vous suiviez la recette en suivant la recette, simplement pour apprendre cette technique…

Après avoir appris à maîtriser parfaitement une technique, vous pourrez peut-être commencer à la modifier selon vos besoins.

Après cela, après que vous ayez vu ce qu’elle peut faire, allez ensuite de l’avant et voyez ce qui arrive quand vous refaites la chose qui vous avait amenée à chercher une nouvelle recette en premier lieu.

Dans une ère d’accès illimité à des recettes, la partie difficile sur obtenir un bon conseil n’est pas de l’obtenir. C’est de le suivre. Et ensuite, vous pourriez être capables d’intégrer la recette et d’en faire une réelle compréhension.


Je profite de ce billet pour vous rappeler que depuis peu PMI® a mis en ligne le « Resource Hub ».

Le Project Management Institute® a rassemblé une variété de ressources en ligne gratuites, d’événements virtuels et même un avant-goût de nouvelles offres numériques pour aider les managers de projets à se connecter à une communauté mondiale, à acquérir des compétences et à se préparer à progresser dans un monde que nous espérons prochainement « post-COVID-19 ».

Visitez le PMI Covid-19 Resource Hub

Explorez et partagez ces ressources, et revenez souvent car il y a de fréquentes mises à jour.

Lien vers le « resource hub »

PMI is a registered mark of Project Management Institute, Inc.

Biais Cognitif – d’Anticipation

Notre cerveau est câblé pour attendre des expériences positives. Cette anticipation contribue à notre bonheur.

Par exemple, acheter à l’avance ses billets d’avion pour les prochaines vacances crée un sentiment de joie et d’excitation. Mais il y a aussi des cas d’anticipation anxiogène qui nous incitent à nous inquiéter inutilement. Comme, qu’adviendra-t-il si la pandémie continue de sévir alors que j’ai réglé à l’avance mon futur séjour ?

En quoi sommes-nous concernés dans nos projets ?

résultatsLes projets commencent dès la préparation et présentation du cas d’affaire ou business case à créer des attentes de la part de toutes les parties prenantes. Nous y identifions tous les bénéfices matériels et intangibles, les gains escomptés, les économies, les accroissements de parts de marché, les augmentation du niveau de satisfaction client…

jeter l'argentLa partie « identification des risques » du cas d’affaire va modérer un peu cette image rêvée et ramener les choses dans la réalité. Hors, si la balance est mauvaise, trop d’excitation et d’espoirs ou trop de peur des risques encourus, le manager de projet devra en permanence dépenser du temps et de l’énergie à encourager les uns et calmer les autres.

Comment éviter le plus possible ce travers ?

Soyez clairs et factuels sur les risques en focalisant l’attention sur les plans de management de ceux-ci plutôt de l’anticipation de désastres. Donc, ne minimisez pas les impacts et probabilités de matérialisation des risques, mais ne jetez pas non plus d’huile sur le feu en pensant qu’ainsi vous obtiendrez davantage d’attention. Parce que vous l’obtiendrez cette attention et elle vous coûtera bien plus qu’elle ne vous rapportera en temps, ressources et énergie.

Ce biais peut-il nous être utile ?

Quels sont les jalons auxquels vous allez montrer vos livrables et nourrir une attente positive ?

Créez une attente positive pour votre nouveau produit (ou service) en l’annonçant à l’avance. Créez un buzz positif, quelque chose à attendre avec impatience pour vous assurer que vos parties prenantes et commanditaires sont mobilisés, positifs et volontaires.

Prévoyez et annoncez des livrables même partiels qu’ils pourront voir et toucher pour les rassurer sur la réalisation des promesses du projet. Le jalonnement judicieux d’un projet de plusieurs trimestres ou années permet à chaque passage de jalon de créer une attente positive, de l’anticiper et de ressentir une impression positive de progression vers l’objectif tant attendu.

Hexagon est partenaire de DantotsuPM

Que faites-vous dans mon bureau ? par Jean Charles Savornin (1er chapitre de l’ouvrage « Innover, Organiser, Inspirer pour réussir sa Transformation »)

Avez-vous consulté « Innover, Organiser, Inspirer pour réussir sa Transformation » Techniques et témoignage de vie de Chefs de Projet de la Francophonie ?

Vous pourrez  très prochainement le télécharger gratuitement.

Cet ouvrage collectif (infos détaillées ici) nous invite à suivre le parcours original et personnel de professionnel(le)s auteurs chacun d’un chapitre et qui nous y livrent les leçons tirées de leur expérience dans le management de projet et le leadership.

Premier thème: « Appréhender avec sérénité la dimension humaine »

Et tout premier chapitre : « Que faites-vous dans mon bureau ? » par Jean Charles Savornin

C’est par ces mots accusateurs, que Jean Charles Savornin commence le récit de son aventure !

En tant que jeune chef de projet venu rénover une installation industrielle, il était assis dans le bureau d’un des cadres exécutifs clé du projet, senior et très expérimenté.

Voici une histoire qui aurait pu très vite tourner au vinaigre, sans la présence d’esprit, la lucidité, et l’humilité de Jean-Charles.

Cet exemple concret nous invite à réfléchir aux bonnes pratiques comportementales faites de :

  • Mesure,
  • optimisme,
  • questionnement raisonné,
  • anticipation,
  • sens de l’essentiel et
  • bien comprendre ce qui compte vraiment pour le client.

Même sur un produit ou service très technique, le relationnel et la gestion des personnes sont la clé du bon déroulement du projet.

Le leadership n’est pas une chose que l’on énonce à travers de grands principes mais plutôt une expérience qui se vit au quotidien tout en naviguant avec l’équipe.

FDF est partenaire de DantotsuPM
Ne manquez pas le wébinaire du 21 Octobre avec Jean-Charles Savornin !

2 aspects des risques dans les projets auxquels vous n’avez peut-être pas encore pensés !

David Hillson, the « Risk Doctor » a enregistré ces 2 vidéos que j’ai trouvées intéressantes sur des aspects des risques auxquels réfléchir à l’avance.

La première est d’aller plus loin que probabilité et impact pour déterminer la priorité d’un risque. La seconde lui permet de discuter des risques qui ne sont pas liés à des événements incertains.

Aller plus loin que probabilité et impact

La plupart des gens priorisent les risques individuels en fonction de la probabilité qu’ils se produisent (probabilité, fréquence, probabilité) et de l’ampleur de l’effet qui en résulte (impact, conséquence). David Hillson explique pourquoi d’autres facteurs pourraient être pris en compte lorsque nous décidons quels risques sont les plus importants.

Que sont les risques « non liés à un événement »?

Nous savons que les risques sont des effets de futurs incertains événements qui auraient une incidence sur les objectifs s’ils se produisaient. Mais David Hillson dit qu’il y a trois autres types de risques qui ne sont pas des événements, mais qui sont tout aussi importants. Si nous ne comprenons pas, ne cernons pas et ne gérons pas ces risques de façon proactive, il nous manque beaucoup de risques qui pourraient nous toucher.


Ne manquez pas de visiter le site du Risk Doctor et ses briefings mensuels qui sont disponibles en Français !

CSP est partenaire de DantotsuPM

La magie d’histoires utilisateur courtes (User Stories)

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 ?

The Magic of Small User Stories

https://www.agilealliance.org/the-magic-of-small-user-stories/ par Dwight Kingdon

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.

Pourquoi des histoires plus courtes ?

  • Une petite de dose satisfaction à chaque histoire complétée

    Focus : Des histoires courtes nous focalisent et nous aident à voir que la fin n’est pas trop éloignée. Il est fréquent de se sentir écrasé par les détails quand nous travaillons sur de longues histoires.  De brèves histoires génèrent aussi une satisfaction de l’équipe plus élevée; les personnes reçoivent une petite dose de dopamine à chaque fois qu’elles finissent quelque chose.

  • Transparence : Des histoires courtes fournissent une transparence et une visibilité beaucoup plus claire des progrès dans le sprint pendant le Daily Stand-Up.  Le réalisé est facile à suivre quand nous voyons une série de courtes histoires achevées; il est plus difficile d’évaluer et de visualiser le réel progrès sur une grande histoire chaque jour.
  • Relisez ce billet sur pourquoi Fibonacci

    Prévisibilité : Des histoires courtes ont tendance à aboutir vélocité plus précise et juste, ce qui réduit la variabilité et améliore la prévisibilité.  Des évaluations relatives de points d’histoire en utilisant la séquence de Fibonacci sont par définition de moins en moins précises pour de plus grandes histoires – voir “le cône d’incertitude”.  Ainsi, une histoire 13 ou à 20 points est probablement beaucoup moins prévisible que plusieurs histoires à 2, 3, ou 5 points.

  • Flexibilité : Des histoires courtes fournissent .  Elles fournissent davantage de flexibilité pour nous adapter comme nous apprenons.  Quand les circonstances changent ou que certaines histoires deviennent sans utilité, il y a moins de perte dans la réorganisation ou l’élimination d’une courte histoire.
Relisez ce billet
  • Livraison : Des histoires courtes permettent aux équipes de test de commencer à évaluer plus tôt dans le sprint et de travailler sur de plus petites portions de code.
  • Risque Réduit : Des histoires volumineuses augmentent le risque que l’équipe ne livre rien à la fin du sprint qui soit 100 % fait (Done).  La capacité de l’équipe ressemble à un entonnoir.  Quand nous essayons de forcer un grand objet (de grandes histoires) à y passer, l’entonnoir se bouche.  Par exemple, un développeur travaillant sur une grande histoire peut aussi être le seul avec le jeu de compétences nécessaires pour compléter une autre histoire critique.

Comment puis-je créer des histoires plus courtes ?

Vous trouverez des tas de bons articles sur la décomposition d’histoires d’utilisateur sur Google.  Néanmoins, voici une poignée de questions que j’ai trouvé utiles pour déterminer comment créer des histoires plus courtes :

  • 80/20
    Vidéo explicative sur Pareto

    S’il y a plusieurs résultats dans une unique histoire utilisateur, sont-ils tous nécessaires tout de suite ? Y-a-t-il un découpage 80/20 qui fournirait la majeure partie de la valeur ?  Pouvez-vous développer ces 20 % dans une autre histoire différente ?

  • Avez-vous des règles métier multiples ou plusieurs personas dans l’histoire utilisateur ? Ces règles métier peuvent-elles être construites séparément, ou les différents personas traités dans des histoires séparées ?  Des règles métier plus simples peuvent-elles suffire pour le moment pour faire marcher la solution ?
  • Est-ce que le parcours optimal peut être codé en premier sans toutes les exceptions ?  Ces exceptions peuvent souvent être relogées dans des histoires complémentaires.
  • Y-a-t-il de multiples plates-formes ou plusieurs interfaces utilisateur associées à l’histoire utilisateur ? Pouvons-nous les développer une par une ?
  • Des opérations multiples sont-elles contenues dans l’histoire utilisateur c’est-à-dire  Créer, mettre à jour, supprimer une donnée? Pouvons-nous développer une opération à la fois ?
  • Quels scénarios de test s’appliquent ? Certains scénarios sont-ils complexes et pas très critiques ?  Une première itération plus simple peut-elle être développée pour valider le design ?
  • La plupart de la complexité de l’histoire vient-elle d’exigences non-fonctionnelles comme la sécurité ou la performance ?  Si c’est le cas, l’histoire peut-elle être découpée pour d’abord faire le travail sur la fonctionnalité, puis modifiée plus tard pour satisfaire ces exigences non-fonctionnelles ?

Combien courte est « courte » ?  Quelle est la bonne taille ?

Relisez ce billet sur la méthode INVEST

Ce sont des questions très subjectives et elles dépendent de plusieurs facteurs dont la capacité de l’équipe, la durée de sprint et autres.  Un bon point de départ pour déterminer la taille idéale de l’histoire doit utiliser l’acronyme I.N.V.E.S.T.  Si vous êtes peu familiers avec cette approche, cherchez simplement “agile invest” sur votre navigateur internet pour en apprendre davantage.  Une histoire doit délivrer la valeur.  Livrer une histoire qui a peu de bénéfices perceptibles juste pour la garder petite n’a probablement aucun sens.  Au final, les histoires utilisateur plus courtes sont d’habitude meilleures que de plus longues.  Mais, le bon sens s’applique pour vous assurer qu’une histoire utilisateur peut livrer une réelle valeur et peut aussi être achevé en un unique sprint.

CertYou est partenaire de DantotsuPM

Disciplined Agile : Êtes-vous curieux d’en apprendre davantage ?

Si vous avez entendu parler de Disciplined Agile et que vous voulez en apprendre davantage…

L’équipe Disciplined Agile du PMI France se propose de vous accompagner dans cet apprentissage en lançant le Special Interest Group (SIG) Disciplined Agile.

Relisez ce billet sur les certifications Agile du PMI
A qui s’adresse le SIG ? Tous les membres du chapitre PMI France sont les bienvenu.e.s.

Comment participer au SIG ?

Répondez au questionnaire d’inscription au SIG Disciplined Agile PMI-France afin de vous inscrire.

QRP est partenaire de DantotsuPM

Comment ça marche ?

  • Les activités du SIG sont concentrées sur un forum dans un environnement technique encore en cours de définition.
  • Ce forum permettra aux membres du SIG d’échanger librement dans le cadre d‘une charte de bonne conduite (qu’en bons agilistes nous définirons ensemble)
  • Différentes activités seront proposées dont la 1ère sera un cercle d’étude.

Quand ? Dès novembre 2020

Tous les détails sur le site PMI France
CertYou est partenaire de DantotsuPM

Biais Cognitif – de Disponibilité

Nous avons tendance à penser que les choses qui nous viennent spontanément à l’esprit sont plus communes et plus importantes que celles auxquelles nous ne pensons pas immédiatement.

En quoi sommes-nous concernés dans nos projets ?

Confrontés à de nombreuses sollicitations, nous nous basons souvent sur les informations qui nous reviennent le plus facilement à l’esprit.

A cause de ce biais, les choses ou événements récents, fréquents, extrêmes, imprimés dans notre mémoire à court terme ont plus d’influence sur notre décision que grand nombre d’autres informations peut-être plus pertinentes.

Parmi toutes les informations que vous allez présenter, seule une infime portion sera retenue.

Comment éviter le plus possible ce travers ?

« J’ai déjà parcouru un quart du semi-marathon » est plus motivant que « Il me reste les trois quart du semi à compléter »

Faites en sorte que ce ne soient pas les mauvaises informations comme les retards, contretemps, problèmes… qui frappent les esprits mais plutôt les solutions, les perspectives de bénéfices, les résultats déjà obtenus.

Par exemple dans nos projets informatiques, bien que donnant la même information, « Nous avons déjà déployé la solution à 10% des utilisateurs » à un impact différent de « Il nous reste encore 90% des utilisateurs à atteindre ».

Ce biais peut-il nous être utile ?

N’hésitez pas à adopter des leitmotivs répétitifs pour le projet afin de bien ancrer son importance cruciale pour le futur de l’organisation, de l’entreprise, que dis-je, de toute l’industrie ! Bon, j’abuse un peu… mais vous saisissez le truc: Rendez votre projet mémorable et vos arguments frappants.

Par exemple, mettez très souvent votre business case à jour et rafraichissez la mémoire de vos parties prenantes sur tous les bénéfices attendus.

Le sacro-saint et régulier « tête à tête »: Le supprimer, l’améliorer, le rendre attendu et désirable ?

Selon votre propre expérience, les « tête-à-tête » ne sont-ils pas les rendez-vous les plus souvent reportés ou annulés ?

One-on-Ones: Regular and Sacrosanct

https://www.jrothman.com/mpd/management/2019/06/one-on-ones-regular-and-sacrosanct/  par Johanna Rothman

Livre sur Amazon

Quand Esther et moi avons écrit « Behind Closed Doors: Secrets of Great Management », nous n’avions pas vraiment pensé que les tête-à-tête étaient un secret. Mais, les managers ne les faisaient pas régulièrement. Les managers les annulaient pour d’autres réunions “de plus haute priorité ”.

Notre premier livre first modern management book parle de comment les managers se managent eux-mêmes. Une partie de ce management est comment et quand ils décident de tenir leurs tête-à-tête.

D’abord, je n’étais pas sûre de vraiment avoir besoin d’inclure ce chapitre. Mais, bien trop de managers ne s’efforcent pas toujours de trouver les meilleurs créneaux pour un tête-à-tête. Et, ils l’annulent ensuite.

Je ne parle pas juste de tête-à-tête entre un manager et une personne faisant un travail de savoir et de connaissances précieuses. Je parle aussi du cadre exécutif conduisant un tête-à-tête avec l’un des membres de l’équipe de direction. Les directeurs et managers méritent aussi leurs tête-à-tête.

J’ai deux règles sur le tête-à-tête

  1. Créez une fréquence régulière pour les tête-à-tête, au moins une fois toutes les deux semaines. Plus distants que cela et vous ne créez pas de rapport de confiance. Vous ne gagnez pas l’information organisationnelle dont vous avez besoin.
  2. Trouvez un créneau qui fonctionne pour vous deux. Cela signifie comprendre comment l’autre personne doit organiser son temps.

Je vous recommande de lire Maker’s Schedule, Manager’s Schedule de Paul Graham. Si vous n’avez pas encore considéré comment vous bloquez (ou pas) du temps dans votre agenda pour ces rencontres, cet essai pourrait vous éclairer sur vos options.

CSP est partenaire de DantotsuPM

Assurez-vous de toujours tenir vos tête-à-tête. Trouvez et maintenez une cadence régulière, au moins une fois toutes les deux semaines. Vous apprendrez plus que vous ne pouvez l’imaginer.


Si vous vous retrouvez seul…

Il se peut aussi que ce soit votre interlocuteur qui annule souvent les tête-à-tête.

Si vous êtes son supérieur hiérarchique, demandez-vous si vous lui apportez de la valeur lors de ces rencontres ou bien un mécanique reporting ou pire, une allègre distribution de corvées et de choses à faire…

plan do check act

Rappel de ce qu’est le « Plan Do Check Act », Cycle PDCA pour l’amélioration continue.

Le Cycle PDCA est une approche compréhensible, répétable pour travailler vers une amélioration continue.

PDCA Cycle for Continuous Improvement

https://projectbliss.net/plan-do-check-act-pdca-cycle/ par  Leigh Espy
plan do check act
Relisez l’article de Jean-Baptiste Jourdant : cultivez vos talents – Projet et qualité, de nombreux points communs !

Les équipes et des organisations s’efforcent constamment de trouver les meilleures façons de travailler. Bien des organisations doivent faire plus avec moins, moins de personnes ou moins d’argent. Et les organisations veulent toujours trouver des façons d’économiser de l’argent, de gagner en efficacité et rendre l’environnement de travail meilleur. Mais souvent la demande par la gestion pour faire ainsi peut sembler accablante.

Mais 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.

Faites un pas de plus et donnez-lui une chance. Et si vous trouvez une façon d’économiser à votre société de l’argent ou du temps, vous pourriez bien en obtenir un agréable bonus!

Plan Do Check Act – Cycle PDCA

Le Plan Do Check Act – Cycle PDCA est une méthode en 4 étapes utilisée dans le processus d’amélioration continue.

Le livre de Deming sur Amazon

PDCA est aussi connu sous le nom de Cycle de Deming. Dans les années 1920, Walter Shewhart a créé le concept Plan – Do – See (Planifier – Faire – Observer) connu comme le Cycle Shewhart. Edwards Deming l’a ensuite adapté. Une autre variation que vous pouvez rencontrer est le Cycle PDSA : Plan-Do-Study-Act, Planifier-Faire-Etudier-Agir

Mais ils mènent tous à la même chose…

Toutes ces approches s’est concentré sur l’amélioration continue. Et chacun des quatre composants joue un rôle spécifique dans ce processus d’amélioration continue.

Le Plan Do Check Act – Cycle PDCA est une méthode à 4 étapes fréquemment utilisée dans le processus d’amélioration continue. Chacun des quatre composants joue un rôle spécifique dans ce processus d’amélioration continue.

Plan – Préparer, Planifier

Relisez ce billet: Diagramme D’Ishikawa (Fishbone) pour aller chercher la source des problèmes.

En déterminant comment réaliser des améliorations, il est important de comprendre le problème. Vous ne pouvez pas mettre en œuvre des activités d’amélioration si vous ne comprenez pas d’abord le problème. Vous devez comprendre la cause première, dite cause racine, ses impacts et toute autre information appropriée sur le problème.

C’est ce que vous faites pendant cette phase de préparation.

Une fois que vous avez une meilleure compréhension du problème, vous développez alors un plan pour développer des améliorations.

Pour obtenir une approche plus normative de ces activités, les étapes 1 à 5 du papier 7 Problem-Solving approach  peuvent vous être utiles. Elles vous montrent pas à pas comment vous assurer que vous avez une pleine compréhension de la situation, définissez le problème correctement et choisissez la meilleure solution pour la situation. Vous développerez alors un plan pour développer la solution.

Une partie de la planification est comprendre votre ligne de base de départ et savoir quelle métrique utiliser pour mesurer vos progrès. C’est la seule façon pour vous de savoir si vous avez fait des améliorations adéquates.

Avant de passer à l’exécution de votre plan, identifiez clairement à quoi ressemblera le succès et comment vous saurez si votre approche était réussie. Vous devez être capables d’identifier des résultats quantitatifs ou qualitatifs pour savoir si vous avez été gagnants.

Do – Développer, réaliser, mettre en œuvre

Jusqu’ici, vous et votre équipe avez acquis une bonne compréhension du problème et vous avez développé un plan pour l’adresser.

Vous savez quelles sont vos bases de départ et ce que signifie la réussite. 

Maintenant vous exécutez votre plan. Vous pouvez le faire de deux manières différentes.

  • Vous pouvez mettre en œuvre votre plan sur un pilote, testant les réalisations avec un petit groupe avant de dérouler le plan pour tous.
  • Ou vous pouvez exécuter votre plan avec un plus grand groupe, mais vous assurer que le test est contrôlé.

Que vous choisissiez l’une ou l’autre de ces approches, mettez en œuvre les activités que vous avez identifiées pour atteindre des améliorations.

Check – Contrôler, vérifier

Après un délai prédéterminé, mesurez les résultats des changements effectués. Validez si les changements atteignent vos attentes.

Vérifiez par rapport aux mesures de vos lignes de base du départ. Utilisez la métrique que vous avez identifiée avant le lancement.

Vous voulez voir si votre plan a fonctionné et si vous avez obtenu des résultats positifs.

Vous identifierez aussi où vous pouvez encore améliorer le plan. Vous pouvez devoir tordre certaines choses ou modifier le plan en vous vasant sur ce que vous avez appris.

Vérifiez des résultats par rapport à votre ligne de base et voyez si votre plan a marché comme prévu. Vous pouvez vous devoir l’adapter. C’est un cycle apprenant.

Act (ou Adjust) – Agir, ajuster, réagir

Maintenant que vous savez si vos actions ont apporté une amélioration ou pas, exécutez les étapes suivantes appropriées.

Amélioration continue…

Si vous avez mis en œuvre votre amélioration sur un petit groupe pilote avec des résultats positifs, vous pouvez être prêts à lancer les changements sur un plus grand groupe.

Si vous avez exécuté ces changements sur le plus grand environnement et que tout est bon, vous standardiserez alors les changements pour qu’ils deviennent les nouveaux normaux dans l’environnement.

Alternativement, si les changements réalisés n’ont pas fourni les résultats attendus, ajustez le plan.

Et même si vous avez obtenu des améliorations, vous pouvez trouver en avançant que de nouvelles améliorations sont nécessaires. Dans ce cas vous pouvez répéter le cycle.

C’est l’objectif de l’amélioration continue.

Repeat – Répéter

Le Cycle PDCA n’est pas une activité isolée. Les équipes exécutent le cycle à plusieurs reprises pour continuer à améliorer les processus et construire sur des améliorations précédentes.

Votre équipe et environnement se sont améliorés, mais il y a probablement toujours une marge d’amélioration à exploiter.

De nouvelles connaissances, technologies ou approches peuvent survenir qui pourront aider l’équipe à performer encore mieux.

Ou votre nouvelle ligne de base peut vous donner une compréhension sur la façon de s’améliorer encore de différentes façons.

Ou vous pouvez être si inspirés que vous voulez essayer le cycle PDCA sur un autre processus de votre environnement.

Vous n’êtes pas limités sur combien de fois vous pouvez utiliser le cycle PDCA pour continuer à vous améliorer.

Les bénéfices du Cycle PDCA

Il y a de multiples bénéfices au Cycle PDCA :

Boucle de retours continue

PDCA vous donne une grande boucle de retours du terrain pour apprendre rapidement si votre plan fonctionne ou si vous deviez essayer une approche différente.

Perturbation limitée des processus business.

Vous pouvez essayer des solutions potentielles d’abord à une petite échelle avec un groupe pilote. Cela vous permet d’en apprendre davantage sans perturber l’organisation toute entière.

Gagner l’implication d’autres personnes.

Il faut souvent que beaucoup de membres de votre équipe s’engagent et participent dans la résolution de problèmes. S’ils contribuent à travailler vers des améliorations, cela peut les inspirer et les aider à voir le lieu de travail sous un nouveau jour. Ils peuvent même commencer à contribuer davantage à la résolution de problèmes et à l’amélioration continue.

Créer une culture d’amélioration continue.

Vous pouvez créer une culture d’amélioration continue et construire continuellement sur des succès.

Soyez conscients de ces défis

Ce cycle si simple a de super pouvoirs.

Quand vous utilisez le cycle PDCA, il y a plusieurs considérations à prendre en compte :

  • Il faut du temps. Le Cycle PDCA n’est pas une approche qui peut être utilisée sur des problèmes qui doivent être résolus rapidement.
  • Il faut de la discipline. Pour effectuer le cycle de ces activités, vous devez comprendre votre ligne de base, ce que signifie réussir et comment vous mesurerez ce succès.
  • Il faut un environnement contrôlé. Pour savoir si ce sont bien vos activités qui ont apporté le succès, vous devez être capables de contrôler l’environnement en effectuant votre pilote. Sinon, cela pourrait être simplement une corrélation d’autres événements et pas la cause de la réussite. Si c’est le cas, déployer ces changements à l’organisation toute entière pourrait ne pas avoir les résultats positifs vous attendez.

En bref

Vous voici prêts avec votre organisation à aller décrocher une étoile.

Le Cycle PDCA ne saurait être une réparation rapide, mais sa structure est facile à comprendre et à communiquer. Il peut être utilisé dans beaucoup de situations différentes et vous permettre de créer une véritable culture d’amélioration continue.

Et une fois que vous l’avez utilisé pour faire des changements réussis dans un secteur, vous chercherez probablement autre part où l’appliquer pour encore plus d’améliorations !