#22 - Révolutionner la gestion de projet, inspiré de Shape Up - Ryan Singer

Aujourd'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 podcast 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 en téléhargé. 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 revisiter dans le temps. Le but, c'est de remonter à la source, 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. Vous pouvez 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'axé, il est vendu au prix de 26,95€ 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, j'adore les ponts et les liens qu'il peut y avoir entre différents domaines. Shape up est aussi possible. enfin en tout cas 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 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 37 Signals, 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 du 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, Sordid Saving Signal, 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 vous 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 GitHub, 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 280 millions de dollars, revenu annuel, et plus de 250 000 clients. Voilà, les 3 millions d'utilisateurs, donc c'est vraiment... Vraiment une super success story avec 25 ans de rentabilité consécutive sur ce projet. Concernant ShapeUp, Ryan Singer, qui est aussi un des designers et le Head of Strategy et Product, lui, il a détaillé 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à aux produits. 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 Kamban, 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és aux équipes et qui est tournée vers l'efficacité, le delivery et la... l'apport de valeur ou en tout cas le shipping, défaut d'avoir un meilleur nom, le shipping de valeur pour les produits. Alors, ShapeUp, ça a été publié entièrement gratuitement en 2019. Et la particularité de SILVRE, 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 au stand-up meeting, au backlog et aux équipes qui ont des tâches qui s'empilent et qui ne savent pas comment faire, qui perdent aussi notamment le lien entre la vision du projet, la vision du produit et leur exécution quotidienne. Finalement, on a tous, moi le premier, quand j'ai lancé des initiatives produits, on a envie de faire un backlog, de renseigner 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 fait focus, et... 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 sur lequel on passe. En tout cas, le temps pour lequel on... dédiés à 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 cycle de six 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 six semaines, c'est qu'on part sur des sprints de deux semaines. Donc c'est une séquence de six semaines. Ces cycles de six semaines, ils sont détaillés en trois phases. La première phase qui varie entre une et deux 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 cinq et six, donc les semaines cinq et six de sprint, ça va être la finalisation, l'affinage des solutions que l'on aura. développé. Ce qui est intéressant aussi, c'est les principes qui régissent. Les principes qui régissent donc cette théorie. Déjà, le point numéro un 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 et 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 ». définir son appétit pour le projet. 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... 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 donc 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 surtout de d'avoir en tête aussi que en fait dans les différentes phases du projet on va pouvoir à tout instant décider de l'arrêter le framework que chez pub propose c'est un framework en cinq phases la phase numéro un c'est la définition du problème quel problème je vais résoudre mes utilisateurs pour mes clients en interne Quel est l'appétit, 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 deux semaines, pour lequel je vais investir six semaines ? Et ensuite, on commence par définir les solutions. Il y a trois phases dans la méthodologie ShapeUp. 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 et une phase de finalisation. Dans la phase d'exploration, ici, on reste sur ces cycles de six semaines assez vagues, assez brouillons. On ne va pas faire des wireframes super précis. Non, parce qu'en fait, dans la méthodologie ShapeUp, 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 un, c'est de savoir si déjà le projet en vaut la peine et le projet, à un périmètre qui est faisable en la période de six 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 lui met, les solutions qui sont, et on le déterra juste après, qui sont grossièrement définies. on va dire, ce qu'ils appellent les rabbit holes, donc 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 chef de projet, qui va constituer ce pitch avec les différents stakeholders. Alors qui sont les stakeholders ? Déjà, on a la partie product, qui est le chef de projet, les business units qui sont différentes 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 la partie de projet. 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 pitchs qui sont mis à disposition. Donc globalement, c'est un comité qui va... prioriser, définir les différents pitchs 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, la personne référente numéro 1 sur l'entreprise, le CTO, référente 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 cycle. L'objectif donc, c'est à partir de ces pitchs de sortir un plan. des pitchs qui sont sélectionnés, qui vont être le focus, qui vont être la priorité pour ces cycles de six 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 ? Est-ce que l'appétit qu'on a défini est juste ? Est-ce qu'on a envie d'investir le... temps à louer, est-ce qu'on a envie d'investir deux semaines, est-ce qu'on a envie d'investir plus, est-ce qu'on a 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 vont bénéficier 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 pour le cycle de six semaines sur lequel on va s'accorder. Une fois qu'on a défini, d'après la méthode, le pitch, on part dans un cycle de Donc 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éalise le pitch et qui sont focus sur ce cycle de six semaines. Pendant ce cycle de six 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 six 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 six semaines, on n'a pas réalisé le projet. Là, la méthode est radicale, le principe est clair, on... On arrête le projet. Si le projet n'est pas réalisé dans les six 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 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 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. 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 aux gros marqueurs. Donc, c'est des esquisses. Ils appellent ça des esquisses aux marqueurs. 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 investit 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 pérennité du ROI de cette solution-là. Le but est de ne pas l'avoir délivrable 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 à s'embêter, à faire un design trop complexe. On fait vraiment blackboard et des esquisses. Les esquisses grossières, ça peut être tout simplement... 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 textes, je vais juste le notifier par des petits gribouis. 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, on va dire, la... la créativité d'un designer qui pourrait arriver derrière et aussi en laissant de l'adaptabilité. Parce que, en fait, derrière, une fois que le pitch est validé, souvent, on va se rendre compte que les taffes 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 et il faut pouvoir l'utiliser et s'adapter. Pourquoi ? Parce que, on rappelle que 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 le scope, puisque mon objectif, c'est justement de délivrer dans le temps imparti. 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, on fait un pari qu'en X semaines, 6 semaines, 2 semaines, si c'est des projets plus courts. et on peut batcher les plusieurs projets de deux semaines dans un projet de six semaines, pour garder des cycles complets, eh bien on va réaliser ce pari. Ensuite, on assigne ce projet, on n'assigne pas des tâches, donc il n'y a pas vraiment un CTO qui va découper les tâches et dire, c'est l'équipe projet designer 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 que au lieu d'avoir une liste de tâches pour le front une liste de tâches pour le bac non 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, on a killé 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 même 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é, 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 chart Hill, le Hill chart, donc le chart Colline, qui... récapitule, au lieu d'avoir une liste de tâches et combien de pourcents je vais réaliser sur cette tâche, etc. Non, eux, ils partent de trois étapes. Un, je détricote 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 Collin. Et c'est avec ce diagramme Collin 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ées. Et si j'ai des tâches qui sont bloquées, à un endroit, je sais que je peux prendre un moment pour identifier des 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 ? Ce diagramme, il est peu pratique et il change surtout des différentes... vision 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 l'ensemble des tâches au démarrage du projet. Parce que si 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 limitation pour pouvoir l'utiliser dans d'autres aspects. Les enjeux essentiels, c'est d'avoir des cycles de six semaines. D'avoir une structure temporelle qui comprend dans ce cycle de six 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 à adopter et on peut délivrer. Donc les six 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 imparties 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 nous 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 1 à 2 semaines, et des investissements importants qui vont jusqu'au cycle complet de 6 semaines. Ces 2 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 entièrement leur priorité. Donc si j'ai six semaines avec un projet qui vaut six semaines, je vais passer les six semaines dessus avec mon équipe de designers et de développeurs. Si par contre, j'ai des plus petits projets de deux semaines, je vais avoir trois projets de deux semaines à délivrer durant le cycle de six 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. Futur notification, je peux pas 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 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 home page par exemple, ici on peut définir un appétit de 6 semaines, et donc on a un temps plus long, on est prêt à investir plus de temps sur la home page que sur la notification. Donc on change la logique sur de l'output, c'est-à-dire qu'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, on peut 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, il faut faire des choix pour investir judicieusement. Le deuxième point qui est intéressant, c'est l'autonomie totale. C'est la culture de PaceCamp et de 37 Signals. Pas de surveillance, pas de daily stand-up. C'est plutôt des check-in hebdo en asynchrose sur la base de ce diagramme call-in 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 call-in. 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, chez 7 Signals, c'est une équipe full remote depuis le début. 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, voilà la méthodologie, le côté préparation des pitchs 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é », ce qu'ils appellent « shaping », avec un niveau de définition qui est, on va dire, grossier. C'est les 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 cool down, la période de cool down, la période de rafraîchissement où ils prennent deux semaines. 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-out. leurs constats, et surtout c'est la rétention des talents. Puisque, grâce à ça, je partage, je mets à disposition, 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, et assuré par la gouvernance du projet, qui sont les betting tables dont on parlait plus tôt. Maintenant, Shepup peut aussi être adapté, hors tech, en marketing, on peut faire les campagnes, on peut avoir de l'appétit sur des projets créatifs. 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. Eh bien, 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 qu'on puisse délivrer le plus rapidement possible. Donc, finalement, moi 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 ma... 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 graph colline. Donc là je suis en phase de démarrage, j'observe, je regarde comment ça se passe, je vais essayer de créer des pitchs. Donc là vous invitez à 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. Donc c'est un outil et un livre qui m'ont vraiment inspiré, qui m'ont... redonner 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 limiter dans le temps. Je rappelle que se limiter dans le temps, c'est lié à la loi de Parkinson. La loi de Parkinson, c'est une loi, on va dire un 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 project managers qui sommeillent en vous, qui vont 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 commentaire 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 vraiment bien fonctionné ? Ça reste quelque chose d'itératif et quelque chose de vivant. En tout cas, moi, c'était 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 à très bientôt pour un nouveau livre. Allez, salut !

