Comment nous estimons un logiciel, et pourquoi nous donnons des fourchettes

Les clients demandent souvent un seul chiffre. Nous donnons une fourchette, et ce n’est pas une esquive : c’est la forme honnête de l’information disponible avant d’avoir compris le problème.

Estimer des heures, puis convertir en argent

Nous dimensionnons tout en heures d’ingénierie d’abord. Les heures, nous savons les raisonner à partir de l’expérience : nous savons à peu près ce que nous ont coûté les paiements ou la synchronisation hors ligne par le passé. Convertir en argent à la fin permet de discuter du taux journalier séparément.

La deuxième plateforme coûte moins cher que la première

Une erreur fréquente consiste à doubler le prix pour une deuxième plateforme. Au moment de la construire, le modèle métier, l’API et le design system existent déjà. Le coût supplémentaire se limite à l’interface et au travail propre à la plateforme, soit une fraction de l’original.

Ce qui fait réellement bouger une estimation

—Les intégrations avec des systèmes que nous ne maîtrisons pas, qui ont leurs propres délais.

—Les exigences de conformité découvertes tardivement, parce qu’elles contraignent l’architecture.

—Un processus de décision flou côté client — la cause de dépassement la plus fréquente, d’après notre expérience.

Resserrer, pas augmenter

Après un appel de cadrage, le chiffre doit devenir plus précis et non plus élevé. Si une estimation ne fait que monter une fois le travail engagé, c’est le signe qu’elle était optimiste pour emporter l’affaire. Nous préférons perdre l’affaire plutôt que de faire cela.