Estimer un MVP sans inventer un prix

Chiffrez la décision avant la liste de fonctions

Commencez par la décision que le MVP doit éclairer. Il peut devoir montrer qu’un utilisateur comprend un parcours, qu’une intégration est faisable ou qu’un petit groupe revient à une action utile. Ces questions demandent des preuves différentes. Une liste d’écrans sans décision peut grandir sans devenir recevable. Définissez utilisateur, problème, plus petite version, non-objectifs et suite donnée au résultat.

Séparez prototype, pilote privé en production et produit public. Un prototype peut utiliser données temporaires et étapes manuelles pour répondre à une question d’interaction. Un pilote réel demande identité, permissions, supervision, reprise et support adaptés. Une sortie publique ajoute éventuellement stores, juridique, accessibilité, analytics et opérations. Appeler chaque étape MVP masque la frontière de coût et empêche de comparer les offres.

Comptez interfaces, états et responsabilités

Chaque système externe ajoute plus qu’un appel API. Estimez authentification, permissions, limites, erreurs, reprises, doublons, accès de test, revue fournisseur et changements futurs. Un import ajoute mapping, validation, correction, confidentialité et suppression. Le mobile ajoute signature, fiches store et dépendances de revue. Demandez quels faits sont déjà vérifiés et quelles hypothèses nécessitent une tâche de découverte.

Les états utilisateur comptent autant que les écrans. Incluez vide, chargement, hors ligne, expiré, rejeté, partiel, non autorisé et récupération. Notez qui fournit contenu, comptes, revue sécurité, validation design et réponses aux fournisseurs. Le travail du client reste dans le calendrier même s’il n’est pas facturé par le prestataire. Une estimation crédible nomme ces dépendances.

Choisissez preuves et niveau de qualité

Définissez la recette selon le risque. Un outil interne simple peut demander des tests représentatifs et une reprise manuelle. Une app grand public ajoute appareils, accessibilité, confidentialité, stores et support. Un système traitant données sensibles ou actions importantes exige des accès, journaux, revues et incidents plus solides. Ces obligations changent l’effort même si l’interface semble petite.

Listez les environnements et preuves: contrôle local, preview, staging, accord fournisseur et observation de production ne sont pas identiques. Décidez ce qui doit être automatisé, revu manuellement et signé. Un test réussi ne prouve ni adoption ni revenu. Les métriques produit ont leur plan de mesure et exigent du temps après sortie. Cette séparation évite de tarifer des promesses business comme si l’ingénierie les contrôlait.

Estimez avec fourchettes et règles de changement

Découpez découverte, design, réalisation, intégration, vérification, sortie et transmission. Pour chaque lot, écrivez hypothèses, dépendances, propriétaire et preuve de recette. Utilisez une fourchette quand l’information manque et nommez la décision qui la resserrera. Une marge correspond à des incertitudes nommées, pas à un pourcentage caché. Comparez les propositions par inclusions et exclusions, pas uniquement par total.

Convenez de la gestion du changement. Un processus utile consigne le nouveau fait, son effet sur les preuves, les alternatives et le décideur avant de changer délai ou coût. Protégez la petite version en déplaçant l’optionnel vers des décisions ultérieures. Si le budget est la contrainte ferme, réduisez explicitement périmètre ou ambition de preuve. Ne préservez pas une liste impossible en supposant du travail gratuit.

Incluez lancement, maintenance et sortie

Le coût de construction n’est pas le coût d’exploitation. Ajoutez hébergement, fournisseurs, données, stores, supervision, support, sécurité, sauvegardes et incidents selon le cas. Identifiez qui suit dépendances et plateformes après lancement. Un build peu cher devient coûteux sans responsable de reprise ou de prochaine version. Un produit plus petit avec des opérations claires peut être le meilleur investissement.

Exigez propriété des dépôts et comptes, instructions de déploiement, inventaire des environnements, limites connues et exercice de transmission. Décidez entre embauche interne, support récurrent ou nouvelle mission bornée. Revoyez l’estimation après découverte et premières preuves en production. Le but n’est pas de prédire tout le produit, mais de rendre le prochain investissement compréhensible, borné et réversible.

Critères de décision

Posez les mêmes questions à chaque option avant de choisir.