Former une idée pour un nouveau logiciel est énergisant. Le remue-méninges des possibilités et la visualisation du potentiel inspirent les membres de l’équipe à créer quelque chose de nouveau qui résout un problème. L’idéation est passionnante, mais si vous ne mettez pas votre idée à l’épreuve, vous risquez de ne pas obtenir le produit que vous attendez. L’idée est-elle pratique ? Est-elle réalisable ? Les utilisateurs voudront-ils réellement l’utiliser ? Quelles ressources seront nécessaires pour le construire ? Ces questions et d’autres peuvent toutes trouver une réponse avec une preuve de concept.
Qu’est-ce qu’une preuve de concept ?
La preuve de concept (poc) consiste à créer des preuves et de la documentation sur la faisabilité d’une idée. Elle décrit comment le produit ou le service idéalisé deviendrait commercialisable, comment il fonctionnerait, s’il est nécessaire et qui est la population cible. Bien qu’une preuve de concept ait plusieurs applications dans différents domaines (allant du marketing à la médecine), lorsqu’il s’agit de développement logiciel, elle s’applique à un processus spécifique. Pour les idées spécifiques aux logiciels, une PoC est un acte qui consiste à déterminer si le logiciel peut être construit dans le monde réel, quelles technologies doivent être utilisées dans le développement et si le logiciel est susceptible d’être adopté par les utilisateurs prévus.
Comment rédiger une preuve de concept ?
Il n’existe pas de méthode tranchée pour rédiger une preuve de concept. Les règles ne sont pas strictes comme elles le sont pour d’autres documents écrits, tels que les documents de recherche, qui doivent tous suivre le même schéma d’intro, de méthodes et de conclusion. Au lieu de cela, il est important de s’assurer que des sujets clés spécifiques sont couverts, quelle que soit la manière dont ils le sont. Une preuve de concept est un document vivant qui peut être mis à jour au fur et à mesure que vous avez de nouvelles pensées et que vous obtenez de nouveaux commentaires des personnes qui le lisent. Pour le développement d’idées logicielles, une PoC doit aborder les points suivants :
Prouver le besoin
Il n’est logique de consacrer du temps et de l’argent à la construction d’un produit que si des personnes en ont besoin. Ces personnes sont peut-être les employés de l’entreprise, qui ont besoin d’améliorer leur productivité. Peut-être s’agit-il d’un nouveau marché que l’entreprise ne dessert pas actuellement, mais qu’elle pourrait facilement atteindre. Qui qu’ils soient, vous devez savoir que votre logiciel répondra à leurs besoins. Avant de commencer à construire le logiciel, vous devrez être parfaitement clair sur les points de douleur que votre public cible rencontre. Vous ne voulez pas deviner quels sont ces problèmes ou supposer que vous le savez sans parler réellement à un échantillon représentatif des personnes du groupe. Vous n’avez pas besoin de parler à des centaines de personnes à ce stade, juste assez pour que vous commenciez à entendre les mêmes préoccupations répétées. Lorsque vous interrogez les utilisateurs et les parties prenantes potentiels, assurez-vous de poser des questions sur les implications de chaque point de douleur. Vous voudrez connaître à la fois l’impact commercial et l’impact personnel de chacun d’entre eux afin de créer une liste de priorités. Vous finirez par voir apparaître des modèles et des fils conducteurs. Vous serez peut-être surpris de ce que vous n’entendez pas dans ces entretiens. À la fin de cette étape, vous aurez une liste de besoins et d’objectifs spécifiques que le logiciel devrait résoudre.
Faire correspondre les points de douleur aux solutions et obtenir des commentaires
Cette étape consiste à faire un brainstorming sur les façons de résoudre chacun des points de douleur que vous avez identifiés à la première étape. Il y aura probablement plusieurs façons de résoudre chaque problème. Après votre brainstorming, vous évaluerez chaque solution possible pour déterminer comment elle se positionne par rapport au coût, à la concurrence, au calendrier, aux défis technologiques, etc. Une fois ce processus terminé, vous devriez avoir une idée plus claire des solutions à inclure dans le produit final.
Une fois que vous avez cette liste de solutions, retournez voir les utilisateurs et les parties prenantes que vous avez initialement interrogés et découvrez leurs réactions et leurs réponses aux solutions recommandées. Décrivez comment vous envisagez le fonctionnement du produit et demandez-leur leur avis. Ces commentaires vous fourniront des informations précieuses pour aller de l’avant.
Que se passe-t-il après la validation du concept ?
Prototype de votre solution et test
Votre prochaine étape consiste à créer un prototype qui enveloppe vos solutions dans un produit rudimentaire que vous pouvez utiliser pour tester avec les personnes que vous avez interrogées précédemment. Ce prototype doit avoir le jeu de fonctionnalités et l’interface utilisateur/utilisateur attendus. Une fois le prototype construit, testez-le avec vos personnes interrogées pour obtenir des commentaires supplémentaires. Enregistrez leur utilisation du produit pour suivre le degré d’intuitivité de l’interface et découvrez si vous avez négligé une fonctionnalité importante.
Créer un produit minimum viable
Un MVP est différent d’un prototype dans la mesure où il s’agit d’une solution entièrement fonctionnelle que vous pouvez mettre au monde pour l’utiliser. Alors qu’il ne comprendra que les fonctionnalités les plus importantes et essentielles pour résoudre les principaux points de douleur que vous avez identifiés, il doit fonctionner du côté de l’utilisateur, tout comme le produit final. Le MVP vous donne la possibilité de tester le produit au-delà de votre petit groupe de personnes interrogées, à un groupe plus large et plus représentatif de votre marché ou de votre public. Il offre la possibilité d’obtenir davantage de commentaires qui vous indiqueront si le produit, dans son itération actuelle, trouve un écho auprès des utilisateurs et des parties prenantes.
Concevoir une feuille de route
À partir de toutes les informations que vous avez recueillies dans chacune des étapes précédentes, créez une feuille de route qui décrit ce que vous avez appris et décrit un processus recommandé étape par étape pour la construction du produit. Considérez cette feuille de route comme un ensemble de plans pour la construction d’un bâtiment. Avec cette feuille de route comme guide, tout le monde sera maintenu sur la même page tout au long du développement du produit et aura une image claire de l’objectif final.
