Équipes Projet Sans Chefs De Projet : Explorer Le Dilemme Du CP

Lisez la transcription :

Nous testons la retranscription de nos podcasts à l'aide d'un logiciel. Veuillez excuser les éventuelles fautes de frappe, l’IA ne retranscrit pas encore parfaitement à 100% du temps.

Galen Low : Équipes projet auto-gérées. Cette seule expression suffit à provoquer une crise existentielle chez n'importe quel chef de projet. Mais est-ce une menace pour notre existence ? Ou est-ce la clé permettant au chef de projet de prendre un rôle bien plus stratégique ?

Si vous vous interrogez sur l'avenir de la gestion de projet et sur la pérennité du métier de chef·fe de projet digital, continuez d'écouter. Nous allons soulever le capot pour découvrir comment une organisation parvient à développer avec succès des solutions logicielles complexes grâce à des équipes distribuées et auto-organisées, et ce que cela signifie pour la gestion de projets digitaux en général.

Merci de nous écouter, je m’appelle Galen Low de Digital Project Manager. Nous sommes une communauté de professionnels du digital en mission pour s’entraider à devenir plus compétents, confiants et connectés afin de livrer des projets impactants et porteurs de sens. Pour en savoir plus, rendez-vous sur thedigitalprojectmanager.com.

Bonjour à tous — merci d'être avec nous pour ce podcast du DPM.

Mon invitée aujourd’hui est une professionnelle IT basée à Kiev, qui fait bouger les lignes du management des processus métier et du management de produits digitaux depuis plus de 15 ans. Elle a été business analyst, directrice PMO, directrice produit, directrice expérience client, travaillant pour des marques telles que Heinz, Yandex, Adidas ou Zyxel pour déployer des systèmes d’entreprise à grande échelle.

Aujourd’hui, elle est cheffe de produit chez Railsware, sur l’équipe Coupler.io, où elle supervise des équipes distantes et agiles, auto-gérées, qui créent des produits largement adoptés, aujourd'hui devenus des références, comme Calendly.

En dehors du travail, elle enseigne la gestion des processus métiers et la gestion de projet à la Lviv Business School, tout en élevant son bébé pour qu'elle devienne la prochaine génération de femmes dans la tech.

Accueillons chaleureusement Julia Ryzhkova. Bonjour, Julia !

Julia Ryzhkova : Bonjour à tous !

Galen Low : Merci d’être avec nous aujourd’hui. Merci pour nos récentes discussions, je suis vraiment ravi pour l’épisode d’aujourd’hui car je pense qu’il touche à un sujet qui nous rend tous un peu nerveux en tant que chefs de projet : est-ce que notre métier va continuer d’exister ?

Nous allons y revenir, mais je voulais te demander — comment vas-tu ? Qu’est-ce qui t’inspire en ce moment ?

Julia Ryzhkova : Ce sont en fait deux choses différentes. Si l’on parle de Railsware, c’est le framework BRIDGeS. On l’a ouvert récemment, il s'agit d’un cadre de décision qui permet, à haut niveau, de décrire un problème puis de le transformer en solution.

Nous venons de le partager publiquement et actuellement je m’emploie à en faire parler autour de moi. C’est vraiment génial, je suis très enthousiaste à ce sujet. On y travaille depuis plus de 15 ans. Là, c’est comme une ouverture au public, et c’est vraiment inspirant.

D’un point de vue personnel, comme tu l'as dit, j’enseigne aussi à la business school de Lviv et on monte en ce moment une formation publique en ligne sur les processus métiers. J’espère que cela améliorera la maturité globale de la culture du business process en Ukraine.

Cela aussi m’inspire.

Galen Low : J’adore ça. Deux choses passionnantes, de belles réussites. Félicitations !

Si les gens souhaitent en savoir plus sur le framework BRIDGeS, où doivent-ils aller ?

Julia Ryzhkova : Sur le site de Railsware, nous avons un sous-domaine dédié.

Galen Low : Génial. Très cool. Très cool. Et puis, on enregistre en décembre, on s’apprête à passer à 2022… Qu’est-ce qui t’enthousiasme le plus pour 2022 ?

