De la culture projet à la culture produit MAIF
•Als PPTX, PDF herunterladen•
0 gefällt mir•1,027 views
Découvrez ce qu'est la culture projet et la culture produit, ce qui les différencie et à travers l'illustration d'un produit fictif à la MAIF, découvrez une mi...
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (11)
Ähnlich wie De la culture projet à la culture produit MAIF
Ähnlich wie De la culture projet à la culture produit MAIF (20)
Mehr von Gregory Alexandre
Mehr von Gregory Alexandre (8)
De la culture projet à la culture produit MAIF
- 1. DE LA CULTURE PROJET A LA CULTURE PRODUIT avec la
- 2. Grégory Alexandre Coach Agile chez Coactiv Agiliste depuis plus de 8 ans @gregalexandre http://www.coactiv.fr @hellocoactiv Viviane Taccori Responsable du Pôle Support Projet à la MAIF En charge de la mise en place d’une démarche Agile à la MAIF
- 3. Un projet Un produit Un produit, désigne le résultat d'une activité humaine sous la forme d'un bien ou d'un service Stricto sensu, un bien est une chose utilisable pour combler un besoin ou un désir Wikipedia On appelle projet un ensemble finalisé d’activités et d’actions entreprises dans le but de répondre à un besoin défini dans des délais fixés et dans la limite d'une enveloppe budgétaire allouée Wikipedia
- 4. IL ÉTAIT UNE FOIS… A la MAIF
- 7. 2 démarches 2 res ultats Aujourd’hui et demain Une démarche produit Avant Une démarche projet
- 8. Lancer Définition du périmètre Définition du budget Définition d’une date Date Cadrer Réaliser Mettre à disposition Le processus projet à la MAIF Revue du budget Revue de la date Revue du périmètre … des fois
- 9. Lancer Cadrer Mettre à disposition Définition du périmètre Définition du budget Définition d’une date Définir la vision Définir le contexte produit Définir l’organisation du projet Partager la vision Comprendre les utilisateurs Récolter, prioriser et estimer les besoins Identifier les solutions, les coûts, les risques et les opportunités Réaliser Des changements dans le processus
- 10. Commanditaire J’exprime mes attentes Pilote J’organise le projet MOA Représentants métier Utilisateurs Je fourni l’EdB CPI Je monte un cahier de solution Fin de cadrage Concepteurs On rédige des specs Contributeurs SI Développeurs Utilisateurs On développe et on livre Jusqu’à présent, comment on s’organisait ?
- 11. Equipe L’équipe élargie Commanditaire PiloteMOA Représentants métier Utilisateurs CPI ContributeursDéveloppeurs concepteurs Coopérent Collaborent Et maintenant on s’organise comment ?
- 12. LE CADRAGE
- 13. Des hypothèses de solution portées par la DSI Un recueil des besoins primordiaux Une expression de besoin Un périmètre Identification des utilisateurs L’analyse de journées types L’identification d’objectifs
- 14. Faire appel aux utilisateurs Ateliers co-localisés Interviews, concertation en visio conférence
- 15. Définition du périmètre cible Définition du budget Définition d’une date Date
- 16. Définition d’une date en fonction de la sortie de l’offre Définition du budget de départ Définition d’un périmètre macroDate
- 17. Vision en 30 secondes POUR : [public concerné par le produit] QUI : [formulation du HU des cibles] QUOI : [ce qu’est le produit] DONT : [le bénéfice majeur, utilité de la solution] CONTRAIREMENT : [pratique actuelle, concurrence] Utilisateurs / clients Sponsors Bénéfices attendus Activités Échéances [date limite de la mise à disposition] Atouts [utilisation possible de l’outil Product Box] Freins / risques [utilisation possible de l’outil Speed Boat] Critères de succès [ce qui permet de dire que le projet/produit est une réussite]
- 18. 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 0.0% 5.0% 10.0% 15.0% 20.0% 25.0% Piloter par la valeur
- 19. Définir la valeur– Impact Mapping 20 000 souscriptions en 6 mois Jérémy Vois facilement Ne demande plus d’aide Infobulles Aide à la saisie Rosette Proposition en 3 clics Ne recommence plus à 0 Carine N’utilise plus Excel Impacte le processus Possibilité de reprioriser les offres Gestionnaires sinitres WHY WHO HOW WHAT
- 20. Cartographie produit et MVP – Story Map Accueillir Proposer Vendre Conclure R3 R1 R2 Voir le nombre de ventes C Saisir de manière simple J Associer au sociétaire J Lister les offres R Gérer le cas extrême R Visualiser une fiche produit R Valider une fiche R Exporter le reporting C R1 Vision en 30 secondes POUR : [public concerné par le produit] QUI : [formulation du HU des cibles] QUOI : [ce qu’est le produit] DONT : [le bénéfice majeur, utilité de la solution] CONTRAIREMENT : [pratique actuelle, concurrence] Utilisateurs / clients Sponsors Bénéfices attendus Activités Échéances [date limite de la mise à disposition] Atouts [utilisation possible de l’outil Product Box] Freins / risques [utilisation possible de l’outil Speed Boat] Critères de succès [cequi permet de dire que le projet/produit est une réussite]
- 21. Définir la valeur– Impact Mapping 20 000 souscriptions en 6 mois Jérémy Vois facilement Ecrans peu chargés Couleurs distinctes Ne demande plus d’aide Infobulles Aide à la saisie Rosette Proposition en 3 clics Liste des offres à l’accueil Liste triée par potentiel Ne recommence plus à 0 Sauvegarde en brouillon Gestion d’historique Carine N’utilise plus Excel Export de reporting Manipulation des données Impacte le processus Possibilité de reprioriser les offres Acteur gestion sinitres WHY WHO HOW WHAT
- 22. Plan projet et specs 8 mois 400 JH Fin septembre 2600 JH 31 septembre Date fixée par le plan projet Date fixée par la mise en marché Liste priorisée de besoins Estimation et projection sur les versions
- 23. Trottis Budget, date et périmètre calé Gère plus de 30 cas d’usage de trottinette à assurer
- 24. Trottis Identification d’un MVP Répond aux 10 cas client les plus récurrents Objectif Trouver une offre en 3 clics Trottis
- 25. LA RÉALISATION
- 26. Des ressources moins cher et ajustable Une équipe performante, collaborative et challengeante L’équipe
- 27. Gestion des orientations produit Hier : Vérification de l’avancement du produit Parties prenantesDocumentation Produit Utilisateurs A LA FIN
- 28. Validation de la conformité au plan Gestion des orientations produit 1ère étape : Démonstration du produit aux personnes liées au projet Démo 2 semaines Parties prenantes
- 29. Gestion des orientations produit Objectif : Revue testable avec des utilisateurs Utilisateurs Parties prenantes 2 semaines
- 30. 520 JH investis Mi mars 2014 L’accompagnement au changement a commencé Mise à disposition d’un MVP Trottis pro Trottis enfants Tro
- 31. Trottis pro Trottis enfants Tro 50 JH Prise en compte des feedbacks et réinvestissement
- 32. Fin du projet 5 semaines de retard 3000 JH 2j de retard 2400 JH Respect du périmètre Un produit adapté Renforcement de l’équipe
- 33. ET ENSUITE ?
- 34. 30 cas livrés, 18 cas utilisés 3 mois d’accompagnement au changement Des déphasages par rapport au quotidien des conseillers 19 cas prévus, 18 utilisés Accompagnement au fil de l’eau, pas de dispositif de déploiement important En adéquation avec leur pratique, gestion adaptée au quotidien des conseillers Février 2015 pour Trottis Trottis pro Trottis enfants Trottis ------------ ----------- - ______ ________ -------- ------- ------- ------- ------- ------- ------- ------- -------
- 36. L’équipe de maintenance avec l’équipe de développement Responsabilisation Continue la gestion des versions Corrige ses anomalies Trottis pro Trottis enfants Trottis ------------ ----------- - ______ ________ --------
- 37. LA CULTURE PRODUIT C’EST
- 38. Un produit tiré du besoin utilisateur et du marché Une solution portée par le centre de réalisation ou la DSI Démo Une revue permettant d'obtenir du feedback Une démonstration de l'avancement du produit + - + - + - + - Equipe performante, solitaire et interchangeable Un produit émergent Le suivi d'un plan Une équipe soudée, engagée et sensibilisée PRODUIT PROJET
- 39. Autonomy, Mastery & Purpose Daniel Pink Ressources
- 40. Questions ?
Hinweis der Redaktion
- Bonjour et bienvenue à la session DE LA CULTURE PROJET A LA CULTURE PRODUIT avec la MAIF Nous n’allons pas faire un retour d’expérience de la MAIF, nous allons illustrer nos concepts avec la MAIF c’est pourquoi ça ne s’appelle pas «… à la maif »
- Greg Lire juste et pointer la distinction
- Viviane Il était une fois à la MAIF … nous allons vous raconter l’histoire d’un projet qui s’est passé à la MAIF
- Viviane Il était une fois « Un nouveau besoin », le besoin exprimé par la Direction commerciale était de créer un outil commercial performant pour vendre un nouveau produit d’ assurance dans nos délégations
- Viviane Ce nouveau produit c’est Trottis, c’est un produit qui couvre l’usage d’une trottinette, vous comprenez bien que cette offre est totalement fictive mais qu’elle va nous servir d’exemple pour la présentation, Trottis devait être mis sur le marché le 1er novembre 2014
- Greg Nous allons étudier ce nouveau projet sous deux démarches et les comparer entre elles, qu’est-ce qui distingue une démarche projet telle qu’existante en partie dans les grandes entreprises type MAIF et une démarche produit vers laquelle l’entreprise tente d’aller
- Viviane Décrire le cycle projet : Lancer / cadrer /réaliser / MAD Souvent comme on cadre tout de manière prédictive, il devient difficile d’en enlever et on veut tout garder ce qui nécessite assez régulièrement de revoir à la hausse le budget ou de repousser les délais, le périmètre est revu exceptionnellement et souvent la révision est subie faut d’argent ou de temps
- Viviane Comment s’organisait un projet en mode classique : Commanditaire exprime les attentes au pilote qui va monter son organisation projet. La MOA prend le sujet et travaille avec des représentants qui, potentiellement peuvent faire appel aux utilisateurs La MOA fourni l’expression de besoin au CPI, le CPI travaille avec des architectes pour concevoir une solution, une fois le cadrage arbitré sur la totalité du périmètre, les concepteurs réalises les specifications sur la totalité du périmètre, les développeurs codent selon les specs et livrent la solution qui mis à dispo des utilisateurs après des recettes globales Comme vous le voyez, ce processus est très séquentiel, chacun adresse un livrable à une autre personne (commande d’un client) et l’autre réalise (fournisseur) relation client/fournisseur Les utilisateurs sont quasi inexistants dans ce dispositif, ils peuvent consulter au début et ils réceptionnent le produit à la fin sans ne l’avoir jamais vu (sauf en accompagnement), Entre ces deux moments, il peut se passer de nombreux mois
- Viviane Comment s’organisait un projet en mode classique : Commanditaire exprime les attentes au pilote qui va monter son organisation projet. La MOA prend le sujet et travaille avec des représentants qui, potentiellement peuvent faire appel aux utilisateurs La MOA fourni l’expression de besoin au CPI, le CPI travaille avec des architectes pour concevoir une solution, une fois le cadrage arbitré sur la totalité du périmètre, les concepteurs réalises les specifications sur la totalité du périmètre, les développeurs codent selon les specs et livrent la solution qui mis à dispo des utilisateurs après des recettes globales Comme vous le voyez, ce processus est très séquentiel, chacun adresse un livrable à une autre personne (commande d’un client) et l’autre réalise (fournisseur) relation client/fournisseur Les utilisateurs sont quasi inexistants dans ce dispositif, ils peuvent consulter au début et ils réceptionnent le produit à la fin sans ne l’avoir jamais vu (sauf en accompagnement), Entre ces deux moments, il peut se passer de nombreux mois
- Viviane Dans une organisation agile oriénté produit, on supprime les silots et le séquencement entre acteurs, on rassemble les acteurs dans une équipe et on les regroupe de préférence dans un même lieu (plateau projet) ce qui crée une dynamique collective, des échanges, du challenge, un esprit d’équipe, un niveau d’information constant pour tous, une vision partagée , etc
- Viviane (partie de gauche) Jusqu’à présent dans une démarche de gestion de projet classique, dès le lancement du projet, la DSI demandait une expression des besoins fonctionnelle exhaustive aux MOAs pour identifier la portée du périmètre fonctionnel et applicatif et pour identifier les impacts et chercher comment intégrer ce nouveau produit dans le processus de vente existant. A partir des besoins émis par la MOA, la DSI proposait une solution que laquelle elle avait estimée le coût et la durée de réalisation alors que les utilisateurs finaux n’avaient toujours pas été consultés Greg : droite
- Viviane La consultation des utilisateurs finaux n’est pas simple à organiser quand vous avez un réseau de vente ou de gestion éclaté au 4 coins de la France, il faut donc trouver des moyens de contact et d’échange pour organiser des rendez-vous à distance (webex, conf cal, etc) ou des échanges en en présentiel sur des sites éloignées ou au siège… Il est indispensable et important d’impliquer les utilisateurs finaux car ce sont eux qui réalisent les activités et qui connaissent le mieux le processus métier (cf. le premier slide avec journée type) Créer une dynamique collective de co-construction avec les utilisateurs est un facteur majeur de satisfaction et de réussite d’un projet Dans le cadre d’une nouvelle offre, on peut également impliqué les sociétaires dans une démarche de co-création dès la conception de l’offre
- Greg Revenir à la def projet : repondre au besoin, date définit, coût fixé. Triangle de fer, quand une contrainte bouge, les autres aussi Réalité le périmètre ne bouge pas car si on ne fait pas tout, le produit n’a pas de valeur
- Greg En gestion de produit, on étudie ce triangle Il s’avère qu’on est dans le scénario le moins prédictible On inverse le triangle, contrôle budget et date définie par le marché, périmètre évolutif Comment s’assurer que dans un périmètre mouvant, on fait les bonnes choses ?
- Greg Pour approfondir le contexte et l’objectif, définition de la vision, utilisateurs types et hypothèse du business model ----- Notes de la réunion (09/06/15 12:34) ----- Retravailler cette slide Tout ce qui est fait ici a pour objectif de fournir le plus de valeur possible aux utilisateurs et c'est globalement l'objectif de la culture produit
- Viviane Comme le précisait Grégory, la culture produit c’est apporter de la valeur aux utilisateurs, il s’agit donc de maximiser la valeur métier et de délivrer aux utilisateurs ou aux sociétaires ce qui apporte le plus de valeur, le plus rapidement Ainsi plus la valeur d’un élément ou d’une fonctionnalit est importante, plus sa priorité est élevée et, comme la priorité définit l'ordre dans lequel les éléments produit sont réalisés, les éléments avec le plus de valeur sont développés en premier. Nous parlons de Valeur, mais c’est quoi la valeur ? ? C’est une notion qui peut sembler flou ! » la valeur, ça veut tout dire et rien dire tout dépend des attendus, on peut apporter de la valeur financière à une entreprise mais aussi de la valeur d’usage ou d’utilité à un utilisateur ou de la productivité, ou de l’ergonomie, etc, Comment peut on les mettre en balance ? Pour définir tout ça il y a des outils (diapo suivant par Greg) Et comment peut on les mesurer ? On vous en reparle un peu plus tard
- Greg Outil d’aide à la décision Etude des impacts d’une fonctionnalité sur un objectif de valeur
- Greg Evoluer tout au long du projet
- Greg Outil d’aide à la décision Etude des impacts d’une fonctionnalité sur un objectif de valeur
- Viviane Du côté orange, le projet est piloté en suivant scrupuleusement le plan projet : Durée de réalisation prévue sur 8 mois, le contenu correspond à ce qui a été prédit et on « embarque » toutes les fonctionnalités La date de fin de réalisation Fin septembre est planifié selon les travaux à réaliser et en considérant qu’il faut garder du temps pour les recettes, les corrections, l’intégration et l’ accompagnement au changement des utilisateurs…. Le coût global du projet est estimé à 2600 JH De l’autre côté, le projet est piloté par la valeur c’est-à-dire avec un objectif prioritaire qui est de réaliser un produit minimum viable qui délivre rapidement des fonctionnalités vitales qui apportent de la valeur métier (valeur d’usage/utilité), Dans l’approche produit, un 1er investissement de départ est estimé à 400 jh, le budget correspond au produit minimum, il permet de livrer la première version du produit et la liste des fonctionnalités priorisées par les métiers et d’aller chercher leur feedback En fonction du budget et du temps restant, ce produit minimal pourra être complété ou ajusté pour ajouter de la valeur au MVP si besoin (prise en compte de feedback, de changements, d’imprévus…) jusqu’au 31 septembre Est-ce un problème si le produit coûte moins cher que le budget accordé ?
- Greg Quand on a définit les 3 points du cadre, roadmap produit de A à Z
- Greg Evoluer tout au long du projet
- Greg Quelles sont les différences entre une équipe projet et une équipe produit ? Pour maximiser la rentabilité, l’équipe projet a préféré faire appel à une équipe constituée d’un sénior et de juniors. L’équipe fonctionnait en Scrum avec un tableau de suivi et un burndown chart et s’assignait les tâches. L’équipe confirmait ou non le carnet d’itération prévu au planning via un chiffrage. De son côté, l’équipe produit a mis beaucoup d’importance dans la meilleure équipe possible. La meilleure équipe pour l’équipe produit, c’est une équipe performante, on veut quand même que ça envoi du pâté hein mais aussi une équipe engagée dans le produit, qui comprenne le besoin et challenge le Product Owner pour lui proposer la meilleure solution. Après tout comme l’équipe projet, l’équipe a produit son management visuel et ses indicateurs Ca prend du temps : C’est sur, la question à se poser c’est de savoir si vous allez le gagner derrière. Avoir une équipe comme celle ci peut permettre de décharger les concepteurs fonctionnels qui, avant devaient arriver la meilleure solution fonctionnelle, l’équipe s’occupant de produire le plus vite possible et avec la meilleure qualité en espérant déjà que ce soit faisable. Je ne peux pas me passer de cet expert : Il arrive que lors de la constituion de votre équipe, vous preniez un constructeur ultra performant mais incapable de travailler en équipe. Pour créer la meilleure équipe produit possible, il faut savoir se passer d’une personne pour sauvegarder la dynamique d’équipe afin de bénéficier des avantages du collectif.
- Viviane Classiquement dans la plupart des grandes entreprises non agiles, on réalise beaucoup de documentation. Cette documentation est souvent appelée livrable (EDB, dossier de solution, stratégie de recette, dossier de cadrage, spec, etc), Ces livrables finalisent des étapes du projet et servent à suivre l’avancement du projet et surtout à valider ou à contractualiser la suite. Tout le cycle projet est ponctué par la livraison de documentation et c’est qu’à la toute fin qu’on livre le produit et que les utilisateurs le voient
- GREG Toutes les deux semaines, l’équipe projet réalisait une démo de leur produit aux acteurs du projet (commerciaux, marketing…) l’objectif était de présenter le produit pour créer une dynamique positif autour du travail réaliser et de rassurer les parties prenantes plus ou moins éloignées de l’opérationnel. L’objectif de la cérémonie était de bien valider ensemble la conformité du produit par rapport au plan défini dans la roadmap et le cahier de besoin.
- Greg « Mais je ne vais pas faire essayer un produit non fini ! » c’est une grande crainte des équipes, montrer un travail en cours, risquer d’être critiqués en montrant un brouillon. Une grande croyance est de penser que les utilisateurs sont incapables de se projeter. Pour rappel, lorsqu’on construit un produit en agile, tout ce qui est produit est sensé être fonctionnel. Soyez pédagogues, présentez la démarche auprès des métiers, des utilisateurs et désamorcez leur incompréhension de devoir faire un retour sur quelque chose en cours. « Et s’ils veulent tout changer ?» vous avez normalement construit le plan initial avec eux, vous avez étudié leurs besoins en amont et vous construisez au fur et à mesure. Il y aura des changements c’est sur mais s’il advient que les utilisateurs décident que ce que vous leur montrez est à refaire à 0 c’est qu’il faut repenser votre analyse utilisateur. Quoiqu’il en soit, le produit n’est pas dans le marché. Plus tôt vous remontez les problèmes plus vous serez en capacité de réagir.
- Viviane La mise à disposition du MVP arrive, le MVP est livré après 3 mois de réalisation, l’équipe a pu finaliser son MVP et le proposer en bêta test à un panel d’utilisateurs de confiance Ainsi bout de 3 mois, pour un investissement de 520 jh, l’équipe a été en capacité de livrer les fonctionnalités prioritaires, de prendre en compte des changements d’où l’investissement plus important et surtout le produit est présenté aux utilisateurs et l’accompagnement peut également commencé
- Viviane La mise à disposition du MVP aux utilisateurs a permis de prendre en compte leur retour et de réinvestir sur le produit
- Viviane Ca y est, les deux produits sont sortis, c’est l’heure de faire un bilan : l’équipe du mode projet est satisfaite car les engagements sont quasiment respecté, seulement 1 mois ½ de retard alors qu’il y a eu pas mal de problèmes et de perturbation, coût est un peu supérieur mais le principal c’est que le plan projet soit respecté et que le produit sorte, avec un bon niveau de qualité L’équipe du mode produit est également très satisfaite, et, le produit est totalement adapté aux besoins des utilisateurs car les changements demandés ont été intégré au fur et à mesure, la date a été décalée de 2 jours et au final le budget est de 2400 jh mais le résultat apporte tellement de satisfaction et de valeur aux utilisateurs que le projet est une véritable réussite.
- Viviane
- Greg Après la fin du projet, la Bananache est allé au mains de l’équipe maintenance qui a dû gérer les anomalies restantes en attendant un nouveau projet d’évolution.
- Greg De son côté, la BananaQueen est restée aux mains de l’équipe qui l’avait créé, le projet est peut être terminé mais le produit continue de vivre. C’est le produit de l’équipe qui continue sa gestion, corrige ses anomalies et crée de nouvelles évolutions tous les jours en attendant la prochaine release.
- Greg
- Greg