Un projet ne déraille presque jamais sur la technique. Il déraille sur un périmètre jamais écrit, un retour qui arrive trois semaines trop tard, ou une mise en service traitée comme une formalité. Voici comment on s'y prend pour éviter les trois.
On part de l'existant, pas d'une page blanche : ce qui tourne aujourd'hui, ce qui coince, ce que vous avez déjà essayé. On cherche l'enjeu réel derrière la demande, souvent différent de celui annoncé, et le point d'arrivée qui vaut la peine d'être visé en premier.
Un document de cadrage : périmètre, risques, budget, calendrier, et ce qui reste dehors.
Du temps : deux ou trois échanges, l'accès à ceux qui font le travail aujourd'hui.
Le produit se construit par jalons, et chaque semaine apporte quelque chose que vous pouvez ouvrir et critiquer. Pas de tunnel de trois mois au bout duquel on découvre qu'on s'est trompés : les écarts se voient tôt, quand ils coûtent encore peu à corriger.
Une version utilisable qui grandit, et un point hebdomadaire court sur ce qui avance et ce qui bloque.
Vos retours dans la semaine. Un produit attend rarement mieux qu'un avis qui arrive vite.
La mise en service est une étape du projet, pas ce qu'on bricole à la fin. Reprise des données existantes, bascule sans interrompre l'activité, surveillance de ce qui tourne, et transmission complète : dépôt, documentation, accès à votre nom.
Le produit en ligne, utilisé, et de quoi le reprendre sans nous.
Une personne disponible le jour de la bascule, et les décisions qui n'appartiennent qu'à vous.