📇 Carte Context Mapping #8 : Customer/Supplier Development
Vue Rapide
🎯 Objectif : Upstream co-concevoir des interfaces avec downstream
👥 Relation d’équipe : Upstream/Downstream (avec engagement)
📊 Couplage : Moyen (interface négociée)
Concept
L’équipe upstream et l’équipe downstream collaborent pour concevoir une interface optimale pour les deux.
Upstream Team Downstream Team
(Supplier) ↔ (Customer)
↓ Négociation ↓
Interface optimale
La philosophie : “Je fournisseur, tu es client. Parlons de ce que tu as besoin.”
Quand l’Utiliser ? ✅
- ✅ Vous avez un vrai client/fournisseur (asymétrique)
- ✅ Le downstream a des besoins spécifiques (pas un “molten mass”)
- ✅ L’upstream veut servir et écoute le downstream
- ✅ Communication régulière entre les deux teams
- ✅ L’interface peut évoluer progressivement ensemble
Exemples
- Backend ↔ Frontend : designer l’API ensemble
- Platform ↔ Tenant : customiser la plateforme pour tenants
- Library Publisher ↔ Library User : design API avec des usagers
- Data Provider ↔ Data Consumer : ajuster le format d’export
Quand l’Éviter ? ❌
- ❌ L’upstream a trop de downstream : pas de scalabilité
- ❌ Les downstream ne peuvent pas communiquer
- ❌ L’upstream ne veut pas investir dans la relation
- ❌ C’est une relation transactionnelle : plutôt Published Language
- ❌ Le downstream n’a pas de besoins particuliers
Questions Clés à se Poser 💭
- Avez-vous vraiment entendu les besoins du downstream ?
- À quelle fréquence vous collaborez sur l’interface ?
- Qui arbitre si les besoins entrent en conflit ?
- Comment mesurez-vous que l’interface répond aux besoins ?
- Comment évoluez-vous l’interface ensemble ?
Implications pour Upstream
Responsabilités
- ✓ Écouter les besoins du downstream
- ✓ Co-concevoir les solutions
- ✓ Fournir support et training au downstream
- ✓ Investir dans la relation
Avantages
- ✓ Client heureux : vous livrez exactement ce qu’il faut
- ✓ Feedback rapide : vous voyez les problèmes tôt
- ✓ Innovation ensemble : meilleures solutions
- ✓ Loyalty : downstream vous fait confiance
Risques
- ⚠️ Consommateur de temps : beaucoup de réunions
- ⚠️ Customization : interface devient complexe
- ⚠️ Dépendance : difficile de changer l’interface
- ⚠️ Expectations : si tu écoutes, les demandes augmentent
Implications pour Downstream
Responsabilités
- ✓ Articuler clairement vos besoins
- ✓ Participer activement à la conception
- ✓ Tester et valider rapidement
- ✓ Donner feedback constructif
Avantages
- ✓ Interface taillée pour vous : pas de Anticorruption Layer
- ✓ Influence : vos besoins façonnent l’interface
- ✓ Support : upstream veut vous aider réussir
- ✓ Alignement : you’re not a second-class citizen
Risques
- ⚠️ Dépendance : customization = tied to this supplier
- ⚠️ Complexité : interface devient complexe pour te servir
- ⚠️ Bloqué : si upstream dit non
Patterns de Collaboration
1. Sprint Collaboration
Sprint Planning:
├─ Upstream team
├─ Downstream team
└─ Planifier ensemble ce sprint
Sprint Execution:
├─ Upstream implémente feature
├─ Downstream testes dans son contexte
└─ Feedback
Sprint Review:
├─ Demo ensemble
├─ Validation
└─ Plannifier prochain sprint
2. Feature Request Process
Downstream has need:
"Je veux faire X, tu peux m'aider ?"
↓
Upstream analyzes:
"Voici 3 options"
↓
Co-decision:
"On fait option 2"
↓
Co-implementation:
"Voici le draft, test-le"
↓
Validation:
"Perfect ! merge"
3. Design Partnership
Upstream proposes interface:
"Voici mon design pour Feature X"
↓
Downstream reviews:
"J'aime A et B, mais C c'est pas bon"
↓
Iterate:
"Et si on faisait C comme ça ?"
↓
Agree et Implement
Exemple Concret : E-commerce Platform (Upstream) ↔ Merchant (Downstream)
Contexte
- Platform : e-commerce host
- Merchant : seller using the platform
- Merchant a besoin de custom inventory management
Phase 1: Listen to Customer
Merchant says: