Project Team ou Product Team ?

La sentence est irrévocable !

Notre Contexte

Chez Younited Credit (YC pour les intimes), on est en perpétuelle évolution et 100% agile ; on privilégie au maximum les petites évolutions incrémentales d’organisations. Parfois, il nous arrive aussi d’avoir des changements plus structurants.

Initialement, nous avons testé une organisation où l’on mixait des Product Teams et des Project Teams.

Exemple : parmi la dizaine d’équipes qui existaient, il y avait une Product Team WebMarketing dont le rôle était de gérer les tunnels d’acquisitions Web de Younited Credit. Et en parallèle, il y avait une Project Team dont le rôle était de lancer de nouveaux pays et celle-ci pouvait avoir besoin de modifier ou de créer des tunnels d’acquisitions.

Depuis 2 ans, on a coupé les crédits de ce mode de fonctionnement en arrêtant de fonctionner avec des Project Teams pour s’orienter vers une organisation 100% Product Teams.

Pourquoi ce choix ? La communauté des Product Owner YC a décidé d’œuvrer sur le sujet pour mieux vous partager la problématique ; nos enseignements arrivent dans quelques lignes, accrédités de quelques anecdotes…

Un produit traversé par des Project Teams

Sur le papier, mixer des Project & Product Teams est simple :

1. Chaque équipe [Product ou Project] peut faire des modifications sur tous les produits YC.

2. Les développeurs des Project Teams doivent émettre une Pull Request (une PR, une revue de code) aux développeurs de la Product Team “Owner” du produit sur lequel la modification a été faite.

3. La Product Team “Owner” analyse la PR et ainsi garde la main pour accepter ou refuser qu’un développement soit intégré à son Produit.

Dans la pratique, les équipes nous partageaient des difficultés sur ce mode de fonctionnement.

D’où une volonté de comprendre cette complexité induite, aux antipodes d’une de nos valeurs : #makeitsimple.

”This is not a method!”

Le premier point a été de constater que chaque équipe (Project ou Product Team) travaillait avec sa propre méthode, et qu’en fin de compte les Produits pouvaient inclure des éléments créés avec différentes approches.

Chaque Project Team va appliquer sa propre méthode (qui est d’ailleurs unitairement cohérente dans un contexte donné), mais lorsque cumulées sur un même produit génèrent une complexité exponentielle.

Quand on parle de méthodes, cela peut adresser la quasi-totalité des interventions sur un projet : développement, test et les frameworks associés, mode de spécifications, monitoring, backlog…

Comme on le voit dans la scène ci-dessus, il devient complexe de garantir une cohérence technique, fonctionnelle et business sur nos produits.

Objection votre Owner !

Pour valider les évolutions proposées par les Project Teams, il fallait détricoter les Pull Request pour en comprendre le sens business associé et partager des priorisations. Cette responsabilité était déléguée aux développeurs, plutôt qu’aux PO & QA de la Product Team.

En conséquence, l’ownership du produit se retrouve dilué : les validations des PR se résument à une démarche sans vision globale du Produit et les régressions font l’objet de nombreux échanges.

Pour imager le propos, cela revient sensiblement à définir l’origine d’un pare-chocs abimé sur une voiture qu’on aurait loué auprès de 10 clients successifs…

Dans ce contexte, il était parfois compliqué de pouvoir valider des évolutions de produit tout en respectant les engagements de délais pris vis-à-vis de nos partenaires.

Clap de fin

Lorsque la Project Team a livré son projet, l’équipe est dissoute et chaque membre va se concentrer sur un nouveau challenge : l’ownership technique et le choix des solutions retenues sont remis en cause et les évolutions/correctifs de bugs s’avèrent onéreux, voire nécessitent un projet de refactoring.

Exemple d’échanges : la Feature X !

C’est là qu’apparaît l’importance de la propriété des Produits, couplée à une responsabilité forte, nécessaires pour promouvoir la notion de « développement durable ».

Le Product à l’Owner !

A partir de ces enseignements, nous allons pouvoir définir une nouvelle organisation en se basant sur quelques fondamentaux :

• Avoir un ownership et une responsabilité claire du périmètre applicatif.
• Maîtriser l’ensemble de la chaîne de valeur et distribuer les équipes en se basant sur des critères durables.
• Donner une mission à chaque équipe.

Clarifier les responsabilités : Un film d’Owner?

Nous avons partagé ce constat avec nos autres communautés de pratiques (Architecture, QA, Lead Devs, Dev Sec Ops) et il s’est avéré que le verdict était sans appel : on devait passer à une organisation 100% Product Team et arrêter les Project Teams.

