Cet article a pour objectif de décrire les étapes nécessaires et sujets qui doivent être anticipés avant l’arrivée de l’équipe de développement d'un prestataire. Afin que cette dernière puisse être pleinement et immédiatement opérationnelle.
Préparer un kick-off
C’est l’étape primordiale qui permet d’embarquer la nouvelle équipe à bord de votre produit tout en lui transmettant votre connaissance.
Votre vision produit, business model
Plus la vision produit et votre business model seront clairement expliqués, plus l’équipe de votre prestataire sera à même de comprendre les choix réalisés et ceux à venir. De plus, parce que l’objectif est de raisonner par “valeur”, une équipe qui aura une connaissance fine de la vision produit et de son business model sera beaucoup plus pertinente pour vous proposer des idées de fonctionnalités ou d'évolutions auxquelles vous n’auriez pas pensé car vous n’avez pas “les mains dedans”.
Outils, droits, dépôts de fichiers et accès
L’équipe du prestataire va devoir travailler dans votre environnement et donc utiliser vos outils : il leur en faut donc un accès (Google Drive, Jira, Github…).
Pensez à bien lister ces éléments en amont et à vérifier les licences associées, car un compte supplémentaire est parfois synonyme d’une licence à payer en plus (ou parfois de passer de la version gratuite à la version payante).
S’assurer de connaître suffisamment votre produit et son contexte
Pour que l'efficience de l’équipe de votre prestataire soit maximale : il vous faut avoir balayé toutes les zones d’ombres qui entourent votre produit afin d'éviter tout ajustement a posteriori.
Risques et hypothèses
Un produit se construit de manière itérative, dans un contexte changeant et pour lesquels les acteurs et décideurs ont une rationalité limitée. Vous avez donc émis en amont du projet des hypothèses (exemple : nos utilisateurs souhaitent mettre en favoris des éléments avant de les mettre dans leur panier et de finaliser leur achat). Vous devez les vérifier avant d’envisager engager votre future équipe dessus.
User journey et persona
Afin que l’équipe qui arrive puisse être opérationnelle instantanément, elle s’attend à ce qu’on lui fournisse un ensemble de documents liés au produit pour en expliquer son fonctionnement, les interactions qu’ont les utilisateurs avec le métier…
Proposez a minima : un user journey, et des fiches sur les principaux personae.
Une roadmap
Il est primordial d’offrir une vue d’ensemble, même macro, à la future équipe afin qu’elle puisse anticiper les prochains grands jalons, les objectifs en cours et à venir, ainsi que les grandes étapes du produit.
Une roadmap à jour est donc un incontournable.
Disposer d’assets graphiques et d’artefacts directement utilisables et validés
Il est crucial que pour l’arrivée de l’équipe de votre prestataire que vous ayez réalisé la plus grosse partie de l’UX design, de la création graphique ainsi que de la rédaction de vos spécificités fonctionnelles ou user stories.
Design system et bibliothèque de composants
Vous devrez fournir à l’équipe des éléments graphiques prêts à être intégrés : par exemple un export sur Zeplin.io, des maquettes Sketch, un storybook déjà réalisé par une autre équipe portant sur le même projet, un design system fait par l’UX/UI et qui contient les différents styles de boutons et leurs états, en plus des maquettes desktop et mobile de toutes les pages.
Backlog priorisé et story mapping
Ayez à disposition un backlog priorisé qui reprend toutes les fonctionnalités souhaitées, détaillées du point de vue utilisateur (exemple : “en tant qu’utilisateur je souhaite pouvoir ajouter un produit dans mon panier depuis n’importe quelle page produit”) avec des règles métiers (exemple : ajouter un produit dans son panier ne retire pas le produit du stock, il le "réserve" juste pour 15 minutes) et la maquette ou le composant graphique associé.
L’équipe dans votre organisation
On dit souvent, à juste titre, qu’un produit est le reflet de l’organisation de l’entreprise qui le produit.
La méthodologie
Tout d’abord, commençons par la méthodologie de travail de l’équipe. Est-ce que l’équipe sera libre et autonome sur ce point ? Peut-elle appliquer un framework AGILE comme SCRUM ? Êtes-vous à l’aise avec des livraisons itératives toutes les deux semaines ? L’équipe pourra-t-elle faire tester ces fonctionnalités auprès d’utilisateurs le plus rapidement possible ?
Toutes ces questions devront être définies en amont du projet et sont directement liées à sa réussite.
Les points d’arbitrage et de pilotage envisagés
Comment allez-vous fixer et mesurer l’atteinte des objectifs de l’équipe ? À quelle fréquence souhaitez-vous pouvoir échanger avec elle, sur quels critères souhaitez-vous avoir un pouvoir décisionnel versus sur quels éléments leur accordez-vous une totale autonomie ?
Vous pourriez par exemple décider de fixer des OKRs (Objective Key Results) trimestriels à l’équipe et qui découlent directement des objectifs de l’entreprise, puis de fixer une démo du travail accompli toutes les deux semaines, et enfin un comité de pilotage et de revue de la roadmap tous les deux mois.
Les processus de validation
Qui valide les éléments qui sont transmis à l’équipe ? Qui valide la priorisation ? Qui valide les éléments livrés ? Qui fait la recette ? Qui dit “OK pour la production” ? Ce sont toutes ces questions qui doivent avoir trouvé leur réponse avant l’arrivée de l’équipe de votre prestataire.
Vous pouvez par exemple mettre en place une matrice RACI pour vous aider à identifier et figer les rôles et processus de décisions.
Pour en savoir plus sur Eleven Labs, cliquez-ici et pour plus de contenus, cliquez-ici
Participer à la conversation