Test & Learn - Passez en mode Ultra Agile avec le Nocode

L'une des spécificités du métier de Product Builder est notre capacité à gérer un projet de bout en bout : c'est à dire de la phase de discovery à la phase de delivery jusqu'à la définition et l'exécution des prochaines itérations du projet. C'est ce processus itératif que je vais vous présenter dans cet article. Comment le No code permet de passer en ultra-agile avec de multiples itérations produit ?

Alors que dans une équipe produit traditionnelle, la phase de discovery peut prendre un certain temps, le nocode va nous permettre de réduire considérablement cette phase. Ce qui va être important, c'est de créer un cadre et d'aller vite. On va se concentrer sur le besoin fondamental qu'on veut résoudre, le POC, mais cette première brique doit nous permettre d'itérer autour d'elle. Pour créer cette approche modulaire de la conception, on va se concentrer sur :

• L'architecture de notre base de donnée
• Les outils nocode et services qu'on va sélectionner méticuleusement
• La scalabilité et l'efficience de ce qu'on produit
• Et notre capacité à onboarder les équipes dans ce processus de création et d'apprentissage

Le nocode a le pouvoir de rendre notre travail ultra agile en nous permettant de créer rapidement quelque chose de fonctionnel. Par exemple, pour un produit interne, cela signifie que l'utilisateur pourra avoir un produit entre les mains en moins d'une semaine. Après cela, il est important de recueillir un grand nombre de retours d'utilisateurs pour améliorer notre produit.

Cette approche peut être déroutante au début, mais pour qu'elle fonctionne, il est important de respecter certaines règles de base. Au fil des projets, chez Gojob, nous avons appris à travailler en équipe et avons mis en place une méthode de développement agile qui a fait ses preuves, même s'il y a toujours de la place pour l'amélioration.

Première version de l'Order Book, le carnet de commande Gojob (Voir fin de l'article pour plus de contexte)

1- La phase de conception

Le nocode peut réduire considérablement la durée de la phase de conception d'un projet, mais cette phase ne doit pas être négligée. Elle nous permet, tout d'abord, de bien identifier les besoins du projet en menant de nombreuses interactions avec les différentes parties prenantes :

• Le métier est une partie prenante essentielle pour identifier les besoins du projet et fournir des informations concrètes sur ce qui va être réalisé. Nous pouvons également nous appuyer sur le métier pour identifier les indicateurs de performance que nous souhaitons suivre afin de valider ou non la réussite du projet. Ces indicateurs peuvent être à la fois liés au business (taux de conversion) et à l'utilisation ou l'impact du projet (adoption, temps gagné, etc.).

• Le produit nous aide à déterminer ce que nous souhaitons réaliser en V0. Il peut également nous aider à prioriser les premières itérations d'un projet en nous donnant une direction claire, tout en sachant que nous pouvons modifier nos plans à tout moment.

• Nous pouvons également avoir besoin de discuter avec d'autres interlocuteurs, comme des équipes techniques ou data, afin de valider la faisabilité technique de certaines parties du projet, l'accès à certaines données ou la connexion à des services internes ou externes.

La communication est cruciale pendant cette phase. En plus de répondre à toutes les questions que nous pouvons nous poser en tant que Product Builder, elle nous permet surtout de partager nos observations et notre analyse de ce que nous sommes capables de réaliser en V0. Nous devons également être ouverts à la discussion et partager les livrables de la conception avec tous les interlocuteurs pour valider l'alignement entre les différentes parties. Pour cela, nous utilisons souvent l'outil FigJam de Figma pour créer des documents visuels qui expliquent les différents flux (automatisations) de nos projets et Notion pour centraliser toutes les notes utiles pour la compréhension globale du projet.

Mapping visuel d'une automatisation (Brief Consultant, fonctionnalité de l'Order Book, voir fin de l'article pour plus de contexte)

Dans le cas d'une application Web, nous faisons généralement très peu de maquettes car nous allons produire la V0 du projet très rapidement et préférons mettre l'outil entre les mains des utilisateurs pour recueillir leurs retours et faire évoluer la plateforme presque instantanément.

La dernière étape de la phase de conception consiste à sensibiliser les utilisateurs à la méthodologie de travail afin d'éviter toute frustration :

• La V0 est la première version de ce que nous souhaitons réaliser. Les différentes fonctionnalités seront mises en place au fil des itérations. Ne vous inquiétez pas si cela ne correspond pas à votre produit idéal, nous allons le construire ensemble.
• Nous avons besoin de recueillir autant de retours d'utilisateurs que possible, que ce soit sur le comportement des automatisations, la structure de l'application, le parcours utilisateur ou l'accès et la visualisation des données. Cela nous aidera à améliorer notre produit et à répondre au mieux aux besoins de nos utilisateurs.
• Nous souhaitons que chaque bug ou comportement anormal soit immédiatement signalé et remonté. Bien que nous effectuions de nombreux tests pour assurer la fiabilité de notre solution, les retours des utilisateurs sont particulièrement précieux pour nous. Nous les utiliserons pour améliorer notre produit et répondre au mieux aux besoins de nos utilisateurs.

