Lantern

Bêta

Bibliothèque · Définition · Intermédiaire

ChecklistÀ lire

Matrice build / no-build d'une fonctionnalité

Grille à 6 critères pour décider de développer, réduire, contourner ou refuser une fonctionnalité.

Pour qui, pour quand

PriorisationStrategyDeliverySaaSB2BPMPOEngineering Manager

En résumé

Six questions, une réponse écrite chacune. Si trois restent vides, la décision n'est pas mûre : ce n'est pas un non, c'est un « pas encore instruit ».

Méthode étape par étape

dans l'ordre, sans en sauter

  1. 01Problème : est-il observé chez plusieurs clients ?
  2. 02Segment : quelle part de la base est concernée ?
  3. 03Alternative : existe-t-il un contournement acceptable ?
  4. 04Coût total : build + maintenance + support + formation.
  5. 05Coût d'opportunité : qu'est-ce qui est décalé ?
  6. 06Sortie : comment saura-t-on qu'il faut l'arrêter ?

Questions à me poser

avant de te lancer

  • →Comment saurons-nous que c'était une erreur ?
  • →Qui maintiendra ceci dans 2 ans ?

Ce qui coûte cher

les pièges déjà vus sur ce sujet

Oublier le coût de maintenance dans l'équation.

Mes notes

ce que tu retiens, ton contexte

À jour · stocké dans ce navigateur

Situations couvertes

  • · Je dois décider s'il faut développer une fonctionnalité
  • · Je dois challenger une demande métier

Provenance

Delivery & arbitrage.docx

ajoutée le 2026-03-08

Mots-clés

buildarbitragedécisionfonctionnalitécoût

À lire juste après

ce que cette fiche appelle

Ce qui renvoie ici

des fiches qui citent celle-ci - c'est là que tes REX réapparaissent