Nous commençons toujours par rappeler qu’avant de nous connaître, beaucoup de nos clients ont vécu des projets informatiques avec des livraisons tardives, plus ou moins proches des attentes, attentes difficilement exprimées par ailleurs initialement. Ce terrain potentiellement conflictuel entre exécutants et décideurs est certainement l’arbre qui cache la forêt. Nous expliquons ensuite que chez Imagile les développeurs discutent en direct avec les clients dans l’objectif de rectifier constamment et ainsi détecter puis satisfaire les attentes.
La problématique vient en effet de l’approche naturelle à rechercher l’exhaustivité des attentes quelle que soit leur granularité. Dans cette approche ô combien classique, ce qui se définit aujourd’hui doit être ce qui doit être validé en fin de projet. C’est ce que l’on pourrait appeler l’effet tunnel.
La réalité est qu’entre la définition des besoins et la livraison, plusieurs mois peuvent s’écouler lors desquels les curseurs et périmètres peuvent être, à juste titre, re-priorisés voire remis en question. Il faut donc rester souple, rester agile et se concentrer sur l’utilité des livraisons.
Notre approche consiste à ne pas descendre trop bas dans la définition des périmètres à réaliser au cours du projet. Bien sûr, nous avons des paramètres incontournables comme la durée du marché, classiquement 3 ans, ou encore une enveloppe budgétaire à respecter.
N’oublions pas que le mieux n’est pas l’idéal. Nous partons du principe qu’est idéal ce qui est simple et fonctionne correctement. Nous fonctionnons donc par étapes, par versions livrées, testées et mises en production régulièrement.
La première version est toujours un socle solide qui remplit les services critiques à rendre. Les autres besoins sont précisément définis le moment venu, dans le délai réglementaire et l’enveloppe budgétaire ayant défini la procédure d’appel d’offres, et nourris par les retours des utilisateurs des versions précédentes.