🚀 Shape Up - Ryan Singer 🚀
Bienvenue dans ce nouvel épisode où nous explorons la méthode de gestion de projet qui a révolutionné Basecamp et des milliers d'entreprises dans le monde : "Shape Up" de Ryan Singer. 📚⚡
Aujourd'hui, découvrez comment abandonner définitivement les méthodes traditionnelles (Scrum, Agile, backlogs infinis) pour une approche basée sur l'autonomie, la confiance et l'efficacité.
Cette méthode, développée par l'équipe à l'origine de Basecamp et d'une success story de 25 ans, va transformer votre façon de gérer vos projets !

🌟 Ce que vous allez apprendre :
⏰ CYCLES DE 6 SEMAINES
→ Pourquoi 6 semaines est la durée parfaite (ni trop court, ni trop long)
→ Comment structurer exploration, construction et finalisation
→ L'art de définir son "appétit" pour chaque projet
🎯 BETTING TABLE & PRIORISATION
→ Le rituel qui remplace tous vos comités de pilotage
→ Comment 4 personnes décident mieux qu'un comité de 15
→ Les 4 questions qui révèlent si un projet vaut le coup
🎨 OUTILS
→ Breadboards : cartographier sans perdre de temps
→ Esquisses grossières : pourquoi le détail tue la créativité
→ Hill chart : le seul indicateur de progression qui compte
👥 ÉQUIPES AUTONOMES
→ Designer + Développeurs = équipe projet complète
→ Fini les daily stand-ups et la micro-gestion
→ Comment responsabiliser sans surveiller
💡 NOUVEAU PARADIGME
→ Temps fixe, scope variable (l'inverse de ce qu'on fait habituellement)
→ "Combien je veux investir ?" vs "Combien ça va coûter ?"
→ Pourquoi arrêter un projet après 6 semaines est libérateur
🚀 APPLICATIONS CONCRÈTES
→ Adaptable en marketing, RH, produits physiques
→ De la startup à la grande entreprise
→ Remote-friendly par design

Une nouvelle approche de la gestion de projet, dites adieu aux méthodes qui vous font perdre du temps et de l'énergie ! 
Le livre est disponible GRATUITEMENT sur basecamp.com/shapeup

TIMESTAMPS :
00:00 Introduction et contexte
02:30 Qui est Ryan Singer et l'histoire de Basecamp
05:45 Les limites de Scrum et Agile
08:20 Les principes fondamentaux de Shape Up
12:15 Les cycles de 6 semaines en détail
18:30 Le betting table : prioriser comme un pro
25:40 Breadboards et esquisses grossières
32:10 Le hill chart révolutionnaire
38:20 Applications hors tech
42:15 Mon retour d'expérience et plan d'action

#ProductManagement #GestionDeProjet #ShapeUp #Basecamp #RyanSinger #Leadership #Efficacité #Startup #Tech #Management #Autonomie #Innovation