Erreurs courantes dans le développement de MVP

MVP (minimum viable product) est un produit qui est développé avec un maximum d’économies d’argent et de ressources, généralement dans le seul but de tester une hypothèse. L’hypothèse, en règle générale, est le besoin et/ou l’utilité de ce produit.

MVP ne signifie en aucun cas « projet », fait à la hâte, qui une fois terminé sera jeté et sera écrit de toutes pièces.

Si vous êtes convaincu du contraire, alors vous devriez définitivement arrêter, revoir les priorités de développement et lire cet article. Cela vaut la peine de réduire les fonctionnalités du produit, mais en aucun cas d’essayer de tout faire en même temps, dans une course folle, en omettant des parties importantes des fonctionnalités et en laissant derrière soi une série de bogues. Il est nécessaire de déterminer avec précision quelle fonctionnalité est de base et laquelle n’est pas utilisée dans la plupart des cas.

Dans cet article, je parlerai de notre expérience personnelle dans la création de MVP et, à la fin, je donnerai une liste de conseils utiles que vous pourrez utiliser dans votre développement.

Expérience personnelle de création de MVP

En règle générale, si vous créez MVP, vous êtes limité en temps et en ressources humaines. Par conséquent, la première et principale étape consiste à déterminer la fonctionnalité de base, sans laquelle cette application n’a pas de sens, c’est-à-dire l’action clé qui doit être réalisée.

Selon les statistiques, sur l’ensemble des fonctionnalités existantes des applications, seules 12 % sont utilisées en permanence. Vous devez classer par ordre de priorité les parties de la « liste de souhaits » en vous posant la question habituelle « quelle est la quantité de fonctionnalités nécessaires » et ne sélectionner que les plus attendues dans la liste des MVP.

Quant à l’aspect technique du développement, vous devez immédiatement comprendre quels éléments doivent être écartés. L’erreur la plus importante et la plus courante des développeurs est que le MPV est une « ébauche ». Ce n’est pas vrai ! À l’avenir, si l’hypothèse était testée avec succès, il serait bon de continuer à développer le produit actuel, plutôt que de jeter tout l’argent dépensé pour développer la version actuelle du produit. Par conséquent, vous ne devez pas être sceptique, par exemple, quant à la possibilité de couvrir avec des tests MVP.

Ce que vous n’avez pas à refuser :

• Test de couverture de la partie arrière ;
• Utiliser des tests unitaires ;
• Documentation ;
• Révision du code ;
• Rétro et remaniement techniques ;
• Le design.

Refactoring

Une chose à laquelle vous ne devez absolument pas renoncer. Lors de la création d’un produit minimal, il est très important qu’il soit flexible, évolutif et prêt à se développer dans n’importe quelle direction. Par conséquent, s’il devient évident qu’une partie de l’application n’est pas flexible ou potentiellement incapable d’évoluer, il vaut la peine de s’arrêter et de corriger la situation car, à l’avenir, cela peut s’avérer déplorable.

Style de code

Il semblerait que l’on puisse manquer cela, mais non. L’accent mis sur le style de code est plus pertinent que jamais là où la vitesse est importante. Car à n’importe quel stade de développement, il peut être possible de connecter des ressources supplémentaires sous forme de personnes. La vitesse d’entrée maximale d’un nouveau développeur dans le contexte est notre objectif principal. Cela inclut également la disponibilité de la documentation. L’émergence d’une nouvelle personne dans l’équipe devrait accélérer le développement, et non le ralentir. Il peut ralentir en raison d’un grand nombre de questions qu’il pose concernant le code et l’application dans son ensemble. Par conséquent, les aspects techniques et architecturaux doivent être immédiatement inclus dans la documentation.

Conception

Le point extrêmement controversé de l’élaboration était la nécessité de la conception. En fait, il serait extrêmement stupide d’attendre le développement du design avant de commencer le développement du produit – parfois, il faut plus de temps pour développer un design que ce qui est alloué à l’ensemble du développement. Mais en même temps, il est bon de se rappeler qu’il est très important de fabriquer un produit qu’on veut utiliser. Il est heureux que les développeurs aient une capacité extrêmement rare à faire « beau », mais en réalité, ce n’est pas toujours le cas et vous devrez peut-être engager un graphiste qui a au moins des compétences de base, mais de bonnes compétences en matière de conception graphique .

L’un des arguments importants, après lequel vous arrivez encore à la conclusion que la conception est nécessaire, est l’accélération du développement. Une conception qui semble, peut-être, hors du temps, accélère tout de même considérablement le développement et enlève une partie de la charge des développeurs. Ces derniers peuvent alors consacrer plus de temps directement au développement et à l’architecture de l’application. C’est formidable si les ressources allouées à MVP vous permettent d’ajouter un concepteur à l’équipe.

Ce que vous pouvez encore refuser

Les processus

Les processus sont ce que vous pouvez vraiment sacrifier. La construction de processus est toujours une activité coûteuse. Bien sûr, vous devez disposer des processus de base : fixation d’objectifs, sprints, orientés vers la mise en œuvre d’une partie intégrante du fonctionnel, tentatives d’évaluation des tâches. Mais en réalité, tout peut déraper, car il a toujours fallu être aussi flexible que possible : quelque part, la tâche peut être simplifiée, et quelque part, il faut soudain affiner la fonctionnalité qui a été manquée ou mal interprétée. Néanmoins, vous devriez toujours vous fixer de petites lignes directrices sous la forme de dates limites les plus proches avec une compréhension de ce qui devrait être prêt pour ce moment.

En utilisant un outil de suivi du temps en même temps que votre application de gestion de projet, vous pouvez avoir une idée claire de la répartition du temps de votre équipe.
Cela vous aidera à calculer le coût et à améliorer la productivité de l’équipe.

Quoi d’autre peut accélérer le développement de MVP ? Les développements prêts à l’emploi. Au stade de la création de MVP, vous ne devez absolument pas vous engager dans le développement de vos bibliothèques et plugins. La plus grande partie de ceux-ci doit être prise de l’extérieur et se tourner vers l’Open Source. Peut-être que certaines parties des fonctionnalités ont déjà été développées dans d’autres produits de votre entreprise ou par vous plus tôt pour votre plaisir. Cela vaut également pour les composants. C’est très bien si votre entreprise dispose déjà d’un seul kit d’interface utilisateur que vous pouvez utiliser. Résultat : un développement accéléré et un style uniforme des produits de l’entreprise dès leur sortie de la boîte.

Communication directe entre les développeurs et les clients

De nombreux développeurs n’aiment pas communiquer et communiquer dans la vie, ne pas communiquer avec les clients. Mais la communication a vraiment un grand potentiel pour accélérer le développement. Après avoir déterminé le véritable objectif, en connaissant les buts du produit, les capacités de l’application actuelle et les fonctionnalités déjà mises en œuvre, le développeur peut proposer une solution qui, dans le même temps, aidera à résoudre le problème du client et lui fera gagner la plus grande partie du temps.

Soyez une équipe, pas un recrutement

Le niveau de communication accru au sein de l’équipe vous aidera à trouver rapidement la solution optimale. Par exemple, le Frontend et le Backend communiquent constamment et directement avec nous, s’asseyant à la table des négociations et décidant de quel côté telle ou telle logique sera mise en œuvre, qui déterminera le format des contrats et quelles données seront réellement nécessaires dans l’API. Il est très important que chaque partie du développement puisse répondre rapidement aux demandes de l’autre partie, afin de ne pas bloquer le développement dans son ensemble.

La motivation personnelle de l’équipe et des développeurs

La création d’un MVP peut parfois être stressante et provoquer de nombreux points controversés qui peuvent donner lieu à des débats passionnés et parfois difficiles. Il est très important que dans de telles situations, quelqu’un agisse comme catalyseur et ne permette pas à l’équipe de perdre sa motivation et son esprit d’équipe. En règle générale, c’est la responsabilité du responsable du développement en cours, mais il arrive souvent qu’il n’ait tout simplement pas le temps ou, pire encore, qu’il ne s’en soucie pas. Ne sous-estimez pas à quel point cela affecte la vitesse du développement. Une équipe unie et motivée communique mieux et s’attarde volontiers le soir avant l’échéance de sa propre volonté et de son propre désir.

Répartition claire des responsabilités : à la fois rôles et développement

Lorsque la communication se fait directement entre le développement et les clients, il est utile de déterminer dès le début qui dirige la réunion et quel plan tout le monde suit, qui assume exactement le rôle de l’analyste (s’il n’y en a pas) et qui propose la solution finale. La répartition des responsabilités au sein de l’équipe devrait à nouveau être assurée par le responsable du développement en cours.

Comprendre les produits Synchronisation

Au début du développement du produit, il est très important d’établir un plan pour construire l’architecture de l’application et d’en discuter collectivement avec l’équipe – c’est ce que nous avons fait avant chaque partie complexe de l’application. Description de l’architecture de développement, une série de discussions. L’avant et l’arrière, la conception, et même l’analyste sont guidés en même temps dans cette documentation. Ainsi, vous aurez toujours une compréhension commune de l’application, et vous ne perdrez pas de temps à essayer de vous adapter les uns aux autres. Avant de faire la conception, ou la partie frontale, ou la logique à l’arrière, ou d’organiser les données dans la base de données, il était très important de synchroniser la compréhension de toutes ces parties en une seule image et de se mettre d’accord sur les noms et les termes. Le glossaire général vous aidera également dans cette tâche. Cela peut sembler une bagatelle, mais cela simplifie vraiment la communication. Résultat : un développement accéléré. C’est formidable lorsque l’analyste et le concepteur comprennent ce qu’est un composant ; le recto et le verso portent le même nom ; les clients et le développement appellent la même partie de la fonction par le même nom.

Nous résumons :

• Vous ne devez pas renoncer au contrôle du style de code, de la couverture des tests, de la conception et du remaniement.
• Concevez votre produit de manière à ce qu’il grandisse et se développe. Gardez toujours cela à l’esprit.
• Il est possible et nécessaire d’utiliser des développements prêts à l’emploi, s’il y en a.
• La communication directe entre le développement et le client peut accélérer considérablement le développement.
• Ne sous-estimez pas l’importance de l’esprit d’équipe et de la motivation de l’équipe.
• Attribuer clairement les responsabilités dans les rôles et dans le développement dès le début.
• La même compréhension du produit et la synchronisation de la compréhension sont très importantes pour un développement « rapide ».

MVP n’est pas égal à « draft » !

MVP, c’est quand à chaque étape nous avons un produit exploitable et utile. En outre, il n’est amélioré et complété que par de nouvelles fonctionnalités, et non par des fonctionnalités développées, ce qui en soi n’a aucun sens et n’est pas holistique.