À périmètre variable

« Cela va durer six mois, vous aurez un super produit, mais nous ne savons pas encore quelles fonctionnalités il y aura dedans… »

C’est ce que nous disons au lancement des nouvelles startups d’État. Pour ceux qui sont habitués à rédiger des cahiers des charges cela fait tout drôle. D’habitude, ils donnent une liste de fonctionnalités à un prestataire qui va développer en respectant « les coûts et les délais », et livrer un produit pas terrible. Sauf qu’il faut souvent payer encore un peu plus, parce qu’il y a eu des imprévus.

De la même manière que les physiciens savent qu’il y a un lien entre la température, la pression et le volume d’un gaz parfait (à quantité de matière constante), les habitués du développement logiciel savent qu’il y a une relation entre la qualité, les délais et le périmètre d’un projet (à coût constant). Ainsi, si les délais et le périmètre sont fixés, c’est forcément au détriment de la qualité.

Nous faisons donc le choix (et nous ne sommes pas les seuls) de construire des produits selon des standards de qualité élevés, et dans des délais serrés. La seule solution pour réussir à faire cela, c’est de rendre le périmètre variable. De limiter le nombre de fonctionnalités que nous allons livrer.

L’avantage, c’est que limiter le périmètre initial est une bonne chose. En effet, nous n’apprenons qu’en faisant. Avec de vrais utilisateurs. En testant des hypothèses en conditions réelles. N’est-ce pas la base de la méthode scientifique ? Ceux qui affirment pouvoir tout anticiper sont au mieux naïfs.

Et vous, quels paramètres considérez-vous comme variables ou fixes ?