Speaker #0Aujourd'hui on s'attaque au Product Management et au pont que l'on peut faire pour gérer des projets de manière plus efficace avec le livre Shape Up. Salut à tous et bienvenue dans le potre reste, la source. Moi c'est Franck et je suis un passionné de lecture. Je suis toujours à la recherche du bon bouquin, je suis toujours à la recherche du bon article, du dernier livre qui va pouvoir m'aider dans mon quotidien, qu'il soit professionnel. ou qu'il soit personnel. Et parce qu'on n'a pas le temps de tout lire, parce qu'on n'a pas besoin de rien de tellement. On a besoin de limiter le nombre de lectures qu'on fait. On a besoin de se reposer sur un nombre de ressources qui sont fixes et qu'on va reviviter dans le temps. Le but, c'est de remonter à la sauce, de trouver les 20 livres, 20 livres de référence pour être meilleur professionnellement, être meilleur personnellement, mentalement, physiquement. Alors bienvenue dans cette aventure, bienvenue dans la source. Très content de recommencer la série de la source après quelques semaines de pause pendant les vacances. J'espère que vous êtes bien reposés. Aujourd'hui on va recommencer avec un livre que j'adore, un livre que j'ai lu il y a très longtemps et que j'ai relu récemment, qui s'appelle Shape Up. La particularité de ce livre c'est qu'il est disponible en ligne, que vous pouvez... Vous pouvez donc le lire sur basecamp.com slash shapeup. Il y a l'ensemble du livre qui est disponible. Vous pouvez même, si vous le souhaitez aussi, l'acheter. Il est vendu au prix de 26,95 euros directement sur le site de Basecamp. Franchement, je pense que c'est un livre qui est vraiment clé si on veut faire du product management. Et d'ailleurs, comme vous le savez, moi j'adore les ponts et la... Les liens qu'il peut y avoir entre différents domaines, ShapeUp est aussi possible, enfin en tout cas est aussi utilisable sur de la gestion de projet plus classique et on va voir comment ça se décline. Alors ShapeUp c'est quoi ? ShapeUp c'est le livre qui a été écrit par Ryan Singer. Ryan Singer il fait partie de l'équipe fondatrice de Basecamp, c'est un outil que vous avez peut-être déjà rencontré et déjà connu. C'est un outil de gestion de projet, principalement pour des projets de petites équipes et qui permet de faciliter la collaboration. L'équipe fondatrice autour de Basecamp et de 37signals, c'est Jason Fried, qui est un designer. On a Ryan Singer et on a aussi David Heinemeyer-Hanson. Petite anecdote, c'est lui qui a créé Ruby on Rails, en tout cas Rails. pour la part de langage. Donc en fait, c'est une équipe qui a créé ce logiciel qui favorise, en tout cas pousse, la partie bootstrapping pour justement développer ces entreprises. Alors, 37 Signals, c'est une entreprise qui date de la fin des années 90, ça a été créé en 1999, et le lancement de Basecamp a été fait en 2024, début 2024. avec cette équipe. Je rappelle que Ruby on Rails, qui a été créé par David Heinemeyer-Hanson, c'est un langage qui a alimenté d'autres entreprises, comme par exemple YouTube, Shopify, Airbnb, Twitter, pour les nommer. Donc c'est vraiment un langage fondateur dans la tech et les SaaS. Leur but, ça a été aussi d'être complètement bootstrap. En 2024, ils comptent un revenu de 2 000... 280 millions de dollars revenus annuels, et plus de 250 000 clients. Voilà, et 3 millions d'utilisateurs, donc c'est vraiment une super success story, avec 25 ans de rentabilité consécutive sur ce projet. Concernant ShapeUp, donc ShapeUp, Ryan Singer, qui est aussi un des designers et le head of stratégie et product, lui, il a détailler une méthode de gestion de projet dans ce livre ShapeUp dont je voudrais vous parler aujourd'hui parce qu'elle peut être applicable entièrement déjà au produit et à la tech avec notamment une philosophie qui lui est bien propre, qui change de la vision qu'on peut avoir par tâche, la vision qu'en banque et qui a une approche beaucoup plus axée sur la confiance, la confiance qu'on a envers les équipes, la responsabilisation aussi des projets. qui sont données aux équipes et qui est tournée vers l'efficacité, le delivery et la... l'apport de valeur ou en tout cas le shipping, au défaut d'avoir un meilleur mot, le shipping de valeur pour les produits. Alors, ShapeUp, ça a été publié entièrement gratuitement en 2019. Et la partie du caractère de cible, c'est qu'il est complètement gratuit, puisqu'il est disponible en ligne sur le site dont je vous parlais tout à l'heure. Ça a été une adoption importante des startups européennes et françaises, et le but, ça a été en tout cas de... de mettre une alternative, ou en tout cas de proposer une alternative à la partie Scrum et à la partie agile, avec notamment des options et des alternatives aux stand-up meetings, aux backlogs, et aux équipes qui ont des tâches qui s'empilent et qui ne savent pas quoi en faire, et qui perdent aussi, notamment le lien entre la vision du projet, la vision du produit, et leur exécution quotidienne. Finalement, moi le premier, quand j'ai lancé des initiatives produits, on a envie de faire un backlog, de renseigner toutes les idées qui sont possibles, d'avoir une exécution quotidienne avec des daily stand-up où on parle des tâches du jour. Ici, on prend un contre-pied total. J'ai découvert ce livre il y a quelques années maintenant et je m'en suis servi pour... pour m'inspirer sur la partie produit, je pense que je ne l'ai pas assez exploité, pas assez utilisé, et je voulais vous détailler quelques éléments de la méthode que l'on trouvait dans ce livre. Donc déjà, en le relisant, ça m'a fait un déclic, je me suis dit que l'on pouvait revoir sa manière de gérer les projets, d'être très focus, d'augmenter l'output, en tout cas ce qu'on produit, que ce soit pour la tech, que ce soit pour des actions marketing de contenu, que ce soit pour des projets, tout simplement. Parce que le biais et le prisme par lequel ShapeUp développe sa thèse, c'est de limiter le temps pour lequel on connaît. dédié à des projets, et de maximiser l'exécution dans un intervalle de temps qui est précis, défini. En général, eux, ils parlent de cycles de 6 semaines, pour que ce soit justement assez long pour que le travail ait du sens, pour que le travail ait de l'impact, mais suffisamment court pour gérer les imprévus. pour gérer des points urgents. Le deuxième point dans ces cycles de 6 semaines, c'est qu'on part sur des sprints de 2 semaines. Donc c'est une séquence de 6 semaines. Ces cycles de 6 semaines, ils sont détaillés en 3 phases. La première phase, qui varie entre 1 et 2 semaines, c'est l'exploration, le setup. La deuxième phase, c'est vraiment la construction, l'implémentation. Donc on crée de la valeur. Et les phases 5 et 6, donc les semaines 5 et 6 de sprint, ça va être la finalisation, l'affinage. des solutions que l'on aura développées. Ce qui est intéressant aussi, c'est les principes qui régissent cette théorie. Déjà, le point numéro 1 dans les principes, c'est qu'on va définir un appétit, un temps qu'on a envie de passer sur des projets. Ce qu'ils préconisent dans le livre, c'est d'avoir... entre deux et six semaines d'investissement. Et en fait, c'est ça qui est intéressant dans le biais. On parle maintenant d'investissement, on ne parle pas forcément du coût. Ce qui peut être une pratique commune dans la gestion de produits, la gestion des projets, c'est combien ça coûte. Combien ça va me coûter, comment ça va me coûter. Là, on prend le contre-pied, c'est combien de temps j'ai envie d'investir dans tel ou tel projet. C'est ce qu'ils appellent « setting the appetite » , donc définir son appétit pour le prover. Est-ce que j'ai envie de passer six semaines à développer tel projet, telle feature, ou à l'inverse, est-ce que j'ai plutôt envie d'en passer deux ? Donc on va définir cet appétit et se donner un temps. Et là, pareil, le but, ce n'est pas forcément d'être parfait, mais de se fixer une timeline, de se fixer une deadline. dans laquelle on va réaliser cet objectif et dans laquelle on va réaliser ce projet. Le but, c'est d'avoir un temps fixe et un scope, un périmètre qui peut être variable. Le temps fixe, c'est les cycles de 6 semaines ou des cycles de 2 semaines. L'enjeu. Sur ça, c'est de se créer des frontières et des limites qui sont claires, qui sont vraiment clairement définies, avec comme objectif de trouver les éléments clés pour réaliser le projet et surtout d'avoir en tête aussi que dans les différentes phases du projet, on va pouvoir à tout instant décider de l'arrêter. Le framework. que ShapeUp propose, c'est un framework en 5 phases. La phase numéro 1, c'est la définition du problème. Quel problème je vais résoudre pour mes utilisateurs, pour mes clients en interne ? Quelle est la définition de l'appétit que je vais vouloir y mettre ? Est-ce que c'est quelque chose pour lequel je vais investir 2 semaines, pour lequel je vais investir 6 semaines ? Et ensuite, on commence par définir les solutions. Donc il y a 3 phases. dans la méthodologie shape-up, il y a une phase de recherche, d'exploration, qui sont les deux premières semaines dont je vous parlais tout à l'heure. Il y a une phase d'exécution, il y a une phase de finalisation. Dans la phase d'exploration, ici, on reste sur ces cycles de six semaines assez vague, assez brouillon, on ne va pas faire des wireframes super précis, non, parce qu'en fait dans la méthodologie shape-up, dans ce qui est partagé, ce qui est déterminé, on se dit que plus on va être précis, plus on perd du temps et potentiellement on va être précis pour un projet qui n'en vaut pas la peine. Donc l'enjeu numéro 1, c'est de savoir si déjà le projet en vaut la peine et le projet a un périmètre qui est faisable en la période de 6 semaines. Donc, en récapitulant, on a une phase d'exploration de setup pour générer un pitch. Ce pitch, il doit nous permettre de déterminer le problème, l'appétit qu'on y met, les solutions qui sont, et on le détaillera juste après, qui sont grossièrement définies, on va dire, ce qu'ils appellent les rabbit holes, les trous noirs, ou en tout cas les pertes de temps massives que l'on peut identifier. Ça peut être les risques que l'on va identifier, et ces risques doivent être mitigés directement dans le pitch. Et aussi, en dernier lieu, les no-go, les choses qu'on ne fera pas dans cet intervalle de temps. Une fois... Donc ça, ça fait partie de la première phase. On a une partie de l'équipe produit, par exemple, de la chefferie de projet qui va constituer ce pitch avec les différents stakeholders. Alors, qui sont les stakeholders ? Eh bien, déjà, on a la partie product. qui, en tout cas le chef de projet, donc des business units qui sont différents de celles du product management, qui va être en charge de définir ce pitch avec les différents acteurs. Ce pitch, ensuite, il va être challengé lors de ce qu'ils appellent le betting table. Le betting table, c'est un rituel qui a lieu avant chaque cycle de six semaines qui regroupe plusieurs personnes autour de la table. Et des personnes qui ont un pouvoir de décision, une vision sur les projets et les problématiques. et la capacité de challenger les pitches qui sont mis à disposition. Globalement, c'est un comité qui va prioriser, définir les différents pitches et les différents projets en fonction de ce qu'aura fait le product strategist et des documents qui auront été produits. Autour de cette table, il y aura... Le CEO, donc la personne référente numéro 1 sur l'entreprise, le CTO, référent technique, un programmeur senior, deuxième vision technique, et le product strategist, qui lui rapporte la connaissance client, la connaissance utilisateur. Et avec ces quatre personnes-là, on a un nombre limité de personnes qui sont capables de décider, de prioriser, et de sortir un plan. de cycles. L'objectif donc c'est à partir de ces pitches de sortir un plan des pitches qui sont sélectionnées qui vont être le focus, qui vont être la priorité pour ces cycles de 6 semaines. Alors quelles questions on va se poser lors de ces betting tables, lors de cette instance ? C'est déjà est-ce que le problème a du sens ? Est-ce que vraiment le pitch qu'on présente, est-ce que c'est vraiment un truc qu'on veut résoudre ? L'appétit qu'on a défini est juste. Est-ce qu'on a envie d'investir le temps alloué ? Est-ce qu'on a envie d'investir deux semaines ? Est-ce qu'on a envie d'investir plus ? ils ont envie d'investir moins sur la problématique qui est à résoudre. Est-ce que la solution qui est proposée est attractive ? Attractive pour le client, attractive pour les utilisateurs, attractive pour les différentes parties prenantes qui bénéficient de ce pitch-là. Est-ce que c'est le bon moment de lancer cette initiative ? Ça peut être lié au marché, ça peut être lié à un contexte d'entreprise, un contexte client. Et finalement, est-ce que j'ai les bonnes personnes qui sont disponibles pour... réaliser ce pitch, ce qui n'est pas toujours le cas. Et donc, ces questions-là doivent permettre d'établir un plan et de sélectionner les meilleurs pitchs pour le cycle de 6 semaines sur lequel on va s'accorder. Une fois qu'on a défini, d'après la méthode, le pitch, on parle d'un cycle de 6 semaines. On a un pitch qui est grossier, je reviendrai tout à l'heure sur pourquoi il est grossier. Le but, pour les équipes, et les équipes sont en général constituées. Ce qui est préconisé par la méthode, c'est d'avoir un designer et un ou deux développeurs. Ça c'est une équipe qui réalise un pitch, c'est une équipe projet qui a un cadre défini. Donc on peut avoir un développeur front, un développeur back, on peut avoir juste un développeur full stack et un designer. Dans tous les cas, c'est designer plus développeur qui font l'équipe, qui réalisent le pitch et qui sont focus sur ce cycle de 6 semaines. Pendant ce cycle de 6 semaines, ils vont prendre le pitch et ils vont eux-mêmes explorer les solutions et les tâches qui sont à définir pour ensuite les réaliser et les finaliser. C'est eux, eux seuls, cette équipe projet qui va... prendre la responsabilité du projet et trouver les solutions les plus viables sur le cycle de 6 semaines. Maintenant, qu'est-ce qui se passe à la fin ? Soit on réussit le projet, super, tout le monde est content, mais on peut aussi avoir des projets qui ne sont pas finis dans les temps. C'est-à-dire qu'au bout des 6 semaines, on n'a pas réalisé le projet. Là, la méthode est radicale, le principe est clair, on arrête le projet. Si le projet n'est pas réalisé dans les 6 semaines, on le coupe, on arrête, c'est terminé. on passe à autre chose et on le met de côté pour aujourd'hui. L'avantage de ça, deux choses. Un, on n'a perdu que six semaines. On n'a perdu que six semaines. Et deux, on met une sorte de pression, un challenge pour les personnes qui sont en charge du projet. Maintenant, comment ça se passe si on revient sur les différents principes et les différents éléments ? On rappelle que pendant le pitch, on a dit qu'on a dégrossi le sujet. Il y a trois méthodes qui sont utilisées, en tout cas trois parties qui sont utilisées, ce qu'ils appellent dans le livre de trouver les éléments, puisque la réalisation, l'output du pitch, c'est de trouver les éléments. Il y a deux gros éléments plutôt qui sont utilisés, qui sont un peu dans la lignée du parcours utilisateur et du design, mais du design vraiment grossier. Un, c'est les breadboards. Les breadboards, c'est ce qui... s'apparente à des cartes électroniques grossières. Donc si vous lisez dans le livre, vous allez trouver que c'est globalement un flot d'endroits, ce qu'ils appellent les places, donc les endroits où se trouve l'utilisateur. Par exemple, je vais avoir un endroit qui est la landing page, un endroit qui va être le login, un endroit qui va être peut-être la page profil, un endroit qui va être le dashboard, un endroit qui va être la page de paiement, un endroit qui va être la facture, etc. Et chaque endroit a... une liste de dépendance et une liste d'informations qui lui sont associées. Par exemple, sur l'endroit login, je vais avoir mon prénom, mon nom, mon mail, mon mot de passe, par exemple. Et un bouton qui me dit « Ok, go se loguer » . Le breadboard a pour objectif de définir et de designer le parcours utilisateur sans détail. Donc si je suis à un endroit qui s'appelle login, le login peut être une nouvelle page, peut être une pop-up, peut être... Il y a un tas de choses qui ne sont pas forcément à définir maintenant. Tout ce que je sais, c'est qu'à cet endroit-là, il me faudra un mail, un mot de passe et un bouton pour passer à l'étape suivante. Une fois que le bouton est cliqué, il me permet d'aller à un autre endroit qui peut être mon compte. Et sur mon compte, avoir accès à d'autres dépendances que je vais détailler. L'idée, c'est d'avoir quelque chose de très visuel, d'avoir quelque chose sans design, mais d'avoir un parcours utilisateur qui est défini. Une fois que l'on veut préciser un petit peu le design, ils appellent la deuxième méthode, qui est la méthode au gros marqueur. Donc c'est des esquisses. Ils appellent ça des esquisses au marqueur. Pourquoi ? Parce qu'en fait, on n'a pas besoin de détailler et de s'embêter à faire un design en wireframe très complexe, très défini. Tout simplement parce qu'on perd du temps, parce qu'on met du temps sur un sujet qui peut toujours être débranché. C'est-à-dire qu'ici, on est toujours dans une phase de pitch, on est dans une phase de détermination de la... de la pérennité du ROI de cette solution-là. Le but n'est pas d'avoir des livrables, parce que si on commence à faire des wireframes, à être super précis, et à vouloir montrer qu'on a une solution super chiadée, non, il est possible qu'une semaine plus tard, on dise ce projet, on le kill, parce qu'en fait, il n'a aucun sens, aucun intérêt, et on n'a pas besoin de le faire. Ou alors, il est tout simplement impossible à faire. Donc, on ne passe pas de temps à ce... à s'embêter à faire un design trop complexe, on fait vraiment breadboard et des esquisses grossières. Les esquisses grossières, ça peut être tout simplement... Voilà, si je prends un exemple qui est dans le livre sur un calendrier, l'esquisse, ça va être un espace calendrier dans lequel je vais avoir mes différentes cases liées à mon calendrier. Et si j'ai envie d'avoir des événements, je vais avoir un point sur les jours de mon calendrier qui ont un ou plusieurs événements. Et puis là où il y a des écritures, ou en tout cas des champs de texte, je vais juste le notifier par des petits gribouillis. Et ça, ça suffit pour l'instant. Pourquoi ? Parce que ça donne une direction, ça permet au product, au chef de projet, d'orienter la solution sans... contenir et sans limiter la créativité d'un designer qui pourrait arriver derrière, et aussi en laissant de l'adaptabilité. Parce que derrière, une fois que le pitch est validé, souvent on va se rendre compte que les tâches qu'on avait prévues, le beau plan qu'on avait fait, il y a de nouvelles tâches qui arrivent, des découvertes que l'on fait au fil du projet. Et c'est tout à fait normal, il faut pouvoir l'utiliser et s'adapter. Pourquoi ? Parce qu'on rappelle qu'un des principes de la méthode, c'est d'avoir un temps limité, mais un scope, un périmètre qui est variable. Et le périmètre variable, c'est s'il y a des nouvelles tâches qui arrivent, si je découvre des choses, je vais les intégrer dans mon scope, puisque mon objectif, c'est justement de délivrer dans le temps un parti. Donc le principe, c'est de trouver ces éléments, ces éléments clés à partir des breadboards et des esquisses, pour pouvoir honorer le pari que l'on fait. On fait un pari qu'en X semaines, 6 semaines, 2 semaines, si c'est des projets plus courts, et on peut batcher plusieurs projets de 2 semaines dans un projet de 6 semaines, pour garder des cycles complets, on va réaliser ce pari. Ensuite, on assigne ce projet. On n'assigne pas des tâches, il n'y a pas vraiment un CTO qui va découper les tâches et dire que c'est l'équipe projet designer plus... plus les développeurs qui vont faire les tâches, ils vont organiser leurs projets. Et le but, c'est d'organiser les projets, ce qu'ils appellent l'organisation par structure et pas par people. Par structure, c'est-à-dire qu'au lieu d'avoir une liste de tâches pour le front, une liste de tâches pour le back, on va avoir un périmètre complet que l'on va découper en scope, structure, et on va attaquer structure par structure avec le front. le bac et le design. Pourquoi on fait ça ? Parce que ça permet d'avoir une synchronisation entre les différentes personnes qui vont produire l'application et de montrer du progrès. Puisque c'est un des points importants, on peut très bien avoir en quelques jours la structure numéro 1 et on peut passer à la structure numéro 2. Et la structure numéro 2, on l'attaque de la manière front, back, designer, ou full stack et designer pour avancer. Et petit à petit, on va grappiller les différents périmètres, les différentes structures, les différentes parties du projet ou de l'application que l'on aura déterminée, que l'équipe projet aura elle-même déterminée pour montrer justement le progrès qu'elle a. Pour montrer le progrès, un point intéressant, c'est ce qu'ils appellent le chart. le Hill Chart, le Chart Colline, qui récapitule, au lieu d'avoir une liste de tâches et combien de pourcents j'ai réalisé sur cette tâche, etc. Non, eux, ils partent de trois étapes. Un, je décricote les choses, j'essaie de trouver les solutions, j'essaie de comprendre un peu le problème auquel je m'attache. Deux, c'est le aha moment, donc le eureka, j'ai trouvé la solution et je sais comment faire. Et le trois, c'est la phase descendante qui est je délivre. je produis. Et donc, chaque tâche, chaque structure passe dans ces différentes phases et va suivre ce diagramme colline, et c'est avec ce diagramme colline que l'on peut même faire du reporting. J'ai un certain nombre de tâches qui se trouvent au début de mon projet dans le figuring out. Plus j'avance, plus j'ai de tâches qui arrivent. dans le aha moment et qui sont en train d'être réalisés. Et si j'ai des tâches qui sont bloquées à un endroit, je sais que je peux prendre un moment pour identifier les solutions. Est-ce que c'est un point bloquant qui a un risque de décaler, d'annuler mon sprint ? Est-ce que c'est une tâche dont je peux me passer pour réaliser la structure ou non ? Ce diagramme, il est... de pratique et il change surtout des différentes visions qu'on peut avoir dans la gestion de projet classique. Donc c'est que j'ai un pourcentage d'avancement en fonction des tâches que j'ai planifiées, mais on sait que ces tâches, souvent, surtout en early stage et sur des projets qui sont, on va dire, d'innovation, on a de nouvelles tâches qui apparaissent et on n'est jamais 100% sûr d'avoir... d'avoir l'ensemble des tâches au démarrage du projet, parce qu'on ne va pas passer non plus... Le but, c'est de délivrer de la valeur, d'avancer, de découvrir des choses. On ne va pas passer des semaines à définir un projet et mal le définir. Le but, c'est de sortir des choses. En résumé, il y a dans ce livre beaucoup, beaucoup de matière. Elle est principalement adressée par le prisme du product, de la tech. Il n'y a pas forcément de... de limitation, pouvoir l'utiliser dans d'autres aspects. Les enjeux essentiels, c'est d'avoir des cycles de 6 semaines, d'avoir une structure temporelle qui comprend dans ces cycles de 6 semaines l'exécution, et dans l'exécution, il y a une partie exploration, mise en place, détermination des solutions, jusqu'à un moment où on est clair sur la solution adoptée et on peut délivrer. Donc les 6 semaines nous permettent de faire l'ensemble et l'entièreté du cycle jusqu'à la finalisation. La partie qui délivre est différente de la partie qui fait le pitch. Le pitch doit nous permettre d'avoir un moment plus stratégique dans lequel on va déterminer les bonnes ressources et la validité et le ROI du pitch que l'on veut déployer et mettre en place. J'ai envie de mettre en place une solution de paiement avec Apple Pay, par exemple. Est-ce que c'est le bon moment ? Est-ce que j'ai les bonnes personnes qui peuvent le faire dans les six semaines qui sont en partie avant de lancer mon cycle de six semaines ? Et l'enjeu, c'est d'inverser complètement la question de l'investissement versus le coût. On ne dit pas et on ne parle pas de combien ça va me coûter. Non, on veut savoir combien on est prêt à investir pour le pitch, pour la feature, pour le projet. Une fois qu'on est prêt à investir, on a des investissements faibles, des petits investissements de une à deux semaines, et des investissements importants qui vont... jusqu'au cycle complet de 6 semaines. Ces deux investissements-là vont être associés à des équipes qui sont autonomes, qui sont focus, et dont le projet est entièrement leur priorité, ou dont les projets sont entièrement leur priorité. Donc si j'ai 6 semaines avec un projet qui vaut 6 semaines, je vais passer les 6 semaines dessus, avec mon équipe de designers et de développeurs. Si par contre j'ai des plus petits projets de 2 semaines, je vais avoir 3 projets de 2 semaines à délivrer durant le cycle de 6 semaines. Par exemple, un exemple qui est défini pour Basecamp, c'est une feature de notification peut avoir un appétit de deux semaines. Voilà, feature notification, je pourrais passer plus de deux semaines dessus. Je pense que deux semaines, c'est suffisant. Et donc, je dois me débrouiller, l'équipe doit se débrouiller pour passer deux semaines dessus. Donc après, temps fixe. Scope variable, on ne va peut-être pas faire quelque chose de très élaboré sur les notifications s'il y a un risque que ça dépasse les deux semaines. En revanche, la refonte d'une page de la homepage par exemple, ici on peut définir un appétit de six semaines, et donc on a un temps plus long, on est prêt à investir plus de temps sur la homepage que sur la notification. Et donc on change la logique sur de l'output, d'être... On ne va pas demander à quelqu'un combien ça coûte 2, c'est non, je veux passer 2 semaines là-dessus, qu'est-ce que tu me proposes comme solution ? Et ça change beaucoup la physionomie, je trouve que c'est assez intéressant, puisque, en fait, toujours passer sur une home page, on pourrait passer 6 mois par exemple, si on a envie d'aller dans le détail, etc. Non, maintenant, il faut faire des choix pour investir judicieusement. Le deuxième point qui est intéressant, c'est l'autonomie totale. Ça, c'est la culture de Basecamp et de 37signals. Pas de surveillance, pas de daily stand-up, c'est plutôt des check-in. hebdo en asynchrone sur la base de ce diagramme colline qui va définir la phase montante de découpage ou en tout cas de compréhension des solutions au aha moment tout en haut de la colline, j'ai trouvé la solution jusqu'au delivery et le fait de réaliser les solutions. Cela permet une communication totalement asynchrone puisque chez Basecamp et chez 37signals C'est une équipe full remote depuis le début. Donc depuis 99, c'était pas mal. D'ailleurs, ils ont aussi écrit un autre livre, la même équipe, qui s'appelle Remote, avant le code vide. Le but aussi dans l'organisation, c'est d'avoir des designers et des devs qui sont ensemble. Pas de backlog, pas de répartition des tâches qui est uniquement dédiée au front, au back. Non, c'est une équipe qui gère le projet de A à Z. Donc ça veut dire une équipe, un projet, pas une équipe. plusieurs projets. On veut focus. Et enfin, la méthodologie, le côté préparation des pitches, avec la définition du problème, avec les solutions et les risques qui sont à identifier et à mitiger, pour pouvoir dessiner des solutions qui sont entre guillemets « shapées » , ce qu'ils appellent « shaping » , avec un niveau de définition Merci. qui est grossier. C'est des croquis, c'est les fameux risques identifiés, c'est l'appétit qu'on a identifié. Donc globalement, les trois propriétés d'un bon pitch, c'est que c'est grossier, résolu, donc on a identifié les risques, et c'est limité dans le temps. Donc on a un périmètre qui est clair. Et donc les outils qu'on a vus, c'est le breadboarding, que je pourrais vous partager, et que vous verrez même dans le livre. les esquisses qui sont les deux outils principaux pour en sortir les éléments clés. Le dernier point, c'est qu'après ces cycles, eux utilisent ce qu'ils appellent le cooldown, la période de cooldown, la période de rafraîchissement, où ils prennent deux semaines pour résoudre des bugs, explorer, faire de l'amélioration continue des side projects. Les bénéfices qui sont retirés de cette méthode, c'est... de stimuler la créativité des équipes. Les équipes sont totalement libres de trouver les solutions et du coup, on renforce leur autonomie. Renforcer cette autonomie et responsabiliser les gens dans un environnement qui est cadré mais libre, ça évite les burn-outs. Donc ça, c'est leur constat. Et surtout, c'est la rétention des talents. Puisque, grâce à ça, je délivre, je partage et je mets à disposition, ou en tout cas, je... responsabilise les équipes sur des projets, je ne responsabilise pas les équipes sur des simples tâches et je les mets en lien avec une vision claire, un appétit clair qui est défini, en tout cas assuré par la gouvernance du projet qui sont les betting tables dont on parlait plus tôt. Maintenant, Shippup peut aussi être adapté hors tech, en marketing, on peut faire les campagnes, on peut avoir de l'appétit sur des projets. créatif, j'ai envie de faire une vidéo 3D de mon entreprise, de mes services, j'ai envie de faire un shooting de mes collaborateurs, de créer un podcast, de créer toutes sortes de choses, on peut l'aborder de la même manière. Un pitch, un appétit, une liste de tâches associées à une équipe projet qui va le réaliser. On peut le faire en RH sur les programmes de formation, on peut le faire sur les produits physiques également, pour que ça puisse délivrer le plus rapidement possible. Donc finalement, ce que ça m'a apporté, ce que ça a changé, c'est la vision que j'ai à des projets que je délivre. Aujourd'hui, j'ai revu mon usage, en tout cas les projets que j'ai dans mon Rtable, les projets persos, les projets de boîte, pour l'adapter à la méthode ShapeUp, pour la visualiser dans un graphe call-in. Donc là je suis en phase de démarrage, j'observe, je regarde comment ça se passe, je vais essayer de créer des pitches. Donc là vous allez faire la même chose, c'est-à-dire premièrement commencer à expérimenter cette méthode, commencer par lire le livre peut-être, vous renseigner rapidement sur les différentes parties du livre dont on a parlé dans ce podcast pour vous familiariser avec les méthodes, et de tester ces mini-cycles de pitch plus la traversée dans la colline. C'est un outil et un livre qui m'ont vraiment inspiré, qui m'ont redonné de la perspective sur de la gestion de projet, sur la satisfaction qu'on peut avoir à partager un projet, le gérer, en déterminer les solutions, et surtout à réduire le côté pression. On n'a pas besoin de tout savoir dès le début. On peut découvrir au fil de l'eau. L'enjeu, c'est de se... limité dans le temps. Je rappelle que ce limité dans le temps, c'est lié à la loi de Parkinson. La loi de Parkinson, c'est une loi dans le regard à biais cognitif. Quand vous avez deux semaines pour faire une tâche ou deux mois, vous la finirez en deux semaines ou en deux mois, selon la deadline que vous vous fixez. C'est ce qu'on appelle la loi de Parkinson. On pourra en développer un bout plus tard dans un autre épisode qui sera sur les biais cognitifs. Voilà, un livre super, un livre qui va inspirer les product managers qui sommeillent en vous, qui va inspirer les chefs de projet qui sont en vous aussi. N'hésitez pas à poser vos questions, on peut échanger sur le sujet bien évidemment sur la partie commentaires, ou vous pouvez me contacter directement, ce sera avec plaisir d'échanger sur... sur la méthodologie, sur les différents outils qui sont utilisés, et sur les retours d'expérience que les uns et les autres ont, si vous avez utilisé la méthode ShapeUp, qu'est-ce qui a fonctionné pour vous, qu'est-ce qui a moins bien fonctionné, ça reste quelque chose d'itératif, et quelque chose de vivant. En tout cas, moi ça a été un plaisir de relire ce livre, je vais l'appliquer dans les semaines qui viennent pour mes projets, et on pourra se faire un retour une prochaine fois. En tout cas... N'oubliez pas que c'est disponible gratuitement sur Basecamp. Inspirez-vous, et puis à très bientôt pour un nouveau livre. Allez, salut !
