91 lines
3.1 KiB
Markdown
91 lines
3.1 KiB
Markdown
# Process Produit
|
|
|
|
Les méthodes et pratiques opérationnelles du quotidien d'une équipe produit.
|
|
|
|
---
|
|
|
|
### Discovery vs Delivery
|
|
|
|
**Deux phases distinctes** du travail d'un PM :
|
|
|
|
**Product Discovery** (trouver quoi construire) :
|
|
- Comprendre les besoins utilisateurs
|
|
- Tester des hypothèses rapidement (prototypes, interviews)
|
|
- Valider avant de coder
|
|
- Outils : user interviews, prototypes, A/B tests, smoke tests
|
|
|
|
**Product Delivery** (construire ce qu'on a validé) :
|
|
- Développer les features validées
|
|
- Gérer le sprint, les specs, les tickets
|
|
- Livrer en production
|
|
- Outils : sprints agiles, roadmap, backlog
|
|
|
|
> L'erreur classique : aller directement en Delivery sans Discovery → construire des features que personne ne veut.
|
|
|
|
---
|
|
|
|
### Feature Flag
|
|
|
|
Un **Feature Flag** (ou feature toggle) est un mécanisme technique qui permet d'**activer ou désactiver une feature sans déployer de nouveau code**.
|
|
|
|
**Usages** :
|
|
- **Rollout progressif** : activer la feature pour 1% des users, puis 10%, puis 100%
|
|
- **A/B testing** : groupe A voit la feature, groupe B non
|
|
- **Kill switch** : désactiver immédiatement si bug critique en prod
|
|
- **Beta users** : donner accès à certains clients avant tout le monde
|
|
|
|
> Permet de découpler le déploiement technique de la mise en production commerciale.
|
|
|
|
---
|
|
|
|
### A/B Test
|
|
|
|
Un **A/B test** est une **expérience contrôlée** où deux versions d'une même chose sont comparées auprès d'utilisateurs réels pour déterminer laquelle performe mieux.
|
|
|
|
**Principe** :
|
|
- Groupe A (contrôle) : version actuelle
|
|
- Groupe B (variante) : version modifiée
|
|
- On mesure une métrique clé sur les deux groupes
|
|
|
|
**Exemple** :
|
|
- A : bouton "S'inscrire" en gris
|
|
- B : bouton "S'inscrire" en vert
|
|
- Résultat : B convertit 15% de plus → on déploie B
|
|
|
|
**Règles d'or** :
|
|
- Tester **une seule variable à la fois**
|
|
- Attendre la **significativité statistique** (ne pas arrêter trop tôt)
|
|
- Définir la métrique de succès **avant** de lancer le test
|
|
|
|
---
|
|
|
|
### Roadmap
|
|
|
|
La **Roadmap produit** est la **représentation visuelle du plan à moyen terme** : ce qui sera construit, dans quel ordre, et pourquoi.
|
|
|
|
**Deux types** :
|
|
- **Timeline roadmap** : features associées à des dates (risqué, souvent inexact)
|
|
- **Now / Next / Later** : horizon temporel souple, plus honnête sur l'incertitude
|
|
|
|
**Ce que la roadmap n'est PAS** :
|
|
- Un contrat → les priorités changent
|
|
- Une liste exhaustive de tout ce qu'on va faire
|
|
- Un backlog détaillé de tickets
|
|
|
|
> La roadmap répond à "où allons-nous et pourquoi", pas à "comment on y va".
|
|
|
|
---
|
|
|
|
### Sprint
|
|
|
|
Un **Sprint** est une **période de travail courte et fixe** (généralement 1 à 2 semaines) durant laquelle l'équipe s'engage à livrer un ensemble défini de fonctionnalités.
|
|
|
|
**Cérémonies classiques** (méthode Scrum) :
|
|
- **Sprint Planning** : choisir ce qu'on fait ce sprint
|
|
- **Daily Standup** : point quotidien de 15 min (blocages, avancement)
|
|
- **Sprint Review** : démo de ce qui a été fait
|
|
- **Retrospective** : améliorer le process de l'équipe
|
|
|
|
---
|
|
|
|
**Tags** : #product #process #agile #discovery #delivery #roadmap #sprint
|