Notre offre "PoC / PoV"

Créer rapidement du code pertinent afin de lever des incertitudes techniques sur un projet plus ambitieux.

Marc Hugon

Directeur technique projets

Vous avez une opportunité business mais vous ne savez pas comment l’adresser techniquement ? Vous avez un projet et vous avez des doutes sur sa faisabilité, voire l’investissement nécessaire pour le mener à bien ? Vous êtes face à une estimation budgétaire qui n’est pas en ligne avec l’investissement qui vous semble le plus cohérent ? Vous avez identifié une opportunité business que vous voulez tester pour valider son intérêt économique ?

Notre proposition d’accompagnement est personnalisée, et peut comporter tout ou partie des éléments suivants :

Identification de la cause précise de l’indécision à laquelle vous êtes confronté
Définition d’un projet minimaliste afin d’assurer une réponse sans ambiguïté sur la façon de réaliser le projet
Développement de ce projet avec du code réutilisable dans votre produit final
Test du code, potentiellement en production, s’il s’avère que c’est l’environnement qui permet de lever le maximum de doutes
Compte rendu de ce qui aura été constaté et de la documentation permettant d’expliquer les méthodes et les moyens mis en oeuvre.

1 – Comprendre votre projet et vos doutes

Il est tout d’abord nécessaire de comprendre vos objectifs métiers. C’est le fil conducteur de tout le travail qui sera réalisé par la suite. L’objectif de ce PoC (Proof of Concept) est de vous aider à atteindre vos objectifs business et/ou organisationnels.

Ensuite, nous faisons un focus sur la problématique pour laquelle vous souhaitez une aide extérieure.

Nous interagissons avec vos interlocuteurs techniques et métiers afin d’avoir une vision précise sur le maximum de paramètres à prendre en compte. L’objectif est d’identifier toutes les contraintes qui peuvent être autant techniques qu’organisationnelles.

Le tout permet de rédiger un document de référence pour les étapes suivantes.

Ce travail est réalisé avec l’expert technique qui développe le PoC, accompagné d’un directeur technique et épaulé par le reste des équipes Kaliop.

2 – Définir le POC / POV

Un PoC (Proof Of Concept) permet d’adresser un sujet technique, quand le PoV (Proof Of Value) est fonctionnel. Le PoV se différencie du MVP (Minimum Viable Product) car l’aspect viabilité est justement une question qui se pose. Dans tous les cas, on va reproduire la même démarche projet. Les interlocuteurs seront généralement les mêmes, c’est le degré d’implication qui va varier. On fera assez logiquement plus appel aux compétences techniques qu’aux fonctionnelles dans le cadre d’un PoC, et vice versa.

Avant de se lancer dans la réalisation, il faut définir :

Le besoin fonctionnel auquel on doit répondre, avec les interactions techniques qui doivent être mises en œuvre pour y parvenir. Des phases UX sont envisageables dès cette étape.
La façon dont le développement doit être fait et déployé.
Les moyens qui permettront de vérifier le résultat constaté.
L’estimation en temps qui va être investie pour ce développement.

Ainsi, on s’assure :

Que le cadre correspond bien aux attentes que vous avez formulées.
Que le code qui va être créé est réalisé conformément à vos attentes, qui peuvent aller jusqu’à vouloir intégrer ce code dans vos propres applications.
Qu’on saura vérifier précisément ce que ce test arrivera ou n’arrivera pas à effectuer.
Et enfin, que le temps passé sur ce développement reste limité, conformément à ce qui a été défini comme un investissement raisonnable et suffisant pour atteindre cet objectif.

3 – Développer et tester

Kaliop recommande l’usage de l’agilité de façon générale, mais encore plus dans le cadre de ce type de projet.

Plus précisément, c’est la capacité à pouvoir tester des itérations le plus rapidement possible qui est primordial pour ne pas perdre du temps sur des hypothèses qui se révèlent fausses.

Nous aurons donc pour principal objectif pendant cette phase de faciliter les tests réguliers au fur et à mesure de l’avancement.

Le temps étant contraint, il est souvent important de mettre à disposition des personnes qui ont des connaissances qui peuvent permettre d’aider l’équipe Kaliop dans sa découverte de vos systèmes. C’est un élément clé pour éviter de trop investir de temps dans le développement de la solution.

4 – Tirer parti des acquis

Tous les tests réalisés pendant la phase de développement et pendant la phase de recette sont pris en compte dans la restitution finale.

Ils permettent de présenter de façon objective les résultats observés, qu’ils répondent ou non à ce qui était attendu. Dans tous les cas, nous capitalisons sur une amélioration de la connaissance, que ce soit pour résoudre le problème initial ou pour identifier des moyens pour arriver à l’objectif métier initial.

Cette restitution contient :

Le code réalisé
La documentation permettant de prendre en main ce code
Ce qui a été constaté avec les tests
Selon les résultats et les attentes, une proposition de suite de projet avec une estimation de l’effort nécessaire