Pour cela, il fallait alors privilégier la création de pools d’expertises, en désignant un ownership fort par typologie de produit. Pour définir nos produits, nous devions nous aligner sur les principales étapes de la chaîne de valeur (ou Customer Journey).

Si on reprend l’exemple du CRM, cela signifie que tous les projets impactant le CRM seront réalisés au sein d’une Product Team qui porte cette responsabilité : la vertu principale est d’avoir une approche globale permettant de standardiser les différentes méthodes traversant un produit.

Ceci passe par un mode d’organisation recentré sur les membres de la Product Team et non plus sur les participants aux différents projets :

1. Seul un des développeurs de la Product Team pourra faire évoluer le code sur le repository du produit.
2. Seul l’ingénieur QA de la Product Team pourra valider et automatiser les tests sur le module en question.
3. Seul le Product Owner pourra prioriser une feature sur son backlog Produit.

Chaque projet d’entreprise peut alors être porteur de besoins différents sur notre CRM en fonction de sa spécificité, mais la Product Team CRM en assure la cohérence et l’intégrité, en lien avec la vision Produit.

En conclusion, si la location ou la colocation s’apparentent bien au marché immobilier, ce n’est pas vraiment le cas pour notre écosystème ; paradoxalement, la pierre est bien plus agile que le logiciel informatique !

Une distribution des équipes basée sur des critères durables

Nous avons découpé le produit Younited Credit en N produits, en respect de la chaîne de valeur, chacun portant une responsabilité respective et précise.

Différentes approches peuvent être déployées sur ce concept mais nous en ressortons les recommandations suivantes :

1. L’identité des produits doit être durable et si possible robuste aux évolutions majeures de l’entreprise.
2. Avoir une architecture technique distribuée et découplée (micro-services, API…) permettant de séparer et dispatcher les applications au sein des équipes, contrairement à une architecture monolithique où le découpage se fait plus naturellement par feature.
3. Chaque team doit bénéficier d’une autonomie forte, que ce soit business sur les prises de décisions sur le produit ou sur des aspects techniques (choix sur le code et le framework utilisé, le test et les déploiements). Ces choix ont vocation à être partagés aux autres équipes si cela leur permet d’améliorer à leur tour leurs produits.
4. Dans un monde idéal, le casting d’une équipe doit être basé sur des profils ayant déjà œuvré dans un contexte produit similaire.
5. La stabilité du staffing est un élément clé pour développer un haut niveau d’expertise sur les produits, à la fois sur les aspects Business et Tech.

Force et Owner ! Votre mission si vous l’acceptez

Chaque équipe se voit confier une mission relative à une activité business de l’entreprise. En voici quelques exemples :

• Team Conversion : « Notre mission est de générer le plus grand nombre de demandes de crédit en optimisant en continu les tunnels d’acquisitions » #MakeItSimple
• Team Completion : « Notre mission est de fournir des dossiers de crédit complets en un temps record » #FasterIsBetter
• Team Transformation : « Notre mission est de prendre la meilleure décision d’octroi en un temps record » #InnovateOrDie
• Team Finance Flow : « Notre mission est d’automatiser et d’industrialiser les flux financiers pour permettre une scalabilité » #NoLimit
• Team Fixing & Funding : « Nous nous assurons que les actionnaires peuvent investir dans des fonds Younited » #ActAsAnEntrepreneur

L’Allemagne en avant-première

L’ouverture du service en Allemagne faisait office de premier test grandeur nature pour la mise en place de l’organisation full Product Team.

La nouveauté consistait dans la répartition de chaque besoin entre les différentes Product Teams : l’équipe Conversion s’occupait de mettre en place un tunnel d’acquisition younited-credit.de ; l’équipe Offer modifiait le module pricing pour mettre en place les grilles de prix Allemandes ; l’équipe Transformation se chargeait de mettre en place les spécificités d’octroi de crédit sur le Back Office Crédit et ainsi de suite…

Dans cette organisation, le lancement de l’Allemagne s’est déroulé dans les temps et avec le niveau de qualité attendu. Pour ce premier essai, nous avons appris qu’il était essentiel de structurer la synchronisation des équipes, notamment par la mise en place de :

• Pilotage Projet,
• Alignement Business,
• Coordination Technique,
• Coordination Qualité.

À la suite du succès rencontré et par la croissance de YC, nous avons continué à créer ces Product Teams au fur et à mesure pour arriver à un total de 12 équipes début 2021.

Conclusion

Cela a été un grand moment de bonheur de rédiger cet article 😊 nous espérons qu’il en est de même pour vous de le lire. Il n’existe pas de modèle idéal, mais nous pensons que ce modèle d’organisation full Product Team est un excellent mix entre 2 valeurs fondamentales de YC : #faster is better ; #act as an entrepreneur.