01
Friction
Pour l’équipe produit
L’intention produit se perdait entre les arbitrages initiaux, les tickets et les reviews.
Critères d’acceptation flous
Arbitrages réouverts
Décisions difficiles à préserver
B2EWeb & MobileGovernanceProduct Ops
Transformer la delivery en un système vérifiable
Lorsque Enphase nous a rachetés en 2022, nos équipes ont dû passer d’une delivery startup à une organisation produit plus globale. J’ai structuré un système de delivery partagé entre product, design et dev pour réduire l’interprétation, le rework et les écarts design/dev.
Challenge
Mon rôle
PilotéContribuéProduct Ops strategyDesign systemGovernanceUX architectureQuality frameworkTeam enablementDesign mentoringDeliveryUser testing
Année
Planning
Outils
Comprendre le problème
Méthodologie
Audit du workflowAnalyse de ticketsAnalyse des reviewsCartographie des artefactsEntretiens avec les parties prenantes
Clarifications après démarrage dev
59%Part des tickets revenant en discussion après le démarrage du développement.
Tickets avec plus d’un cycle de review
40%Part des tickets nécessitant plus d’un cycle de correction design/dev.
Trop de décisions restaient ouvertes après le démarrage du développement
Décisions implicites dans les tickets
38%
États
manquants
31%
Flows
ambigus
18%
Critères
flous
16%
Re-use
absent
7%
Contrainte
technique
Le rework venait surtout de décisions restées implicites.
61%
Reviews multi-métier
Part des tickets recevant au moins deux types de feedback : produit, design ou engineering
Les équipes ne partageaient pas toujours la même définition du livrable
Comment rendre les décisions, critères et responsabilités vérifiables avant le développement ?
02
Friction
Pour le design
Les maquettes montraient l’interface cible, mais pas toujours les règles nécessaires pour l’implémenter.
États incomplets
Edge cases absents
Patterns réinventés
03
Friction
Pour les dev
Les développeurs devaient deviner les comportements, les états et les critères qualité attendus.
Implémentations divergentes
Boucles de review
Décisions implicites
Exploration et solution
01
Renforcer la documentation
Centraliser règles, composants et guidelines dans un hub consultable par les équipes.
Rapide à lancer
Facile à consulter
Peu d’adoption réelle
Décisions encore tardives
Exploré
02
Renforcer les reviews
Ajouter plus de contrôles en fin de cycle pour détecter les écarts avant livraison.
Détecte les écarts
Améliore la qualité
Arrive trop tard
Ajoute du rework
Exploré
03
Créer une delivery partagée
Aligner product, design et dev autour de gates, artefacts et critères qualité communs.
Aligne plus tôt
Réduit l’interprétation
Demande adoption
Plus exigeant au départ
Sélectionné
Découvrez les 4 décisions clés que j'ai prises
Delivery
Déplacer la friction avant le développement
Parce que les décisions réouvertes en review coûtaient plus cher que les arbitrages faits en amont.
Workflow montrant le déplacement des décisions product, design et engineering avant le développement.
Coût évité
- Décisions réouvertes tard
- Rework après développement
Coût accepté
- Plus d’effort en amont
- Process perçu plus lourd
Gouvernance
Clarifier qui décide quoi
Parce qu’une bibliothèque unique mélangeait décisions globales, composants, usages produit et responsabilités.
Architecture du design system séparant foundations, composants, usages produit et responsabilités de gouvernance.
Coût évité
- Décisions dispersées
- Contributions non contrôlées
Coût accepté
- Architecture plus exigeante
- Contribution plus encadrée
Qualité
Rendre la qualité vérifiable
Parce que les reviews arrivaient trop tard et reposaient trop souvent sur des opinions différentes.
Handoff package et checklist de review permettant de réduire les interprétations pendant le développement.
Coût évité
- Validations subjectives
- Critères variables
Coût accepté
- Tickets plus complets
- Reviews plus exigeantes
Adoption
S’appuyer sur des relais techniques
Parce qu’un système partagé ne pouvait pas être adopté durablement s’il restait porté uniquement par le design.
Modèle d’adoption montrant comment les relais techniques aidaient les équipes à utiliser le système.
Coût évité
- Adoption design-only
- Usage superficiel
Coût accepté
- Temps senior dev
- Adoption progressive
Les impacts
Le système a rendu la delivery plus prévisible : moins de décisions réouvertes, moins de rework tardif et des critères qualité plus vérifiables.
Les décisions étaient moins réouvertes après le démarrage dev
l’alignement produit, design et dev arrivait plus tôt
Les reviews demandaient moins de corrections tardives
les critères qualité étaient explicités avant l’implémentation
La qualité dépendait moins des échanges informels
handoff, checklist et gouvernance rendaient les attentes vérifiables
Clarifications après démarrage dev
59%
31%
Avant / Après
Moins de décisions étaient réouvertes après le démarrage du dev.
Tickets avec plus d’un cycle de review
40%
18%
Avant / Après
Les tickets demandaient moins d’allers-retours en review.
Reviews multi-métier
61%
34%
Avant / Après
Les équipes partageaient plus souvent la même définition du livrable.
Gains sur les écrans couverts
Avant / Après
3h30
1h15
12h
5h
5h
2h
Les gains étaient surtout visibles sur les écrans couverts par le système.
Rétrospective
Optimiser chaque équipe séparément
NE PLUSOptimiser les passages entre équipes
MAIS PLUTÔTCorriger l’alignement en review
NE PLUSCréer les conditions d’alignement avant le dev
MAIS PLUTÔTPenser qu’un système s’adopte seul
NE PLUSConstruire l’adoption avec ses futurs utilisateurs
MAIS PLUTÔT