Julia Ryzhkova : Oh, tu sais, tout le monde parle d’intelligence artificielle et de machine learning. Dernièrement, on a fait une réunion pour discuter des visions produits, et j’ai cette idée d’utiliser l’IA sur mon produit, Coupler.io, et j’ai vraiment hâte d’essayer ça et voir ce que ça donne.

Galen Low : Trop bien.

Bon, rentrons dans le vif du sujet. Aujourd’hui, on va parler de la façon dont de petites équipes agiles, à distance, peuvent s’auto-manager et s’auto-organiser en essaim pour créer des solutions logicielles complexes, sans chef de projet à aucun moment. Est-ce une menace pour nous, chefs de projet ? Est-ce une opportunité de devenir plus stratégiques ? Alimente-t-on l’angoisse existentielle de nos auditeurs ?

On va tout explorer en détail, on va vraiment lever le couvercle et creuser.

Mais pour commencer, pourrais-tu nous raconter ton parcours ? Quel est ton rôle aujourd’hui et comment en es-tu arrivée là ?

Julia Ryzhkova : Aujourd’hui, je suis cheffe de produit, donc je gère le développement, la stratégie marketing, la tarification et la force de vente.

J’ai une formation technique, ce qui m’a beaucoup aidée en informatique, mais je n’aimais pas coder. Quand j’ai cherché une voie professionnelle, je voulais un poste où concevoir un algorithme sans avoir à le coder moi-même. C’est ainsi que je suis devenue BA. Puis le leadership m’a plu, je suis devenue cheffe d’équipe BA, cheffe de projet, responsable du pôle BA.

Mais j’ai remarqué que le résultat de mon travail dépendait vraiment du produit sur lequel je travaillais. D’où mon choix de me tourner vers la R&D pour devenir product owner et faire partie du produit. Ce fut la première fois où je me suis sentie à ma place. Le produit a grandi, l’équipe aussi, il y a eu davantage de product owners et je suis devenue directrice adjointe produit, gérant la moitié des équipes scrum, puis j’ai voulu aller plus loin.

Comme on avait déjà une directrice produit, j’ai choisi de m’orienter vers la direction de l’expérience client, où j’ai géré le support, l’académie, tout ce qui touchait aux services. J’y ai mis en place de super process et obtenu de bons résultats.

D’où la décision de tirer parti de ces compétences pour structurer d’autres départements, et je suis devenue directrice PMO. Puis il y a eu le congé maternité. Et une fois ce chapitre important terminé, j’ai voulu revenir au management de produit.

C’était une décision importante et peut-être te demandes-tu pourquoi manager le produit et non le projet ? Parce que je voulais me concentrer sur la valeur pour les clients en laissant la gestion des process de côté. Pour moi, c’est ça la différence entre produit et projet. Il y a beaucoup de points communs.

Mais il me semble que la chefferie de produit permet de se focaliser sur le produit et le client, alors que le management de projet vise le process et son aboutissement, non ? Là, les équipes auto-organisées sont essentielles, et j’ai su que Railsware était une parfaite opportunité quand j’en ai entendu parler et que je m’y suis intéressée.

Galen Low : J’adore ce parcours, ce bagage technique, cette expérience client, ce leadership. C’est vraiment inspirant pour le secteur.

Peux-tu nous parler un peu de Railsware, de la structure des équipes que tu diriges, et du type de projets traités par Railsware ?

Julia Ryzhkova : Oui, commençons par les projets, car la structure des équipes dépend du type de projets. Nous sommes un studio produit, donc nous créons à la fois pour nous et pour d’autres entreprises. Chez Railsware, on aime automatiser tout, et parfois, il n’existe pas un outil sur le marché qui fait ce que l’on veut.

C’est là qu’on décide de développer l’outil en interne, on l’utilise, puis on le lance publiquement car nous savons que d’autres en ont aussi besoin. On commence donc en petite équipe pour tâter le terrain, parfois même avec un développeur à temps partiel — par exemple, pour le Smart Checklist for Jira que nous avons lancé, il a été développé à temps partiel par un seul développeur, et ce n’est qu’à 50k de MRR qu’on a détaché des développeurs à temps plein dessus.

Pour les petits produits comme Coupler.io, on a une squad de développement de 4-5 devs, et une squad marketing aussi de 4-5 spécialistes.