Pour faciliter les échanges d'utilisateurs, nous allons créer un channel Slack dédié. Cela nous permettra également de communiquer sur les mises en production des différentes modifications apportées au produit.

2- La V0 le plus rapidement possible

Comme vous l'aurez compris, notre principal objectif est de mettre en place une version fonctionnelle de notre preuve de concept le plus rapidement possible. Ce qui a le plus de valeur pour nous, c'est le retour de nos utilisateurs et les premières données que nous parviendrons à identifier et à exploiter pour la suite du projet. Toutefois, il y a certaines règles à respecter :

• Structure de notre base de données : Même si nous avons une vision à court terme pour notre preuve de concept et que nous prévoyons de mettre en place une V0 avec peu de fonctionnalités, l'architecture de notre base de données est un élément à prendre en compte sur le long terme. Une mauvaise structure de notre base de données peut limiter l'agilité que nous avons gagnée grâce au nocode. En effet, une fois la version fonctionnelle en ligne, nous commençons à stocker des données. Un changement de structure de notre base de données peut affecter la qualité de ces données. De plus, une mauvaise structure de base de données peut rallonger les délais de production des prochaines itérations car nous devrons consacrer une partie de l'itération à restructurer la base.
• Tester et fiabiliser : Même si nous pouvons simuler des environnements de tests, l'un des aspects particuliers du nocode est que tout est nativement en production. Il est donc crucial de tester et de fiabiliser tout ce que nous faisons. Avec le temps, nous parvenons à identifier facilement les éléments qui sont sources d'erreurs et à les prévenir. Il est important d'avoir un bon système d'alerting pour être réactif dans la correction de bugs. Vous pouvez consulter l'article de Thibaut 2 erreurs à éviter pour des solutions fiables et évolutives pour en savoir plus sur ce sujet.
• Mise en place des indicateurs de performance : La collecte et la mise à disposition de données est souvent négligée dans un projet nocode alors qu'elle est essentielle. Cela nous permettra de valider ou non nos hypothèses sur les prochaines itérations et de surveiller l'avancement de notre projet.

Le Product Builder doit avoir une bonne connaissance de l'écosystème nocode. Il ne s'agit pas de maîtriser parfaitement tous les outils et de se considérer comme expert dans tous les domaines, mais plutôt de connaître le marché et de comprendre ce que l'on peut faire avec chaque outil pour orienter nos choix. Le choix des outils a également un impact sur notre agilité. Par exemple, si j'ai besoin de stocker, de modifier et de rendre facilement accessible des données, je vais privilégier l'utilisation d'Airtable. Si j'ai un grand volume de données et que j'ai besoin de les historiser, je pourrais préférer une simple feuille de calcul Google et/ou un entrepôt de données comme Big Query.

Stack Nocode Gojob

Lors de cette première itération, j'aime beaucoup être présent aux côtés de l'équipe. Je m'assois régulièrement avec eux pour comprendre comment ils travaillent, leur demander leur avis sur l'interface et leur faire des propositions. Cela permet de les inclure dans le processus de création et de les former à l'utilisation de l'outil. En moyenne, nous sommes en mesure de délivrer la V0 en moins d'une semaine. Cela suscite souvent un véritable "effet Wow" en raison de notre rapidité de délivrabilité.

La V0 est toujours accompagnée d'une importante phase de monitoring et de formation des équipes pour les familiariser avec la solution. Nous fournissons généralement une documentation complète avec une notice, des vidéos et des moments de Q&A pour récolter les feedbacks et répondre aux questions sur l'utilisation de l'outil. Nous faisons évoluer cette V0 en fonction des feedbacks jusqu'à ce qu'elle soit fonctionnelle et adoptée par tous.

3-Analyse, apprentissage et itérations

Une fois que la version initiale de notre produit (V0) est en place, nous pouvons commencer à analyser les données et les retours de nos utilisateurs. Nous examinons d'abord ce qui fonctionne bien et ce qui peut être amélioré. Nous nous demandons également ce qui manque le plus à notre produit pour atteindre nos objectifs. Ensuite, nous regardons les indicateurs de performance pour voir comment le produit est utilisé et comment il se comporte. Enfin, nous réunissons les différents interlocuteurs (Business, Produit, Tech...) pour prioriser les prochaines itérations en fonction de ces éléments. En tant que concepteur du produit, le Product Builder joue un rôle crucial dans cette phase, en imaginant et en évaluant les prochaines fonctionnalités par rapport à celles existantes, et en apportant une perspective technique au choix de la priorisation. En effet, notre capacité à délivrer de la valeur rapidement rentre en compte dans notre matrice de priorisation.

