Problématique - 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
Un système de delivery commun entre équipes
Après le rachat par Enphase, chaque handoff était réinterprété différemment selon l’équipe qui le recevait.
J’ai mis en place un système de delivery commun entre product, design et dev pour qu’on décide avant le développement, et qu’on arrête de corriger après.
Contexte
J’ai piloté
Workflow de deliveryQuality gatesDesign handoffGouvernance design systemAlignement transverseProduct/design/dev ops
Équipe
Product - Engineering - Design - Executive
Challenge
Faire scaler la delivery sans laisser chaque équipe réinterpréter ce qui devait être livré.
Année
2023
Planning
2 ans
Outils
Figma, Notion, Storybook, Jira, Flutter
Comprendre le problème
Exploration et solution
Renforcer la documentation
Centraliser règles, composants et guidelines dans un hub consultable par les équipes.
Promesse
Rapide à lancer / Facile à consulter
Raisons d’abandon
Peu d’adoption réelle / Décisions encore tardives
Renforcer les reviews
Ajouter plus de contrôles en fin de cycle pour détecter les écarts avant livraison.
Promesse
Détecte les écarts / Améliore la qualité
Raisons d’abandon
Arrive trop tard / Ajoute du rework
Créer une delivery partagée
Aligner product, design et dev autour de gates, artefacts et critères qualité communs.
Promesse
Aligne plus tôt / Réduit l’interprétation
Risque accepté
Demande adoption / Plus exigeant au départ
Décisions clés
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.
Coût évité
Décisions réouvertes tard
Coût évité
Rework après développement
Plus d’effort en amont
Coût accepté
Process perçu plus lourd
Coût accepté
Clarifier qui décide quoi
Parce qu’une bibliothèque unique mélangeait décisions globales, composants, usages produit et responsabilités.
Coût évité
Décisions dispersées
Coût évité
Contributions non contrôlées
Architecture plus exigeante
Coût accepté
Contribution plus encadrée
Coût accepté
Rendre la qualité vérifiable
Parce que les reviews arrivaient trop tard et reposaient trop souvent sur des opinions différentes.
Coût évité
Validations subjectives
Coût évité
Critères variables
Tickets plus complets
Coût accepté
Reviews plus exigeantes
Coût accepté
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.
Coût évité
Adoption design-only
Coût évité
Usage superficiel
Temps senior dev
Coût accepté
Adoption progressive
Coût accepté
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
Moins de décisions étaient réouvertes après le démarrage du dev.
59%
31%
Clarifications après démarrage dev
Tickets avec plus d’un cycle de review
Les tickets demandaient moins d’allers-retours en review.
40%
18%
Tickets avec plus d’un cycle de review
Tickets réouverts pour ambiguïté design
Moins de tickets retournaient en discussion pour des critères design non définis.
38%
15%
Tickets réouverts pour ambiguïté design
Gains sur les écrans couverts
Les gains étaient surtout visibles sur les écrans couverts par le système.
Rétrospective
Optimiser chaque équipe séparément
Optimiser les passages entre équipes
Corriger l’alignement en review
Créer les conditions d’alignement avant le dev
Penser qu’un système s’adopte seul
Construire l’adoption avec ses futurs utilisateurs