Les autres rôles sont en temps partiel, comme l’analyste data, le support, ou même moi, cheffe de produit, j’interviens sur ce produit et sur ceux des clients. Mais quand le produit grossit, comme ce fut le cas pour Calendly, on étoffe la dev team, puis on divise en plusieurs squads, car on croit à l’efficacité des petites équipes.

Aujourd’hui, Calendly compte trois équipes côté Railsware, plus plein de développeurs côté client. Voilà comment on fonctionne.

Galen Low : Super. J’aimerais vraiment creuser cette idée de squads et de « swarms ». J’aime que le marketing soit aussi une squad. Au fond, Agile ne veut pas dire que développement ou ingénierie.

Ça peut être plein d’autres choses, on va en parler. Dis-moi, quel est le plus grand défi pour toi aujourd’hui côté gestion de produit ?

Julia Ryzhkova : Je pense que ce ne sera pas une surprise, c’est le défi habituel de tout Product Manager dans un produit startup : trouver l’opportunité en or sur le marché.

On résout généralement un « pain point » du client, c’est pour ça que la base client et les KPI augmentent, mais on veut garder le rythme, voire le doubler. Il faut donc identifier un nouveau problème que les clients seraient prêts à payer cher pour résoudre.

Galen Low : Vous êtes des résolveurs de problèmes. Ce que j’aime, c’est que vous réglez d’abord vos propres soucis puis vous permettez à d’autres d’en bénéficier. C’est comme un produit interne qui rayonne vers l’extérieur. Vous êtes aussi un prestataire, aidant d’autres structures à bâtir les produits de leurs rêves pour éliminer leurs douleurs insupportables.

C’est super.

Pour éclairer nos auditeurs : dans mes cercles, l’idée d’équipes auto-gérées est à double tranchant. D’un côté, la plupart des chefs de projet veulent des équipes autonomes pour ne pas devenir le goulot d’étranglement, mais de l’autre, ils souhaitent rester pertinents et garder un poste.

Le concept des équipes projet sans chef de projet n’est pas nouveau au fond. En Scrum Agile, il n’y a pas de chef de projet, juste un product owner, un scrum master et l’équipe de dev. Donc quelque part, l’avenir était déjà en marche, mais on tente toujours de décrypter pour qui ce sera pertinent et comment.

D’un côté, c’est donc une menace — qui a besoin d’un chef de projet si l’équipe peut s’auto-gérer ? Mais de l’autre, c’est le nirvana du management : être plus stratégique, plus proche du produit et du client, moins « dans la mêlée » du pilotage quotidien.

Alors, la question : y a-t-il un équilibre à trouver ? Peux-tu nous expliquer comment fonctionnent ces squads auto-gérées chez Railsware et dans Coupler.io ?

Julia Ryzhkova : En fait, la réponse est liée à notre concept du « product mindset » des développeurs.

On a fait un webinaire sur ce sujet récemment. L’idée, c’est qu’on cherche des développeurs « profil T » mûrs, comme je le suis — tu as dit que j’avais beaucoup d’expériences différentes, et c’est typiquement le genre de personne qu’on recherche. Cela leur permet de travailler avec le client en tant que dev, PDM, PM au moment du MVP.

On a affiné notre processus de recrutement pendant des années pour trouver ce genre de profils, car ce n’est pas évident. On intègre ces talents sur nos produits internes d’abord, avant de les envoyer sur les produits clients, histoire de les former sur l’état d’esprit produit.

Alors seulement, ils peuvent travailler avec les clients, un peu comme un orchestre à un seul musicien. Mais c’est pareil aussi pour d’autres rôles. Tous les Railswarians (c’est comme ça qu’on s’appelle) peuvent travailler séparément. Beaucoup de gens ont eu des expériences de management, même monté leur propre business, que ce soit RH, designers, ou chefs de produit bien sûr. Vraiment tout le monde.

Mais aucun de nous n’est le manager direct de l’équipe. L’autorité se gagne par l’exemplarité. Tu montres le chemin par ton impact sur le produit et le résultat global, c’est ça qui génère la confiance de l’équipe. Tu ne peux pas juste dire quoi faire, tu dois agir et influencer de façon concrète.

Galen Low : J’aime beaucoup cette logique du T-shape, l’apport d’expériences variées. Et c’est intéressant de voir le recrutement focalisé autant sur la posture managériale ou entrepreneuriale que sur la technique. Même si les rôles sont plats dans l’équipe.

