Le temps passe vite, n'est-ce pas ?
Une année, vous avez une idée d'entreprise, la suivante vous vendez votre produit à Amazon ou Apple pour beaucoup d'argent, je veux dire, beaucoup d'argent. C'est pourquoi la vitesse est si important; vous devez agir rapidement, expédier rapidement, et validez rapidement.
Dans cet esprit, parlons des produits minimum viables ou plus précisément, en construire un réussi en 5 semaines.
Je sais ce que vous allez dire :
"5 semaines, c'est assez long pour créer un MVP. Vous devriez l'avoir fait d'ici 1 semaine."
Bien sûr, mais parfois vous souhaitez créer plus qu'un simple formulaire de contact et une enquête sur l'intérêt du produit. Vous pouvez montrer votre idée aux investisseurs, présenter l'idée à un fonds de capital-risque ou cristalliser votre vision sur la base d'une preuve de concept fonctionnelle.
Une combinaison des trois est exactement ce à quoi nous avons dû faire face chez STX Next.
Un de nos clients souhaitait concrétiser son idée de plateforme fintech. Le concept derrière le produit était simple, mais puissant :
- permettre aux utilisateurs d'échanger de l'argent entre différents membres de la communauté sans avoir à payer de frais bancaires ni à répartir les coûts
- échanger à la fois de la monnaie fiduciaire et des crypto-monnaies via un mécanisme d'échange social, en utilisant des taux de change moyens en temps réel
- fonctionner comme une simple page Web avec des plans d'expansion sur d'autres plates-formes à l'avenir
Nous avons tous convenu de commencer par quelque chose de simple et d'apprendre par la pratique au fur et à mesure. Le défi était réel, puisque toute notre équipe n'était dans l'entreprise que depuis un moment. La première fois que j'ai vu les autres gars, c'était 2 jours avant le lancement du projet. Vraiment !
Alors nous étions là, une équipe de 3 :
- moi-même, le propriétaire du produit
- Adam Sajko, l'artisan du frontend
- Damian Brzoskowski, le mécanicien backend
L'objectif était fixé, tout comme la date limite, et je me sentais comme l'homme écureuil, ayant fait le saut et espérant toucher la cible. Dorian Kominek de l'assurance qualité nous a soutenus dans le troisième sprint, mais au départ, nous étions seuls.
Garçon, le temps s'est envolé... mais nous l'avons fait ! Terminé dans les délais et dans le cadre prévu. Le MVP est en production, il fonctionne et nous validons la solution avec les premiers utilisateurs alpha.
"Mais comment ?" vous demandez peut-être. « Comment avez-vous fait ? »
Eh bien, laissez-moi vous dire. Voici mes 5 simples—oserais-je dire, agile — des conseils pour créer un MVP réussi en 5 semaines.
Gérez les attentes, pas les résultats
Grâce au soutien que nous avons reçu d'un autre propriétaire de produit expérimenté, Gosia Maksimczyk,la portée initiale du MVP était bien organisée. Le client savait exactement ce que nous pouvions livrer en 4 semaines environ et a accepté le risque. Ils savaient que nous n'allions pas construire de fusée spatiale à cette époque et que nous devions prendre des raccourcis dans de nombreux domaines.
Plus important encore, cependant, ils avaient la confiance et la confiance nous ferions le meilleur MVP possible sous les contraintes de temps et de portée. Alors qu'il fallait que notre client nous accorde le bénéfice du doute, nous avons fait tous les efforts possibles pour nous assurer que sa confiance en nous était bien placée :
- Nous avons priorisé les fonctionnalités impitoyablement depuis le début. Le but était qu'une fois le temps écoulé, nous aurions au moins fourni les fonctions clés.
- Nous avons mis un point d'honneur à ajuster notre petite feuille de route après chaque sprint. À son tour, la carte nous a montré les prochaines étapes réalisables.
- Nous avons suivi les principes de planification itérative étroitement. Grâce à cela, notre client a été tenu au courant à chaque étape du processus, ses attentes étant ajustées d'un sprint à l'autre.
Nos efforts n'ont pas été vains et le client a été extrêmement satisfait de notre travail. Cependant, cela n'aurait pas été possible s'il ne nous avait pas fait confiance en premier lieu. Certains clients sont particulièrement ouverts d'esprit, et travailler avec eux est toujours une bénédiction.
Connaissez vos affaires
Des entreprises comme celle-ci ne fonctionnent que si l'équipe de professionnels qui y travaille est synchronisée. Même si chaque individu est un spécialiste à part entière, il est bon d'avoir la possibilité de se rabattre sur les autres et de compter sur eux pour vous aider dans le besoin.
Nous avions tous ce qu'il fallait pour répondre aux attentes de notre client, mais le processus a toujours été un travail d'équipe. C'est ce que signifie vraiment connaître vos affaires :être préparé vous-même, tout en laissant les autres vous préparer chaque fois que nécessaire.
Voici ce que nous avons fait conformément à cette philosophie :
- Ateliers de découverte de produits
Lorsque nous sommes entrés dans les premières étapes du projet, la seule chose que nous savions avec certitude était que nous devions créer un MVP en 4 semaines de développement. Ce dont nous avions une idée beaucoup plus floue, c'était la nature exacte du projet.
Dans cette optique, toute notre équipe a participé à des ateliers intensifs de découverte de produits avant d'entrer dans la phase de développement. Les ateliers ont duré 2 jours.
- Conception du produit
La phase de conception du produit, qui a duré environ une semaine, a été la prochaine étape cruciale. Grâce à Adam Srebniak, un spécialiste UX dévoué et cher collègue à nous, nous avons pu mieux comprendre ce que nous construisions.
À notre avantage, nous avons eu la chance d'engager presque toute l'équipe avant d'écrire le code. Cela nous a beaucoup aidés, car nous nous sommes familiarisés non seulement avec l'idée de sortie, mais aussi avec le raisonnement qui la sous-tend.
En cas de doute, nous pouvons toujours revenir aux maquettes ou au slogan du produit afin de se remettre sur la bonne voie et de retrouver notre concentration.
- Expérience
BIC, SWIFT, IBAN, BTC, FX—tous ces acronymes fintech et les idées qui les sous-tendent peuvent vous faire tourner la tête. Ils peuvent également constituer un énorme obstacle sur votre chemin pour respecter le délai.
Heureusement, nous avions eu une expérience préalable avec finance et crypto-monnaies avant de travailler sur ce MVP. Avec notre degré de préparation, ce n'était qu'une question de plusieurs raffinements de sprint - fonctionnant comme des sessions de partage des connaissances - pour mettre tout le monde sur la même longueur d'onde.
- Exécution
Vous connaissez la citation "Une idée n'est rien sans exécution" ? C'est extrêmement pertinent lorsqu'il s'agit de créer un MVP.
La planification est une chose, mais la mise en œuvre en est une autre. Notre équipe a réussi à surmonter les nombreux défis d'exécution grâce à notre expertise à la fois frontend et backend, ainsi qu'un soutien solide de notre équipe d'assurance qualité experte en technologie.
Tout le monde savait comment tirer le meilleur parti de la technologie que nous utilisions, comment construire des choses rapidement, et surtout, comment reconnaître quand quelque chose a été juste assez bien.
Préparez le terrain à l'avance
Lorsque vous n'avez que 4 semaines pour créer un MVP et une toute nouvelle équipe pour le faire, préparer le terrain à l'avance pour minimiser les risques est indispensable.
Vous ne pouvez tout simplement pas vous permettre des sprints de 2 semaines. Si l'un d'entre eux échoue, il ne vous reste plus qu'un seul coup pour inspecter et adapter.
C'est pourquoi lors de la phase de planification, nous avions opté pour des sprints d'une semaine. Ce choix nous a permis de valider, apprendre et ajuster rapidement.
Travailler dans Scrum en sprints d'une semaine, réunions fréquentes sont votre pain et votre beurre. Vous devez faire de la place pour ceux dans les agendas chargés de tout le monde et commencer à coordonner la date et l'heure de chacun dans les plus brefs délais. Il est également recommandé de réserver les chambres pour les réunions à l'avance, afin que vous n'ayez pas à vous en soucier à la dernière minute.
Vous pouvez également configurer des outils rudimentaires pour le projet à l'avance. Jira, GitHub, Jenkins, etc. Cela ne prend pas beaucoup de temps, et si votre projet commence juste cette instance, vous serez reconnaissant d'avoir un endroit pour stocker vos histoires ou stocker, créer et déployer votre code. Outils tiers comme les fournisseurs de taux d'e-mail, AWS ou API relèvent également de cette étape. Notez que les outils SaaS offrent des niveaux gratuits pour les startups, que vous pouvez mettre à niveau vers des plans payants ultérieurement.
Cela dépend cependant de l'entreprise pour laquelle vous travaillez. Parfois, les équipes doivent gérer elles-mêmes l'outillage lors du premier sprint. En fait, j'ai été surpris - très agréablement, devrais-je ajouter - d'apprendre que chez STX Next, il suffisait de quelques simples demandes au service administratif. L'ensemble de l'outillage nous attendait le lendemain matin. Attention, cela peut prendre beaucoup plus de temps dans d'autres entreprises.
Parlant de (cette) expérience, je ne saurais trop insister dessus :mieux vous vous préparez à l'avance, plus il vous sera facile de vous adapter aux circonstances changeantes - ce qui arrive presque toujours - et de garder faire avancer le projet.
Nous avons coopéré dans 2 fuseaux horaires différents. La phase d'exécution a constamment évolué. Les réunions ont été repoussées et déplacées. Il y avait beaucoup à jongler. Sérieusement, tant de pièces mobiles. Nous n'aurions pas réussi si nous n'avions pas été aussi préparés que nous l'étions.
Mettez en œuvre les valeurs fondamentales de Scrum
D'accord, disons que vous avez planifié et conçu votre produit. Les outils sont tous configurés, les histoires écrites et estimées ; il ne reste plus qu'à mettre le travail en place.
Pour ce MVP, nous nous sommes appuyés sur Scrum et Jira. Le tableau Jira était le modèle de ce que nous devions construire, tandis que le guide Scrum servait de manuel pour savoir comment le construire.
Les valeurs fondamentales nous avons mis en œuvre dans notre processus de développement :
- Engagement
Chaque membre de l'équipe était pleinement engagé à atteindre les objectifs du sprint, même si cela impliquait de faire des heures supplémentaires, que ce soit une heure ou une nuit blanche (un occasionnel un, au plus !). Le moyen le plus rapide de tenir les promesses que nous avions faites était de donner la priorité à l'exécution des tâches que nous avions déjà ouvertes. De cette façon, nous avons déployé une grande partie des histoires, au lieu de les commencer.
- Concentrer
La concentration est un must absolu dans les sprints courts. Toute notre équipe s'est concentrée sur des objectifs de sprint spécifiques et des tâches qui étaient essentielles à un moment donné. Afin d'exécuter avec efficacité, vous ne pouvez pas vous permettre de perdre la concentration, même pas un instant.
- Respecter
Le respect doit aller de haut en bas, ainsi que d'un côté à l'autre, pour ainsi dire.
Nous respections notre client et obtenions son respect en retour. Nous avons dépensé leur argent principalement sur les fonctionnalités ayant la plus grande valeur commerciale, au lieu d'éventuelles redondances. Nous étions également réalistes quant aux attentes pour chaque sprint et n'avons inclus que les fonctionnalités réellement terminées dans la démo pour le client. Certains plantages étaient inévitables pendant la démo, mais ils se sont produits sporadiquement grâce au soutien indéfectible que nous avons reçu du QA.
En plus de respecter notre client, nous nous respectons également. Nous avions tous nos forces et nos faiblesses, et être compréhensif et raisonnable à l'égard des deux était le seul moyen d'assurer une coopération harmonieuse à chaque extrémité.
- Ouverture
Une qualité inestimable dans tout environnement de travail d'équipe. Nous avions tous travaillé pour nous améliorer dès le premier jour avec l'équipe, et chacun d'entre nous en a bénéficié.
Il est essentiel de créer une atmosphère dans l'espace de travail où tous les membres de l'équipe communiquent leurs bloqueurs, demandent de l'aide et échangent des opinions. Tout le monde devrait avoir le même droit et les mêmes opportunités d'être entendu.
Accomplissez cela, et les membres individuels deviendront vraiment une équipe. Les décisions prises seront soutenues et exécutées, même si elles sont prises par compromis.
- Courage
Très souvent, vous ne pouvez atteindre vos objectifs de sprint planifiés que si vous êtes courageux. Nous nous sommes permis de nous concentrer davantage sur la recherche de nouvelles idées pour faire le travail à tout prix, plutôt que de nous efforcer de répondre à tous les critères d'acceptation jusque dans les moindres détails.
C'est le courage qui nous a aidés à créer des points d'action pour des améliorations lors des réunions rétro et à les mettre en œuvre lors du prochain sprint.
Il a fallu du courage pour donner une mission extrêmement urgente à un groupe de gars qui venaient d'être embauchés.
Il y avait du courage dans chaque commit que nous avons fusionné dans le code source. Voyez par vous-même !
Ajustez et répétez
Dès que nous avons commencé à coder, nous avions une idée précise de notre objectif. Notre ambition était à travers le toit et il semblait qu'il n'y avait pas d'engagement trop grand pour nous. Nous étions convaincus que nous surmonterions tous les défis sur notre chemin et rien ne pourrait nous empêcher de respecter notre échéance.
C'est pourquoi il n'est pas surprenant que notre premier rapport de sprint ressemble à ceci :
C'est un bon début, n'est-ce pas ? Nous en avons pris trop, trop tôt, et nous nous sommes lancés directement dans le sprint sans estimer les histoires. À cause de cela, nous n'avons pu terminer que certaines histoires, après les avoir finalement estimées lors de la première réunion. Combien d'histoires avons-nous fini, vous pouvez demander? La réponse est 3. Nous avons terminé 3 histoires.
Heureusement, nous avons appris de plus en plus sprint par sprint, en prenant des éléments d'action rétrospectifs et en leur donnant vie. 4 itérations plus tard, notre burndown de sprint était incomparablement meilleur :
Et c'est là que réside la beauté et la simplicité de Scrum :construire des choses avec transparence, les inspecter après chaque sprint et adapter votre processus chaque fois que possible.
J'aimerais vous dire que c'est une solution unique et que les choses se passent toujours comme vous le souhaitez. Malheureusement, je serai le premier à admettre que le plus souvent, vous avez besoin de plus de 4 itérations pour atteindre votre objectif. Peut-être juste quelques-uns de plus, mais, vous savez, encore plus.
(De plus, je sais que j'ai oublié de fermer le sprint. Désolé !)
Quelle est la prochaine ?
Le MVP est actuellement dans la phase de validation de l'idée du produit, à la recherche de nouvelles directions de développement.
Qu'est-ce que cela signifie pour vous ?
Cela signifie que notre équipe de développeurs de rêve a un peu de temps libre. Donc, s'il vous arrive d'avoir besoin d'une magie d'ingénierie logicielle axée sur les résultats, la résolution de problèmes, faites-nous savoir si nous pouvons vous aider !
En attendant, il n'y a pas de repos pour les méchants. Depuis un moment maintenant, nous avons caressé l'idée de concevoir et de construire un MVP pour un produit commercial en moitié le temps qu'il nous a fallu avec ce MVP. Oui, vous avez bien lu :cette fois-ci, nous visons un délai de 2 semaines.
Le travail est en cours pour le moment. Vous voulez savoir comment ça se passe ? Restez à l'écoute pour mon prochain article de blog, ou mieux encore, abonnez-vous à notre newsletter et recevez une notification dès que la publication est publiée.
Merci d'avoir lu, et à bientôt !
