De la culture projet à la culture produit V2
•Télécharger en tant que PPTX, PDF•
1 j'aime•795 vues
De la culture projet à la culture produit V2 La notion de culture produit est de plus en plus présente dans l'entreprise, surtout dans la mise en place de l'agilité. Elle est souvent mise en opposition avec la culture projet. Cette présentation a pour but de présenter ce qu'est la culture produit, la comparer avec l'approche projet, voir quels outils utiliser et les obstacles rencontrés lorsqu'on veut mettre en place une culture produit. Cette présentation sera illustrée via l'entreprise BananaCorp. créatrice de la BananaBounce
Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (20)
Similaire à De la culture projet à la culture produit V2
Similaire à De la culture projet à la culture produit V2 (20)
Plus de Goood!
Plus de Goood! (16)
De la culture projet à la culture produit V2
- 1. DE LA CULTURE PROJET A LA CULTURE PRODUIT avec des
- 2. Grégory Alexandre Coach Agile Coactiv @gregalexandre http://www.coactiv.fr Paris, Aix Marseilles @hellocoactiv
- 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… L’entreprise BananaCorp. Créatrice de…
- 5. BananaBounce La banane qui rebondit Son successeur est sorti cet été voici son histoire…
- 6. OCTOBRE 2013 UN NOUVEAU PRODUIT
- 7. Une idée
- 8. 2 équipes 2 démarches 2 produits Une équipe projet Une équipe produit
- 9. LE CADRAGE
- 10. Expression de besoin et périmètre Etude de marché, clients et concurrence
- 12. Définition du périmètre cible Définition du budget Date Définition d’une date
- 13. Roadmap 8 mois Bananache
- 14. Date Scénario le moins prédictible
- 15. Définition du budget de départ Définition d’une date au 31 mai Définition d’un périmètre macro Date
- 16. 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Piloter par la valeur 25.0% 20.0% 15.0% 10.0% 5.0% 0.0%
- 17. 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Piloter par la valeur 25.0% 20.0% 15.0% 10.0% 5.0% 0.0%
- 18. Définir la valeur– Impact Mapping WHY WHO HOW WHAT
- 19. Définir la valeur– Impact Mapping WHY WHO HOW WHAT
- 20. Cartographie produit et MVP – Story Map
- 21. 8 mois 250k€ 2 semaines Juin 400k€
- 22. LA RÉALISATION
- 23. Des ressources moins cher et ajustable Une équipe performante, collaborative et challengeante L’équipe
- 24. Des ressources moins cher et ajustable Une équipe performante, collaborative et challengeante L’équipe
- 25. Démonstration du produit aux personnes liées au projet Validation de la conformité au plan Démo 2 semaines Parties prenantes
- 26. Une revue testable avec des personnes diverses Autres personnes Parties prenantes 2 semaines
- 27. Une revue testable avec des personnes diverses Autres personnes Parties prenantes 2 semaines
- 28. Un prototype
- 29. 280k€ investis Beta Test du MVP de laBananaQueen Début janvier 2014 On parle de nous La banane qui couine
- 30. Prise en compte des feedbacks et réinvestissement 10k€
- 31. Début avril 2014 350k€ Un plan suivi à la lettre sans perturbation marketing Ajustement à la demande On voit le produit et on en parle Renforcement de l’équipe 400k€
- 32. Fonctionnalité inattendue du produit de FraiseCorp. Ajustement de la liste des fonctionnalités Changement du marché
- 33. Fin du projet 5 semaines de retard 510k€ 2j de retard 550k€ 4j d’avance sur la concurrence Respect du périmètre Un produit adapté
- 34. Fin du projet 5 semaines de retard 510k€ 2j de retard 550k€ 4j d’avance sur la concurrence Respect du périmètre Un produit adapté
- 35. ET ENSUITE ?
- 36. Equipe de maintenance - Anomalies - Potentielles demandes d’évolutions
- 37. La même équipe Continue la gestion des versions Corrige ses anomalies
- 38. Septembre 2014 20 000 utilisateurs 165 000 utilisateurs
- 39. LA CULTURE PRODUIT C’EST
- 40. PRODUIT PROJET Un produit tiré du besoin utilisateur et du marché Une solution portée par le centre de réalisation ou la DSI Une revue permettant Démo d'obtenir du feedback Une démonstration de l'avancement du produit + - + - + - + - Equipe performante, solitaire et interchangeable Une équipe soudée, engagée et sensibilisée Un produit émergent Le suivi d'un plan
- 41. Nouvelle BananaQueen 27 NOV.
- 42. Nouvelle BananaQueen 27 NOV.
- 43. Autonomy, Mastery & Purpose Daniel Pink Ressources
- 44. Questions ?
Notes de l'éditeur
- Démarche projet :
- L’idée de départ est de faire une bananabounce qui émet un son lorsqu’elle rebondit
- Continuer illustrer avec 2 équipes qui font chacune leur produit Comparer les démarches
- Mode projet : direction service réalisation prend le lead Sait comment faire, demande une expression de besoin et challenge rapidement en fonction de la faisabilité But : Sortir vite un périmètre
- Pour approfondir le contexte et l’objectif, définition de la vision, utilisateurs types et hypothèse du business model
- 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
- Quand on a définit les 3 points du cadre, roadmap produit de A à Z
- 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 ?
- 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 ?
- Partant de ce constat, ils ont décidé que chaque fonctionnalité du nouveau produit serait mis en balance en fonction de la valeur produit. « C’est quoi la valeur ? C’est flou ! » c’est vrai, la valeur, ça veut tout dire et rien dire : bénéfices directs, nombre d’utilisateurs, adhésion et comment les mettre elles aussi en balance ? Pour définir tout ça il y a des outils. Et comment on la mesure ? Je vous en reparle un peu plus tard
- Partant de ce constat, ils ont décidé que chaque fonctionnalité du nouveau produit serait mis en balance en fonction de la valeur produit. « C’est quoi la valeur ? C’est flou ! » c’est vrai, la valeur, ça veut tout dire et rien dire : bénéfices directs, nombre d’utilisateurs, adhésion et comment les mettre elles aussi en balance ? Pour définir tout ça il y a des outils. Et comment on la mesure ? Je vous en reparle un peu plus tard
- Outil d’aide à la décision Etude des impacts d’une fonctionnalité sur un objectif de valeur
- Outil d’aide à la décision Etude des impacts d’une fonctionnalité sur un objectif de valeur
- Evoluer tout au long du projet
- La phase de cadrage est maintenant terminée ! Enfin ! Voici un petit récap’ et des différences majeures d’une équipe à l’autre. L’équipe projet, guidée par la direction de réalisation, a privilégié la construction d’une roadmap sur 6 mois pour un coût de 400k€ et une sortie courant juin. De son côté, l’équipe produit, après avoir longtemps analysé le marché, a défini via un MVP un périmètre initial et a débloqué un budget de 250k€ pour une date au 31 mai soit 7j avant la sortie du produit de FraiseCorp. L’agilité était déjà ancrée chez BananaCorp. Les deux équipes ont ensuite décidé de produire en Scrum avec un cycle de 2 semaines.
- 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.
- 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.
- 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.
- De son côté, l’équipe produit réalisait une revue d’itération, sensiblement différente. En pratique, l’équipe invitait des acteurs attachés au projet et des personnes de l’entreprise principalement identifiées non pas comme étant des personnes de l’entreprise mais comme étant des utilisateurs comme vous et moi. Ces personnes étaient invitées à utiliser le produit en l’état afin de faire leurs retours. L’objectif était de récupérer le maximum de feedback pour réajuster le backlog produit par la suite. « 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. Une banane qui ne rebondit pas est toujours une banane, une banane qui ne fait pas de son est toujours une banane. Soyez pédagogues, présenter 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écide 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 les rayons plus tôt vous remontez les problèmes plus vous serez en capacité de réagir.
- De son côté, l’équipe produit réalisait une revue d’itération, sensiblement différente. En pratique, l’équipe invitait des acteurs attachés au projet et des personnes de l’entreprise principalement identifiées non pas comme étant des personnes de l’entreprise mais comme étant des utilisateurs comme vous et moi. Ces personnes étaient invitées à utiliser le produit en l’état afin de faire leurs retours. L’objectif était de récupérer le maximum de feedback pour réajuster le backlog produit par la suite. « 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. Une banane qui ne rebondit pas est toujours une banane, une banane qui ne fait pas de son est toujours une banane. Soyez pédagogues, présenter 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écide 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 les rayons plus tôt vous remontez les problèmes plus vous serez en capacité de réagir.
- Arrivé à un certain stade de la réalisation, assez tôt dans le projet 3 semaines de réalisation je crois, l’équipe produit a désiré réaliser un prototype. L’objectif : valider des hypothèses en proposant à un panel d’utilisateur 2 versions du produit afin que le choix soit fait par les potentiels futurs acheteurs. L’équipe s’est attelée à produire à l’aide d’une imprimante 3D les 2 modèles L’équipe produit avait proposé un modèle avec une couronne « la BananaQueen » et une autre avec une texture d’ananas « La banananas ». Il s’est avéré que la prise en main de la bananas n’était pas très agréable et que l’aspect royal plaisait beaucoup aux enfants. La première hypothèse était validée, l’équipe savait qu’un modèle « bananaqueen » saurait trouver son public.
- Au bout de 3 mois de réalisation a terminé son MVP, l’équipe produit a pu finaliser son MVP et le proposer en bêta test à un panel d’utilisateurs de confiance (anciens client et un jeu concours). L’équipe a livré 100 bananes à utiliser pendant 1 mois. Au bout de 3 mois, pour un investissement de 180k, l’équipe produit était en capacité de proposer à l’utilisation une banane fonctionnelle et de faire parler du produit auprès d’un potentiel futur public.
- Pendant la bêta du produit, les utilisateurs ont remonté qu’après un peu plus d’1 semaine d’utilisation normale, le son s’arrêtait. ¼ des utilisateur ont aussi remonté qu’ils auraient aimé avoir un son animalier qui manquait cruellement au produit qu’on leur avait prêté. L’équipe produit a donc demandé un réinvestissement de 10k€ pour corriger le problème technique et pousser la recherche d’un nouveau son
- Faisons un point de l’avancement des deux équipes : L’équipe projet a dû renforcer l’équipe avec deux juniors afin de rattraper le retard causé par un gros problème technique sur l’enceinte utilisée dans le boitier son. Cela a nécessité une rallonge de 50k€ montant le coût du projet à 450k€. Le plan continue à être déroulé dans le bon sens et validé au fur et à mesure. Elle réussi à avancer en se protégeant des perturbations du marketing qui remettraient en cause ce qui a été fait. De son côté, l’équipe produit ,grâce à ses revues et son bêta test réussi à réajuster son produit, cela lui demande plus d’effort mais pour au final créer un produit visible et utilisable dont les gens parlent.
- Ca y est, les deux produits sont sortis, c’est l’heure de faire un bilan : Le projet de l’équipe projet est un réel succès, seulement 1 mois ½ de retard par rapport aux problèmes rencontrés, pour un coût un peu supérieur mais le principal est que le produit est sorti, avec un bon niveau de qualité et que l’équipe a réussi à ne pas être perturbée par le service marketing. Le projet de l’équipe produit est aussi un succès, si, malgré qu’elle ai voulu fixer la date elle a du décaler de plusieurs jours, le résultat est que la BananaQueen est sortie avant le produit de FraiseCorp. Le coût au final est supérieur aux prévisions (on ne parle pas des 250k qui étaient pour le MVP) mais l’équipe a créé un produit totalement adapté au marché et a déjà confirmer qu’il y avait des acheteurs.
- Ca y est, les deux produits sont sortis, c’est l’heure de faire un bilan : Le projet de l’équipe projet est un réel succès, seulement 1 mois ½ de retard par rapport aux problèmes rencontrés, pour un coût un peu supérieur mais le principal est que le produit est sorti, avec un bon niveau de qualité et que l’équipe a réussi à ne pas être perturbée par le service marketing. Le projet de l’équipe produit est aussi un succès, si, malgré qu’elle ai voulu fixer la date elle a du décaler de plusieurs jours, le résultat est que la BananaQueen est sortie avant le produit de FraiseCorp. Le coût au final est supérieur aux prévisions (on ne parle pas des 250k qui étaient pour le MVP) mais l’équipe a créé un produit totalement adapté au marché et a déjà confirmer qu’il y avait des acheteurs.
- 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.
- 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.