Tu as un background en gestion de projets, tu as même dirigé un PMO. Cette idée d’équipes auto-gérées, au départ, ça ne t’a pas perturbée/ébranlée ?

Julia Ryzhkova : Oui, c’est drôle que tu le demandes. Au début, pendant la période d’essai chez Railsware… C’était facile d’évaluer mon utilité quand j’étais l’élément clé et que sans moi tout partait à la dérive. Mais quand tout fonctionne bien même sans toi, tu ne ressens plus l’impact, du moins comme avant.

On fait des changements, on améliore un processus, et ça avance… un peu. C’est bien, ta présence améliore les choses, mais tu pourrais partir deux semaines sans que tout ne s’écroule. Pourquoi ont-ils alors besoin de toi ? Mais avec le temps, on arrête de vouloir tout contrôler, et avec ce temps libéré, on trouve d’autres moyens d’influencer.

On se concentre sur le produit, le client, la stratégie, et on peut peser plus, parfois. D’autant plus, en laissant de l’espace à l’équipe, elle peut créer des choses incroyables via des guildes — squad de 4 devs, 1 QA, mais aussi la guilde des ingénieurs, la guilde du QA, la guilde des produits.

Par exemple, c’est la guilde produit qui a bâti le framework BRIDGeS dont j’ai parlé. Impossible d’inventer ça sans avoir cette liberté d’action, sans validation inutile…

Galen Low : J’adore. Tous mes meilleurs souvenirs d’équipe sont ceux où il y avait beaucoup d’indépendance et d’empowerment, pas où on cherche à évincer le chef de projet, mais où on donne assez de latitude pour inspirer, orienter, guider. Parfois, on caricature notre boulot de chef de projet, à courir partout façon berger de chats, mais en réalité, c’est surtout donner sens, inspirer et créer l’espace pour que l’équipe donne le meilleur. Ça ressemble beaucoup à votre culture, pas tant dans l’idée de supprimer ton poste, mais de l’élever, le rendre plus stratégique. Et puis, le luxe de réellement pouvoir partir en vacances !

Du coup, aujourd’hui, tu utilises encore tes compétences de gestion de projet ? Est-ce que ça te sert ?

Julia Ryzhkova : Clairement ! Je ne vois pas comment on peut être chef·fe de produit sans avoir un passé de gestion de projet. Comme je l’ai dit, c’est crucial. Mon bagage technique m’a apporté un plus, mais la gestion de projet est indispensable en produit aussi.

Chez Railsware, toutes les fonctions seniors doivent savoir gérer un projet : communication, organisation, etc. C’est utile pour tout le monde.

Si on parle de compétences précises, souvenons-nous du PMBOK, j’évite aujourd’hui surtout l’intégration et la communication, car c’est l’autogestion qui prime. Mais la gestion du scope, du coût, du planning et des stakeholders reste. Pour la qualité, c’est du ressort QA/dev, ce n’est plus moi. Les risques et achats sont partagés sur tous. Si quelqu’un a besoin d’un outil, il fait juste une demande en argumentant.

Et c’est cool de ne pas avoir à tout comprendre. Je ne vois pas pourquoi je devrais décider de tel outil marketing ou de telle librairie de dev. Tant mieux !

Galen Low : Ce qui est fort, c’est que tu dis que toutes les fonctions seniors doivent maîtriser la gestion de projet — scope, coût, planning, stakeholder. Parfois, on l’oublie, alors que c’est la base pour faire avancer sainement un business. Est-ce inscrit dans votre process de recrutement ou bien chacun se forme sur le tas ?

Julia Ryzhkova : Quand je parle des seniors, je pense aussi aux devs ou QA — pas les office managers évidemment. Mais toutes les fonctions qui concourent aux produits/projets doivent savoir se gérer : son scope, son planning, son coût… C’est ce qu’on attend de chacun. On cherche des profils mûrs !

On ne demande pas une formation certifiante, mais on complète au besoin. Mais pas de formation de zéro.

Galen Low : Je comprends. Et comme digital project/product managers, on doit beaucoup apprendre des autres métiers, mais eux aussi doivent apprendre de nous — sur la gestion, le collaboratif, et la compréhension business. Ce partage, c'est clé.

