02 855 233 42 contact@oniti.fr

Comment ne pas rédiger un cahier des charges fonctionnel pour le développement de votre logiciel métier

David, le fondateur d’Oniti, et Julien, développeur senior à l’agence, vous expliquent les limites des cahiers des charges fonctionnels et la méthode maison d’Oniti.
Accueil » Actualités » Comment ne pas rédiger un cahier des charges fonctionnel pour le développement de votre logiciel métier

Logiciel = cahier des charges fonctionnel

Traditionnellement, les entreprises qui souhaitent se doter d’un logiciel métier pour accompagner l’activité de leur entreprise, écrivent, ce qu’il est convenu d’appeler, un cahier des charges fonctionnel. Cet exercice, souvent fastidieux et chronophage, vise à écrire, sur plusieurs pages, les fonctionnalités attendues, le plus précisément possible. Ce document devient ainsi le cadre de la relation entre l’entreprise et l’agence de développement. Il est souvent contractuel et détermine le budget au forfait du projet. Plusieurs semaines après, le client est livré de son outil métier, répondant au cahier des charges, mais ne répondant pas toujours à ses attentes….

Les journées de cadrage, la méthode maison d’Oniti qui a fait ses preuves

« Partager les enjeux de nos clients est essentiel pour bien les accompagner »

Chez Oniti, on privilégie une approche que certains qualifierait « d’agile » dont la recette est simple : une journée + une équipe client + un duo de développeurs = un cadrage fonctionnel partagé.

En une journée, les fonctionnalités principales de votre logiciel métier sont listées, priorisées, comprises. Tout est passé au crible : le métier, le modèle économique, l’organisation. On veut tout savoir.

David BOUCHÉ Dirigeant Oniti

« Partager les enjeux de nos clients est essentiel pour bien les accompagner »

Julien LOLLIVIER, Concepteur-Développeur Oniti

Phase 1. Comprendre les enjeux métier

 « Comment développer un outil essentiel au modèle économique de l’entreprise, si on en n’a pas les clés de compréhension ? »

 La matinée est consacrée au métier. C’est l’entreprise qui parle. Challengés par le duo de développeurs, le dirigeant souvent accompagné de son équipe métier, expliquent, détaillent, répondent à nos questions. Il s’agit d’un véritable moment d’échange. Cela se fait sur le principe de questions/réponses jusqu’à ce que tous les enjeux de la future application nous soient totalement familiers.

Phase 2. Comprendre les enjeux de développement

Au début de l’après-midi, nous prenons la main. Ce sont les développeurs qui parlent. On restitue la demande, on la traduit en termes d’enjeux techniques, on reformule les fonctionnalités, on identifie les points de blocage, on décortique le besoin et on partage les enjeux techniques.

Phase 3, dite « phase post it ! ». Prioriser les fonctionnalités.

A l’issue de ses deux phases, on a les mêmes cartes en main avec l’entreprise, pour discuter des fonctionnalités attendues pour leur logiciel. La méthode ? Les participants écrivent sur des post it, les fonctionnalités souhaitées pour le logiciel selon le principe : « une fonctionnalité = un post it ! » Un grand tableau vient accueillir cette collection.

Ensuite, on range : les prioritaires en haut : celles qui sont indispensables au fonctionnement, celles qui sont essentielles au métier. Plus on descend au bas du tableau, moins les fonctionnalités sont prioritaires. Tout en bas, la liste au Père Noël ! 🎅 Vous savez ces fonctionnalités que vous aimeriez vraiment avoir, mais… plus tard.

Phase 4. Tracer le minimum viable du logiciel

La journée de cadrage s’achève par un trait horizontal, celui qui sépare l’essentiel de l’accessoire pour la première version. Sur le tableau ordonné des fonctionnalités, un trait est dessiné entre les post it des fonctionnalités souhaitées pour le logiciel métier et ceux qui pourront faire l’objet d’un arbitrage budgétaire. On se quitte alors fatigués mais contents.

Phase 5, phase en « chambre ». Evaluer

La journée de cadrage finie, le travail se poursuit à l’agence. Dans les trois jours qui suivent la journée, c’est toute l’équipe de développeurs d’Oniti qui se réunit face au tableau de post it et on compte les jours : 0,5 jour ici, 10 jours là. Chaque fonctionnalité fait l’objet d’une première évaluation en temps passé de développement.

Et une première estimation en ressort qui permet alors de visualiser l’enveloppe budgétaire et la feuille de route de l’application au plus proche du métier.

Un cadrage au plus près des besoins métier de l’entreprise

Partagée avec le client, celui-ci ajuste ses priorités en vue des temps à prévoir. Il déplace quelques post-its : telle fonctionnalité complexe ne sera pas développée, telle autre sera ajoutée au haut du tableau, pour finalement obtenir un cadrage au plus près des besoins métier de l’entreprise.
Le développement pourra ensuite être enclenché si le client souhaite poursuivre la collaboration avec nous. En effet, cette prestation d’Oniti n’engage à rien. Même si 90% des journées de cadrage se concrétisent et si 90% des clients d’Oniti ont démarré leur collaboration avec l’agence par cette prestation.

Au final, cette méthode permet d’initier une démarche itérative et souple de travail avec l’entreprise. C’est plutôt rassurant comme point de départ pour tout le monde !

David BOUCHÉ Dirigeant Oniti

« Le logiciel que vous obtiendrez c’est ce qu’il y a dans la tête du développeur » alors parlons-en !

David BOUCHE, fondateur et dirigeant de l’agence Oniti