Preuves de Concept déléguées
Vous avez envie de lancer un nouveau service, un nouveau produit, une nouvelle fonctionnalité… mais vous n’êtes pas sûr·e de la faisabilité technique, ou de la stack à choisir.
Dans ces cas-là, traditionnellement, on lance une preuve de concept (POC) en interne. On y affecte quelques devs, qui vont devoir aller explorer l’espace fonctionnel et technologique en question, expérimenter, voir si on peut y arriver.
Les dangers de l’inconnu
C’est une approche naturelle, mais elle comporte pas mal de risques, voire d’inconvénients :
- Vos devs ne connaissent pas l’espace des possibles. Technos, approches, aspects de langage : difficile de savoir jusqu’où on peut aller, quoi chercher, comment architecturer quand on avance dans le noir.
- Le code produit est nécessairement jetable. Il est exploratoire, réalisé sans avoir pour le moment le bénéfice de l’expérience et des bonnes pratiques associées. Il n’y aura d’ailleurs ni tests ni docs. Ce serait OK s’il allait effectivement être jeté, mais trop souvent, il est finalement utilisé comme tremplin pour la production, ce qui constitue en soi un handicap.
- Vos devs vont y passer beaucoup de temps. C’est normal, ils·elles tatonnent énormément, se prennent pas mal de murs, etc. Ce temps a un coût direct (rémunérations) et indirect (allongement du time to market pour l’idée que vous cherchez à concrétiser, dans un contexte peut-être très concurrentiel).
- Vous risquez un faux-négatif. Faute d’expertise existante, votre équipe peut conclure à un échec (« pas faisable ») alors qu’en fait, une solution viable existe. Vos concurrents auront peut-être vu le chemin, eux.
- Vous risquez un faux-positif. À l’inverse, l’équipe peut conclure que c’est faisable, mais avoir loupé un point bloquant, resté dans son angle mort. Vous allez alors consacrer beaucoup de temps et d’argent à la poursuite d’une chimère.
Déléguer le POC, une innovation séduisante !
En 2015, Delicious Insights innovait donc en proposant pour la première fois un service de délégation de POC. Puisque sur certains sujets, nous avons une profondeur et une largeur d’expertise, de veille et de retour d’expérience que vous n’avez pas, et que vous pouvez déjà y recourir pour du cadrage technique et de l’audit de code, pourquoi ne pas en profiter aussi pour réaliser plus efficacement vos POC ?
- On saura vite quelles technos et approches sont pertinentes.
- On produira un livrable qualitatif. Du code propre, bien architecturé, conforme aux meilleures pratiques, annoté, testé, documenté, maintenable. De la vraie craftsmanship.
- Si vous nous donnez assez de billes sur votre objectif / contexte projet, nous aurons même à cœur de produire un POC si proche de l’utilisation visée que vous pourrez l’utiliser efficacement comme tremplin pour la prod !
- On aboutira beaucoup plus vite. Certes, on est plus chers à l’heure que vos devs, mais on est moins nombreux et sans doute plus rapides ! Ça vous coûtera sans doute moins cher au final, et surtout vous pourrez sortir ça avant la concurrence !
- Ni faux-positifs, ni faux-négatifs. Vous avez l’assurance que si on conclue par un « oui », vous pouvez y aller en confiance. Et si on conclue par un « non », c’est que c’est mort pour tout le monde, y compris vos concurrents.
En somme, vous dépenserez moins, aurez une réponse plus vite, et si elle est positive, vous pourrez démarrer plus vite et avec moins de dette technique pour la suite ! Que demander de plus ?!