Double-cliquons sur tout ça, pour aider ceux qui nous écoutent et se questionnent sur comment transposer ce modèle : comment ces squads communiquent et restent alignées ?

Julia Ryzhkova : C’est surtout une question de culture. Quand les deux fondateurs de Railsware ont démarré, ils ont défini leurs process de façon structurée — des to-do simples, mais tout était documenté. Ils cherchaient des gens partageant cette culture. Peu de jeunes entreprises démarrent comme ça. D’habitude, on ne s’occupe des process que lorsqu’on perd pied.

Mais là, la structure était présente dès le départ, c’est devenu culturel. L’onboarding est processé, mais le vrai mantra est « documenter au fil de l’eau ».

Chaque réunion, chaque échange collectif, tout va dans une doc partagée, Figma, doc Word, où chaque participant note au fil de l’eau — pas de compte rendu post-réunion. Tout se fait en amont ou pendant la réunion. Et si quelqu’un sort du script, les autres l’écrivent aussi. Deux semaines de vacances ? Il suffit d’ouvrir ces documents, tout est là — pas besoin de « Faites-moi le point ». Rien n’est laissé sur le bas-côté.

Cela va de pair avec la culture de la transparence : toutes les communications passent par des channels publics, on a plus de 300 Slack channels. Quasiment pas de messages privés pour le travail. Tout est public, donc chacun peut s’informer ou répondre plus vite que la personne concernée.

Galen Low : Oui, c’est ce que beaucoup essaient de maîtriser — l’asynchrone, la conservation des discussions. Railsware est très précurseur en la matière, dès le début avec de simples to-do partagés. Pas besoin d’énormes process, mais que ce soit écrit quelque part.

Julia Ryzhkova : Oui, j’admire ça. Avant, j’enseignais qu’au lancement, on pouvait se passer de process si tu es seul et que tu sais comment faire. Mais après avoir vu l’histoire de Railsware, j’ai changé d’avis : il faut structurer dès le départ, même si ce n’est qu’une checklist. Si tu veux te repérer seul, tu feras quand même ton tableau ou ta liste d’étapes. Sinon, tu perds le fil.

Impossible de faire du business sans processus.

Galen Low : Je vois. Qu’en est-il des métriques équipe ?

Dans ce modèle, beaucoup se demandent sur quelles performances se fier, comment savoir que tout est sur les rails, comment contrôler alors que la structure est plate ?

Julia Ryzhkova : C’est amusant, mais je ne regarde aucune métrique de performance individuelle. Peut-être que ça semble fou, mais je suis les métriques produit.

On observe la croissance, nos indicateurs SaaS : conversion, chiffre d’affaires, etc. Bon, je suis la vélocité d’équipe, mais uniquement pour prédire ce que je pourrai livrer à tel ou tel sprint/époque. Je reste donc sur la gestion du planning. Mais si on livre chaque jour ou a minima chaque quinzaine, livrer avec deux semaines de retard n’est pas dramatique.

Le squad gère lui-même sa performance : pair programming avec les nouveaux, cross-testing, code review. Ils se soutiennent et se donnent des feedbacks. Ça se voit pendant les standups, les rétros, où on communique en toute transparence — et même le client est convié, on partage les retours.

La culture du feedback est à haut niveau, chaque nouveau reçoit les retours de l’équipe et peut en donner sur le process, l’entreprise, moi-même. Résultat, deux issues : soit tu ne valides pas la période d’essai, soit tu es au niveau et on ne contrôle plus la performance.

Galen Low : Parfois, ce n’est pas trop intense ?

Julia Ryzhkova : Ça peut l’être, mais en général tout le monde est aligné. Si quelqu’un détecte un souci, tout le monde le voit et on se partage le feedback — je n’ai pas eu de problème marquant.

Galen Low : C’est dans la culture, ancré dès le recrutement. On intègre des gens déjà prêts à vivre ça, à recevoir et donner du feedback, pour que ça fonctionne en structure plate.

Julia Ryzhkova : Oui, c’est vraiment ce qu’on contrôle à l’embauche. Beaucoup de temps est investi : pour les chefs de produit, on organise une journée de travail en binôme sur un vrai problème, pour voir la réaction au feedback. C’est un gros investissement, mais au final, chacun sait si la culture match, au-delà de la technique. Résultat top.