Dashboard d'analyse des performances des recruteurs

Le Product Builder est également responsable de la qualité technique de la solution. Chaque itération s'accompagne d'une phase de conception. Les différents points qui vont nous permettre d'apprendre sont :

• Récolter et analyser les retours de nos utilisateurs. On va d'abord se focaliser sur l'existant. Qu'est ce qui peut être mieux fait? Quelle est l'adoption de notre outil? Pourquoi? Quels besoins ne couvrons-nous pas?
• On va aussi se pencher sur notre besoin primaire. Est ce qu'on répond au besoin? Qu'est ce qui peut être optimisé? Qu'est ce qui nous manque pour atteindre nos objectifs? Quelles fonctionnalités on veut par la suite?
• On va enfin analyser nos indicateurs de performance et revoir nos objectifs si nécessaire.

En utilisant les données recueillies, les différentes parties prenantes du projet se réunissent pour établir une liste de priorités pour les prochaines itérations. Le Product Builder, en tant que concepteur de la solution, a aussi le devoir d'être créatif dans l'imagination des nouvelles fonctionnalités du produit. L'expertise technique associée à la connaissance produit permet d'être proactif dans la proposition de nouvelles solutions.

4- Quand s'arrêter d'itérer?

Selon notre méthodologie, il est important de définir le cadre du projet même si celui-ci peut être modifié au cours des itérations. Tout ce que nous allons développer vise à atteindre le même objectif, à savoir résoudre la problématique identifiée initialement. Pour évaluer les performances de notre produit, nous mettons à disposition des indicateurs de performance qui nous permettent d'analyser son rendement. Nous devons alors être en mesure de fixer des objectifs pour valider le succès du projet. Je vais illustrer cela avec un exemple concret.

Gojob travaille avec des clients qui vont transmettre des commandes d'intérimaires à nos consultants. Lorsque le besoin est récolté, il doit être transmis aux recruteurs et ceux-ci vont s'occuper de trouver les bons candidats. Ils devront ensuite transmettre ces candidats aux consultants qui vont les proposer au client. La problématique qui s'est posée est : "Comment améliorer notre capacité à proposer des candidats pertinents rapidement à nos clients?"

Ce projet a donné naissance à notre Order Book, le carnet de commande Gojob. L'idée est de centraliser l'ensemble des commandes de nos clients dans un Airtable afin de pouvoir coordonner efficacement les équipes qui devront répondre à ces commandes. Ce carnet permet de récolter les commandes, de les prioriser, de les allouer à un ou plusieurs recruteurs. On peut alors imaginer un nombre incalculable de fonctionnalités qui nous permettront d'automatiser tous les processus opérationnels autour de cet outil.

Si on découpe les différentes itérations par rapport à notre problématique :

1. On a d'abord centralisé la réception des commandes de nos clients sur Airtable.
2. On a ensuite créé la possibilité d'allouer un ou plusieurs recruteurs à la commande.
3. On a créé un système de priorisation des commandes pour faciliter notre capacité à répondre rapidement à un besoin.
4. On a mis en place un système d'alerting pour améliorer la réactivité des équipes
5. Grâce à la centralisation on a mis en place des dashboard d'analyse de performances très précis.
6. Un nouveau projet est né en relation directe avec l'Order Book. On a automatisé des actions de sourcing en sollicitant notre base de données intérimaire à chaque fois qu'une nouvelle commande est ajoutée.
7. On a enrichi nos commandes grâce aux informations de nos clients pour affiner notre système de priorisation.
8. On a créé un système de création semi-automatisé de brief à partager entre les consultants et recruteurs pour faciliter les intéractions.

Certaines de ces itérations sont devenues des projets à part entière, mais toutes ont eu un temps de production initial très court. Néanmoins, le projet Order Book évolue régulièrement depuis plus d'un an et est adopté par l'ensemble de l'équipe opérationnelle de Gojob. Nous apprenons de chaque itération et modifions l'outil en fonction des retours d'utilisateurs lorsque nous estimons que cette itération peut contribuer à améliorer significativement les performances des équipes.

Folder du projet Order Book sur Make.

Ce qui déterminera si nous arrêtons les itérations est notre incapacité à trouver de nouveaux leviers d'amélioration qui contribuent à résoudre notre problématique. Grâce aux apprentissages, nous avons réussi à créer un produit sur mesure et parfaitement adapté à l'écosystème Gojob. La question qui s'est alors posée était la suivante : Pourquoi ne pas intégrer l'Order Book à notre Back Office ? La réponse est assez simple : nous ne voulons pas perdre l'agilité que nous avons acquise grâce à cet outil. Il y a évidemment des inconvénients à maintenir un outil aussi central pour notre métier en dehors de notre BackOffice, mais nous en parlerons dans un prochain article.