« People don't know what they want until you show it to them. » Steve Jobs
Les Proof Of Concept sont réalisés dans le but de tester une idée, en justifiant de son intérêt, de sa pertinence ou de sa faisabilité. L’objectif est souvent de convaincre des supérieurs hiérarchiques, en prouvant par des tests, l’intérêt des utilisateurs pour l’idée en question.
POURQUOI ÇA NE MARCHE PAS ?
Problème : la plupart du temps les POC, qui doivent être réalisés rapidement, sont très peu cadrés afin de vite délivrer aux équipes de développement un cahier des charges avec lequel ils pourront commencer à produire. Périmètre incomplet, trop ambitieux, mauvaise communication ou perte d’objectif, en découlent un certain nombre de frictions entre l’équipe commanditaire du POC et les équipes de développement…
1/ L’équipe technique n’a que très peu conscience de l’enjeu du POC ni de l’environnement dans lequel devra potentiellement s’intégrer. Résultat, le travail réalisé est souvent peu réutilisable, ni même parfois réplicable.
2/ Les équipes qui conçoivent le POC ont souvent des difficultés à se limiter au sujet à traiter et imaginent souvent beaucoup de fonctionnalités qui pourraient enrichir l’idée de départ. Effectivement, ce serait plus judicieux avec certaines fonctionnalités. Le problème est que le POC n’en fini jamais d’évoluer et va plutôt tendre vers un produit fini qui aura couté cher, avant même d’avoir été testé.
Résultat, les POC ont souvent du mal à se terminer, ne sont que très peu réutilisables et ne remplissent pas correctement les objectifs initiaux.
LE CADRAGE, UNE ETAPE CRUTIALE ET DETERMINANTE
Le plus important dans tout projet, c’est le cadrage. Quand on souhaite réaliser un POC, définir un périmètre restreint limite les risques, permet aux équipes de bien appréhender le travail et permet des conclusions tranchées. A l’inverse, partir sur un périmètre large risque de compliquer les processus de décision en soulevant bon nombre de questions auxquelles il faudra répondre au lieu de s’attarder à résoudre un problème en particulier.
Un fois le périmètre défini, il faut également le border en listant ce qui sera pris en compte et ce qui n’entrera pas dans le périmètre. Cette étape permet d’éviter, dès le départ, les envies d’alimenter en idées le sujet à traiter.
Lors de cette phase de cadrage, on veillera à impliquer l’ensemble des parties prenantes afin d’aligner tout le monde sur les objectifs du projet. Plus les équipes techniques seront tôt dans le projet, meilleur sera le cadrage et plus fluide sera la phase de développement. C’est un savoir-faire que nous mettons en œuvre chez Keley Consulting pour réaliser les POC de nos clients.
2 MONTH FOR A POC : METHODOLOGIE KELEY EN 2 GRANDES ETAPES
1 / Une phase de cadrage intensif :
- Un scope clair qui s’appuie un nombre prédéfini d’écrans, une fonctionnalité complexe (l’objet du POC), et quelques fonctionnalités simples.
- Des étapes projet qui permettent un cadrage fonctionnel autour d’ateliers de conception
- La présence d’un Lead développeur qui garantira la faisabilité du projet
2/ Une phase de développement par nos équipes techniques
- Sur la base des éléments de concept validés en ateliers
- Avec un plan de test bien défini en amont.
En travaillant conjointement avec nos clients sur une phase intensive de définition des objectifs et de conception, nos équipes techniques ont alors tout en main pour réaliser rapidement le produit attendu : un produit prêt à être testé auprès de vrais utilisateurs, conforme aux attentes marketing et métier. Un produit livré en moins de 2 mois et qui couvrira l’ensemble des besoins, tant fonctionnels que stratégiques.