Galen Low : Ce qui prouve l’investissement côté entreprise. Beaucoup font des tests arbitraires, mais là c’est du concret : le product manager et un décideur C-level passent du temps à collaborer pour juger la dynamique de travail en vrai.

Tout le monde ne peut pas, mais c’est très efficace quand il faut être sûr du fit. Et du côté candidat ?

Julia Ryzhkova : Pour le candidat, c’est aussi un investissement : au lieu de perdre trois mois d’essai avant de réaliser que la boîte ne leur convient pas, ils le savent rapidement. Ce n’est pas la journée entière pour tous les métiers, cela peut être deux à quatre heures selon le poste. Mais il faut ouvrir le contact.

Galen Low : Ça a du sens. Autre sujet : en tant que cheffe de produit, quand tu dois changer la roadmap, modifier le backlog ou le calendrier, comment équipes réagissent-elles au changement ?

Julia Ryzhkova : Probablement tu seras surpris, mais il ne se passe… rien. Je peux retirer des tâches du sprint, en ajouter, expliquer le contexte — par exemple on a dû faire ça récemment, et on en discute, point. Je peux changer le backlog même en cours de sprint, tant que cela reste raisonnable. On fait une réunion pour estimer et synchroniser, et voilà… Je ne chamboule pas la roadmap trop souvent, je la révise une fois par mois pour y intégrer les insights et nouvelles données.

L’équipe connaît la vision et participe aux séances stratégiques avec les C-level pour remonter les alertes ou réajuster si besoin. Ils font même leurs propres remontées — j’ai eu le cas d’un ingénieur qui nous a informés qu’après le changement de notre modèle tarifaire, une plateforme intégrée avec de nombreux clients avait ajusté ses propres prix, mettant nos modèles en incohérence. On a pu corriger nos limites grâce à lui.

C’est incroyable d’avoir ce type de remontée du terrain.

Lorsque j’ai changé d’outil de gestion pour la 3e fois en 6 mois (Trello –> Coda –> Pivotal Tracker –> JIRA), l’équipe a juste demandé 15 minutes de formation et s’est adaptée. Ils sont ouverts au changement, car ils comprennent le pourquoi pour le produit/le client.

Galen Low : C’est fou ! Savoir changer d’outil trois fois en six mois sans râler, ça dit beaucoup… L’esprit « product mindset » s’exprime là : même les devs/designers/marketeurs comprennent le business et s’adaptent pour servir l’utilité client ou business. Ce n’est pas « on me fait changer de cap pour rien », mais « on le fait pour de bonnes raisons ».

Le produit, c’est le changement lui-même. En vrai, la gestion, c’est anticiper l'avenir, planifier en étant prêt à pivoter, justement parce que tout bouge constamment !

Julia Ryzhkova : Exact, d’ailleurs récemment un dev m’a dit qu’il ressentait la stabilité car on avait la visibilité sur le backlog pour plusieurs sprints, même s’il savait que tout pouvait changer. Ce qui compte, c’est d’avoir une vision et de la partager, même si le comment évolue. Ça apporte le sentiment de sécurité nécessaire.

Galen Low : Oui, c’est la confiance par la transparence. Les gens voient la roadmap, le backlog, connaissent la vision globale, et cela suffit à créer l’indépendance et la stabilité. J’aime beaucoup.

Je reviens à un point : on parle beaucoup d’agilité logicielle, de backlog, de vélocité, etc. Mais tu penses que ce modèle fonctionne seulement pour le soft en Agile ? Ou pour tout type d’équipe pluridisciplinaire ?

Julia Ryzhkova : Il faut être Agile, oui — mais au sens du manifeste Agile qui ne parle pas que de logiciel, non ?

Toutes nos squads fonctionnent ainsi, y compris marketing, finance, opérations. Je leur ai appris à estimer, à faire du grooming, à gérer une roadmap, à utiliser le Kanban, à mesurer la vélocité… Ce sont des approches dont tout le monde peut profiter.

Galen Low : À creuser dans un autre épisode ! Car beaucoup voudraient leur équipe marketing/finance aussi Agile que les devs. Tu casses le cliché : Agile n’est pas réservé au code, c’est la capacité à s’adapter au changement, ce dont n’importe quelle équipe peut bénéficier.

