Carte Context Mapping #8 : Customer/Supplier Development

📇 Carte #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 💭

  1. Avez-vous vraiment entendu les besoins du downstream ?
  2. À quelle fréquence vous collaborez sur l’interface ?
  3. Qui arbitre si les besoins entrent en conflit ?
  4. Comment mesurez-vous que l’interface répond aux besoins ?
  5. 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:

"Nous on a plusieurs entrepôts.
Nous voudrions:
1. Synchroniser l'inventory en temps-réel
2. Gérer des SKUs avec multi-variantes
3. Supporter backorder
4. Reporter le inventory par warehouse"

Platform responds:

"OK. Nos systèmes standards on pas tout ça.
Parlons de comment l'implémenter.
Ça sera bon pour d'autres merchants aussi?"

Phase 2: Co-Design Interface

Platform proposes:

POST /api/v1/inventory/sync
{
  "merchantId": "...",
  "warehouse": "SF-1",
  "sku": "...",
  "quantity": 100,
  "reserved": 10
}

GET /api/v1/inventory/levels?warehouse=SF-1

Merchant feedback:

"C'est bon. Mais on veut aussi:
- Batch upload (CSV)
- Notifications quand stock bas
- Forecast de demand"

Platform decides:

"Batch et notifications OK.
Forecast: c'est trop custom, on te donne les données,
tu le calcules de ton côté (Anticorruption!)"

Phase 3: Implement Together

Sprint 1: Inventory Sync

Platform: implement sync API
Merchant: integrate dans son système
Testing: "Ça marche! Mais il manque le field X"
Platform: ajoute X
Result: Perfect API pour merchant

Sprint 2: Batch & Notifications

Platform: webhooks pour notifications
Merchant: configure son side
Integration test: OK!

Sprint 3: Report & Forecast

Platform: export API format standard
Merchant: crée sa propre logic forecast
Result: everyone happy

Escalation & Conflict Resolution

Scenario: Feature Request Mismatch

Merchant: "Nous voulons feature X"
Platform: "C'est ultra-spécifique à toi, coûteux"
    ↓
Option 1: Compromise
  "On fait une version simplifiée pour tous"
    ↓
Option 2: Business Decision
  "Combien ça vaut pour toi ? On peut la vendre ?"
    ↓
Option 3: Merchant-Owned Solution
  "Tu fais ton extension, on supporte via API"

Success Metrics

For Upstream

  • ✓ Customer satisfaction (NPS > 8)
  • ✓ Feature adoption (% merchants using it)
  • ✓ Support tickets (time to resolution)
  • ✓ Repeat business

For Downstream

  • ✓ Time-to-value (reduced)
  • ✓ Feature readiness (exactly what needed)
  • ✓ Support quality (quick help)
  • ✓ Interface stability (can plan)

Intégration avec Context Mapping

Evolution Path

Upstream/Downstream (simple)
    ↓
Customer/Supplier Development
    ↓
Published Language (si trop de customers)
    ↓
ou
    ↓
Anticorruption Layer (si ça ne marche pas)

Checklist de Mise en Place ✓

  • Vous avez clairement identifié le customer et supplier
  • Il y a une communication régulière (bi-weekly minimum)
  • Les besoins sont documentés et partagés
  • Vous avez un processus de feedback et d’intégration
  • Responsabilités sont claires (qui build quoi)
  • Vous avez des métriques de succès

Ressources et Lectures

  • Domain-Driven Design par Eric Evans - Customer/Supplier Development
  • Team Topologies - Enabling Teams & Interaction
  • DDD Crew - Context Mapping

Notes de Facilitation pour l’Atelier

Animation

  • Demandez : “Vous avez vraiment écouté le customer ?”
  • Testez : “Comment vous itérez ensemble ?”
  • Documentez : “Quel est le process de feedback ?”

Pièges Communs

  • ⚠️ Pas d’écoute réelle : supplier impose sa vision
  • ⚠️ Trop de customization : interface devient unmaintainable
  • ⚠️ Pas de processus : feedback aléatoire
  • ⚠️ Pas de doc : “C’était comment à nouveau ?”

Questions Provocatrices

  • “Vos customers se sentent-ils écoutés ?”
  • “Combien de temps vous passez vraiment ensemble ?”
  • “Y a-t-il trop de divergence dans les features ?”
  • “Faudrait-il passer à Published Language ?”