Trop souvent, je vois des porteurs de projet le visage gris : les ESN qu’ils ont rencontré exigent un cahier des charges complet afin de leur donner un chiffrage.
Pourquoi certains demandent un cahier des charges
Certaines agences ou ESN demandent un cahier des charges complets à leurs potentiels clients, afin de leur remettre un chiffrage (souvent sans explications).
Cette approche est très lourdes pour les porteurs de projets, souvent sans culture technique, qui doivent écrire un épais document sans trop savoir comment.
Plusieurs difficultés se présentent :
- quelle forme
- comment rendre le document suffisamment « technico-compatible »
- comment être capable, si tôt dans le projet, d’en présenter toutes les facettes et détails
En réalité, cette approche est uniquement confortable pour les agences, car elle leur permet de ne pas s’impliquer dans le projet avec son porteur.
Elles prennent un document en entrée, donnent un chiffre en sortie, et si le projet se passe mal : tant pis, ça sera la faute du porteur et de son cahier des charges !
Pourquoi c’est une mauvaise voie à suivre
Si vous allez voir un artisan menuisier pour qu’il vous construise une nouvelle porte, va-t’il vous demander de revenir le voir avec des plans détaillés ?
Un cahier des charges, par définition, est un document exhaustif qui va décrire tous les grandes fonctionnalités, puis tous les détails de chaque fonctionnalité d’une application.
C’est un document qui fige donc l’intégralité du projet, alors même… que celui-ci n’a pas démarré !
Cet écrit présente plusieurs défauts majeurs :
- Il arrive bien trop tôt : pas de retours utilisateurs, pas de confrontation aux contraintes pour nourrir la réflexion
- Il est figé : un projet est vivant, il doit pouvoir évoluer en avançant
- Il est éloigné des perspectives techniques : les contraintes tech peuvent forcer un projet à évoluer, mais aussi lui ouvrir des perspectives !
- il est très coûteux à produire : soit en temps, soit en payant un prestataire
Avec un cahier des charges complet, on prend en sus le risque de tomber sur une agence qui va avoir une approche cycle en V : elle prend le document en entrée, et sort une app quelques mois plus tard… en ayant pris très peu de feedback en chemin !
L’approche Adostin
Cadrage produit
Avec Adostin, pas de cahier des charges : je vous demande une simple lettre d’intention, qui décrit brièvement votre idée et ses fonctionnalités principales, vos utilisateurs cibles et les objectifs de votre projet.
Comme le ferait un artisan, à partir de cette lettre d’intention, nous allons programmer un atelier de cadrage produit afin de définir :
- Objectifs du projet
- Utilisateurs cibles
- Concurrents et Avantages Compétitifs
- Fonctionnalités clefs d’une version minimale
- Contraintes techniques
En sortie de cet atelier, je vous fournis un document de synthèse qui décrit votre MVP : le produit minimum viable.
Après retours et améliorations de cette synthèse, je serai en mesure de vous fournir une estimation du nombre de cycle nécessaires à votre MVP, et à son chiffrage… mais avec une véritable connaissance de votre projet et de vos besoins grâce à ce que nous aurons construit ensemble !
Développement en itérations courtes (cycles)
Chez Adostin, le développement est découpé en cycles thématiques. Un cycle peut être court, moyen ou long (~8 jours).
Chaque cycle se concentre sur un spécifique.
Même si un cycle est long, plusieurs livrables seront fournis au fil des développements afin de recueillir du feedback progressivement, et pouvoir le prendre en compte au plus vite.
L’objectif derrière cette approche est de s’adapter durant l’évolution du projet, et de livrer aussi souvent que possible afin de recueillir des retours utilisateurs.
Une fonctionnalité prévue au départ peut ainsi finalement être abandonnée, au profit d’une idée devenue plus pertinente au vu des usages.
C’est également un bon moyen d’éviter les dérives, et de s’assurer que les coûts du projet restent maîtrisés tout en étant au plus proche de vos attentes.