Julia Ryzhkova : Oui, par exemple l’équipe d’ingénierie travaille en Scrum, les designers aussi, mais le marketing en Kanban – c’est plus adapté. Tout ça reste Agile !

Galen Low : Ce qui est logique, car l’opérationnel continue. Bon, passons au côté épineux : personne ne dit qu’un modèle est parfait. Pour ceux tentés de passer à l’auto-gestion, peux-tu dire ce qui, parfois, dysfonctionne dans ce modèle ?

Julia Ryzhkova : Question tricky. Disons que parfois un squad n’a pas la visibilité sur ce qui se passe ailleurs. Par exemple, on avait deux produits internes, Mailtrap et Coupler.io. L’équipe de dev de Coupler.io livrait plein de nouveautés que la petite équipe marketing n’arrivait pas à couvrir côté contenu. Sur Mailtrap, c’était l’inverse. La direction a donc décidé de transférer une partie des marketeurs de Mailtrap vers Coupler.io, et une partie des devs de Coupler.io vers Mailtrap. Ça, le squad ne peut le détecter ni décider seul, il faut une vision macro, donc une intervention du management.

Galen Low : Qui prend ce type de décision ? Toi, les ops… ?

Julia Ryzhkova : C’est niveau C-level. Moi, je remonte le besoin pour mon produit, pareil pour Mailtrap, et les décideurs tranchent car ils voient l’ensemble et sont peu impliqués dans les détails du quotidien — ce qui leur donne la hauteur nécessaire.

Galen Low : Cette réallocalisation était permanente ou temporaire ?

Julia Ryzhkova : On peut soit embaucher, soit switcher temporairement — là, c’est un mélange des deux. Mais cela ne nous dérange pas, comme je l’ai dit, on est Agile. Rebasculer une équipe sur un autre produit pour six mois ou un an n’est pas un problème.

Galen Low : Mais tout ça vient d’un souci de synchronisation entre squads, non ? À quelle fréquence l’équipe marketing et l’équipe technique se parlent-elles ?

Julia Ryzhkova : Ça dépend, mais on a au minimum la démo où les devs présentent les livraisons et une réunion hebdo où je partage les sorties/roadmap à venir côté dev comme côté marketing. Il y a un process d’input management : chacun peut formuler une demande à l’autre équipe, révisée chaque semaine, priorisée ou mise en attente.

Le marketing propose d’améliorer la homepage, le dev demande une nouvelle maquette d’email — tout cela est intégré/planifié ensemble.

Galen Low : Super intéressant. On n’a pas parlé de géographie et fuseaux horaires. Vos squads sont dispersées dans le monde. Faut-il être hyper efficace pour que ça marche en distribué ?

Julia Ryzhkova : Je dirais l’inverse : le remote permet justement plus d’efficience. Parfois, c’est difficile de synchroniser l’Argentine et la Thaïlande, certes, mais c’est mineur.

La majorité travaille à distance depuis 15+ pays, mais avec docs partagées et channels publics, tout est super organisé. Le travail asynchrone fait qu’on n’a pas besoin d’autant de réunions ou de planifier sur des créneaux impossibles !

Galen Low : C’est fondamental : asynchrone ne veut pas dire jamais de réunions mais qu’on se concentre sur l’essentiel, chacun peut consulter les docs en différé. Et « remote » n’est pas juste « télétravail » : la transparence documentaire est capitale.

Y a-t-il une sorte de rejet du management de projet dans ces squads auto-gérées ? Est-ce un gros mot ?

Julia Ryzhkova : Non, pas de rejet. On aime expérimenter, il n’y a aucune obligation. Rien ne sert d’imposer un vrai cursus PM à tout le monde. On préfère partager les points clés lors des guildes, en fonction des besoins. Si quelqu’un souhaite se former plus, il utilise son budget formation, mais c’est du « just in time ».

Galen Low : J’aime ce partage artisanal des compétences, sans chercher à faire de tout le monde un chef de projet ni de chaque chef de projet un dev. L’idée, c’est d’apprendre chacun des autres.

Pour finir, la question phare : tu as mené un PMO, tu es aujourd’hui plus stratégique en tant que cheffe de produit, penses-tu que les squads auto-gérées sont le futur du management de projet ?

Julia Ryzhkova : Je pense que c’est l’avenir des entreprises produit qui réussissent.

