Le secteur de la tech est particulièrement bon au jeu du jargon !
Et pourtant maîtriser les différents types de livrables est important afin de fixer des objectifs et le niveau de qualité attendu.
Alors, quel livrable demander à votre équipe selon la nature du projet ? On vous guide !
Vous êtes en cycle de « découverte »
Qu’il s’agisse d’un travail d’innovation technique, design ou marketing, ce cycle souvent préliminaire permet d’explorer des idées et concepts. Fixer des objectifs et des livrables dépendra de la nature du projet et de son stade ; idéation, cadrage, développement, …
Dans cette phase, vous pouvez être amené à produire plusieurs petits projets avec des objectifs très distincts. Vous pouvez par exemple tester un nouveau moteur de recherche, présenter des prototypes à un panel d’utilisateurs, interfacer votre projet avec une nouvelle API, …
Cette phase exploratoire peut vite déraper, il essentiel de définir des ressources, jalons et objectifs. Vous ne voudriez pas que cette sympathique idée UX végète des mois et finisse par prendre un part importante de votre budget ! Afin de maîtriser le résultat de votre projet, voici un tour d’horizon de différents livrables techniques :
Benchmark
Un benchmark est une mesure comparative qui permet d’évaluer les performances d’un système, d’une application ou d’un composant par rapport à d’autres références. Il s’agit souvent d’une série de tests standardisés visant à évaluer les capacités et les performances d’un produit ou d’une technologie.
Exemple : réaliser un benchmark sur les performances de différents SGBD.
PoC
Un PoC (Proof of Concept) est une démonstration initiale ou un prototype d’une idée ou d’un concept. Il est utilisé pour valider la faisabilité technique et la viabilité d’un projet. Un PoC permet de tester une idée de manière expérimentale avant d’investir davantage de ressources dans son développement.
Exemple : développer et tester une IA de classification automatique de documents.
MVP
MVP (Minimum Viable Product) : Un MVP est la version minimale et fonctionnelle d’un produit qui répond aux besoins de base des utilisateurs. Il est conçu pour valider les hypothèses clés du produit et obtenir des retours des utilisateurs. Un MVP peut être utilisé pour tester le marché, recueillir des commentaires et orienter le développement futur du produit.
Conseil : poussez au maximum la qualité de l’expérience utilisateur au niveau de la key feature. Un MVP réalise une chose de manière parfaite.
Version alpha
Une version alpha est une version préliminaire d’un logiciel ou d’une application. Elle est généralement utilisée pour effectuer des tests internes approfondis et identifier les bogues et les problèmes de base. Une version alpha est limitée en termes de fonctionnalités et peut ne pas être stable ou adaptée à une utilisation publique.
Version bêta
Une version bêta est une version plus avancée d’un logiciel ou d’une application qui est publiée à des utilisateurs externes pour obtenir des retours supplémentaires. Elle est généralement considérée comme étant proche de la version finale, mais peut encore comporter certains bogues ou problèmes à résoudre. Les utilisateurs bêta sont encouragés à signaler les problèmes rencontrés pour aider à améliorer le produit.
Vous entrez dans un cycle de « pérennisation »
Ici, le contexte est différent. Bien que l’innovation soit possible (et souhaitable), le cycle de pérennisation privilégie la stabilité et donc la qualité du développement. Le principale livrable attendu est une application fonctionnelle (accompagné d’une documentation précise).
Il convient dès lors de mettre en place une organisation qui facilitera le développement et la livraison d’une application stable.
Première version d’une application
La version 1, également appelée V1 ou première version, représente la première version complète et stable d’un logiciel ou d’une application. Elle est considérée comme étant prête pour une utilisation générale et peut inclure toutes les fonctionnalités de base prévues dans la vision initiale du produit.
Le développement d’une véritable v1 n’est pas une sinécure : architecture, performance, qualité, tests, … nombreux sont les postes de dépenses. Doit-on assurer une scalabilité importante ? Y-a t’il du turnover dans l’équipe ? Quel niveau de performance atteindre ? Vous devez vous poser les bonnes questions afin de produire et livrer un maximum de valeur dans le moyen et long terme avec des ressources par définition limitées.
NB : Quand il s’agit de créer une fonctionnalité à partir d’un PoC, j’aime utiliser le terme d’industrialisation. Industrialiser revient à rendre fiable, maintenable et performant un concept exploré lors d’un PoC.
Finalement
Il est important de noter que ces termes peuvent varier en fonction du contexte et de l’industrie du développement logiciel. Les définitions peuvent différer légèrement d’une organisation à l’autre, mais ces distinctions générales sont couramment utilisées pour décrire les différentes étapes du cycle de vie.
Pour un chef de projet, identifier clairement ces livrables et leur utilité permet de mieux structurer la demande du client. Vous pouvez notamment lui proposer d’éprouver la faisabilité de certaines idées avant industrialisation dans une solution pérenne.
Ces distinctions permettent aussi de fixer un certain niveau de qualité avec les équipes de développement. Il est important de former vos collaborateurs à ces concepts afin qu’ils changent facilement de posture selon le contexte du projet.