Aller au contenu
cube4devcube4dev

Thèses · Du temps de développement plutôt qu’un périmètre fonctionnel

Un prix forfaitaire pour un produit nouveau, c’est parier qu’on sait d’avance ce qu’on n’apprend qu’en construisant.

Un prix forfaitaire exige un périmètre fonctionnel entièrement défini. Or, pour un nouveau produit, c’est précisément ce qui n’apparaît qu’au cours du développement.

C’est pourquoi je vends du temps de développement : une semaine, sans périmètre fixé à l’avance, sans reconduction automatique.

En détail

Ce qu’une semaine de développement peut accomplir

Une semaine de développement n'est pas une unité de mesure pour un nombre fixe de fonctions. Les produits logiciels diffèrent trop, pour cela, en complexité, en point de départ et en dépendances techniques.

Sur des tâches qui s'y prêtent, un système applicatif cohérent peut toutefois voir le jour en peu de cycles : avec une véritable interface, une logique métier centrale, un modèle de données, de la visualisation et une structure technique solide.

Sur des systèmes de bureau, temps réel ou de visualisation complexes, une semaine peut produire une tranche verticale qui ne contient pas toutes les fonctions ultérieures, mais possède assez d'architecture et de fonctionnalité réelles pour prendre les décisions produit centrales.

Lorsque les bases techniques sont déjà bien comprises, le périmètre peut aller nettement plus loin.

En cas de risques de recherche, d'intégration ou de performance, en revanche, c'est la clarification d'un seul problème technique critique qui peut avoir la plus grande valeur économique.

Le périmètre n'est pas standardisé. L'exigence, elle, l'est : le plus de réalité produit solide possible dans le temps de développement le plus court possible.

Ce qu’une semaine de développement peut accomplir →

Autres thèses