Les équipes auto-gérées permettent au chef de projet de se concentrer sur la stratégie, le produit ou le client. C’est là qu’on atteint enfin le nirvana du « important mais pas urgent » — cet espace qu’on a trop rarement. L’équipe gère l’urgent et tu peux enfin te consacrer à l’essentiel.

Mais bien sûr, tous ne sont pas prêts à être auto-gérés, surtout les juniors. Certains nécessitent plus d’encadrement, même au niveau senior parfois. Donc il y aura toujours de la place pour le management classique de projet.

Mais pour obtenir des résultats ambitieux sur un produit, il faut atteindre ce degré d’auto-gestion qui libère le chef de projet pour la stratégie et l’amélioration globale, au lieu de régler chaque détail.

Galen Low : Très intéressant. Ce que je retiens : l’important contre l’urgent. Beaucoup de chefs de projet classiques souffrent de ne jamais avoir le temps pour le stratégique. Mais il ne s’agit pas de supprimer leur poste, plutôt de l’élever et d’occuper ce créneau.

Julia Ryzhkova : La gestion de projet reste cruciale. Mais avec une équipe auto-gérée, on peut se permettre d’être moins dans l’opérationnel terrain et plus dans l’anticipation, le « quoi faire » plutôt que le « comment ».

Galen Low : C’est ça, élever la fonction et être proactif.

Julia, toutes ces idées sont super. Pour moi, l’essentiel c'est la culture « mindset produit ». Ce n’est pas juste penser au produit dans une logique cycle de vie/lancements, mais être ouvert à l’adaptabilité : comprendre que tout change tout le temps, et que l’équipe doit répondre au changement en comprenant son sens, pas en le subissant.

Votre job, votre backlog, vos outils de gestion, tout peut changer trois fois en un an, mais c’est le mindset qui compte — et c’est clé dans des équipes auto-gérées.

Dernière question, un conseil pour une organisation qui voudrait tester ?

Julia Ryzhkova : N’essayez pas, faites-le. Commencez par une petite équipe, donnez-lui l’autorité et regardez les résultats. Les résultats viendront. Quand vous verrez les bénéfices, vous aurez envie de propager ce modèle dans toute l’entreprise. Il faut juste commencer avec les personnes qui incarnent cet état d’esprit.

Galen Low : Merci Julia d’avoir partagé tout ça. Ce fut passionnant d’apprendre comment vous fonctionnez chez Railsware, comment les squads auto-gérées prennent forme, comment l’Agile est mis en œuvre dans le studio produit.

J’espère que nos auditeurs sont repartis avec de bonnes idées pour insuffler une culture d’auto-gestion, sans se sentir menacés pour autant ! Reviens-nous parler de l’intégration de l’IA dans Coupler.io, ce sera passionnant…

Julia Ryzhkova : Avec plaisir, j’espère pouvoir vous raconter tout cela bientôt.

Galen Low : Merci beaucoup, génial.

Julia Ryzhkova : Merci. C’était vraiment agréable d’échanger, ce sont des sujets qui m’inspirent beaucoup et j’espère que cela inspirera d’autres personnes à tenter l’aventure.

Galen Low : Merci encore.

Julia Ryzhkova : Merci !

Galen Low : Et vous, qu’en pensez-vous ? Les équipes auto-gérées sont-elles l’avenir, ou ont-elles des limites qui les rendent inadaptées à certains contextes ?

Racontez-nous vos expériences : quelle est l’équipe projet la plus autonome avec laquelle vous avez travaillé, et comment cela s’est-il passé ? À l’inverse, quelles sont vos pires frustrations comme chef d’orchestre plus que stratège ? Partagez en commentaire.

Et pour perfectionner vos talents de leader stratégique de projet, rejoignez notre collectif !

Rendez-vous sur thedigitalprojectmanager.com/membership pour intégrer une communauté qui partage ses connaissances, résout des problématiques complexes, et façonne l’avenir de notre métier — ensemble.

Des templates robustes, des sessions de formation mensuelles, des événements communauté et groupes de « mastermind » : être membre, c’est bénéficier de plus de 1000 pairs à vos côtés pour naviguer dans votre carrière de delivery digital.

Si vous avez aimé cet épisode, abonnez-vous et restez connectés sur thedigitalprojectmanager.com

À bientôt et merci de votre écoute.