papercraft : le secret des PO de papernest pour sortir des features sans une seule ligne de code
Des user stories à zéro story point ? 30 par sprints 🙂
À l’origine
Notre job à papernest est de simplifier la vie administrative des gens. En pratique, ça se matérialise notamment par la création de formulaires dynamiques pour souscrire des contrats comme l’énergie, internet ou l’assurance.
On a donc eu très vite une problématique : on avait (et on a toujours) tout le temps besoin de changer les formulations des questions que l’on pose dans notre app pour les rendre de plus en plus claires. On ne vous apprend rien en vous disant que l’administratif est jargonneux et compliqué…
C’est pourquoi on a mis en place un système pour changer facilement les textes de l’app. Comme on aime bien ce qui est clair, on a appelé ça « Les Textes ».
Les changements étaient faciles à faire et c’est donc l’équipe produit (en fait une seule personne à l’époque) et pas l’équipe technique qui a pris en main l’outil.
Ainsi les gens du produit ont pu changer l’app directement sans passer par les développeurs. On faisait des mises en production pour reprendre la terminologie exacte.
Mais on ne s’est pas arrêté en si bon chemin… très rapidement on a étendu le système non plus aux seuls textes de l’app mais carrément à toute l’app de papernest.
Résultat : aujourd’hui, l’équipe produit a directement les mains dans le produit. On crée un tableau de bord, des parcours de souscription, on change les questions, on réutilise de mille façons différentes notre librairie de composants.
On peut aussi voir ça comme une matérialisation avancée d’un Design System utilisable directement par l’équipe produit pour générer l’app. La liberté offerte est incroyable, en contrepartie cela modifie en profondeur le rôle de l’équipe.
Le crafting d’app
Que produit l’équipe produit à papernest ? (excepté des tickets…)
Pas du code Python ou Javascript comme les développeurs, ni du pixel ou des prototypes comme les designers. Quelque chose un peu entre les deux… à mi-chemin entre du design d’expérience et du code très simplifié : en deux mots, du crafting d’app.
On a donc renommé notre vénérable outil « Les Textes » en…
À quoi ressemble papercraft ? Un ensemble de petits fichiers textes qui décrivent précisément l’app. Voilà par exemple, le formulaire de souscription à l’énergie vu depuis papercraft :
Et si on zoom dans electricity_cut.yaml voilà ce qu’on y trouve :
On a rendu la syntaxe suffisamment claire pour que les nouveaux membres de l’équipe puissent être efficaces après 2 h de formation.
Évidemment comme pour un bon vin, certaines subtilités de l’outil se découvrent avec le temps !
Une pelletée d’avantages :
#1 : Maximiser le retour sur investissement des développeurs
À papernest, les développeurs créent des composants réutilisables et fortement paramétrables. Chaque composant doit être le plus générique possible. C’est souvent plus long au départ, mais l’investissement est généralement très rentable à terme.
La librairie de composants est ensuite manipulée par l’équipe produit qui part de ce qui existe déjà pour créer des nouvelles fonctionnalités.
Conséquence :
Les dév. ne font que ce qu’ils sont seuls à savoir faire
Avec papercraft, ils sont déchargés de taches telles que :
- personnaliser l’app aux couleurs d’un partenaire,
- changer l’ordre des questions d’un formulaire,
- changer un wording,
- adapter un parcours utilisateur pour une partie du trafic etc.
Autrement dit : papercraft permet de céder à l’équipe produit toute la brique supérieure de l’app.
#2 : Rendre le Produit à l’équipe Produit !
Alors que ça n’était pas l’objectif initial, le fait de pouvoir manipuler directement la partie visible de l’app a changé la donne :
- On peut essayer nos idées sur le produit final et le montrer à des utilisateurs pour récolter leurs retours avant de mettre en prod.
- On fait une quantité énorme de modifications (autour de 30 par sprint) sans rédiger de ticket ni perdre de temps à communiquer ce qu’on a en tête (pas de téléphone arabe).
- De la faute d’orthographe à une nouvelle partie de l’app, on est aujourd’hui capable de sortir des user stories à zéro story point.
Par exemple, je pourrais tout à fait arrêter la rédaction de cet article et créer un formulaire pour souscrire à une salle de gym (cela me prendrait une quinzaine de minutes, tests et déploiement inclus)…
Et le meilleur pour la fin :
On a intégré un système maison d’AB testing directement dans papercraft
Chaque composant peut exister en plusieurs versions, accessible à une fraction d’utilisateurs. On est allé encore plus loin, car chaque paramètre (et même sous-paramètres !) d’un composant est testable. De cette manière, nos AB tests sont gérés exclusivement par l’équipe produit avec un niveau de personnalisation absolu.
Depuis la mise en place du système, près d’une centaine de tests ont été menés.
L’organisation autour de papercraft
Les équipes produit et dev travaillent de la manière suivante :
- les PO en collaboration avec les designers imaginent des composants
- les développeurs codent ces composants de la façon la plus customisable possible
- les PO ajoutent dans papercraft de multiples occurrences du composant paramétrées selon les besoins.
Un tel changement de paradigme s’accompagne nécessairement d’une organisation adaptée :
- L’équipe produit gère toutes les modifications de papercraft sur des branches Git. On s’en passait lorsqu’une seule personne manipulait l’outil. Mais avec une petite dizaine de personnes qui ont les mains dedans, on n’a pas eu le choix. Contrairement à nos craintes initiales et malgré une courbe d’apprentissage un peu raide, tout s’est relativement bien passé.
- Le rôle de Product Manager inclut désormais le fait d’être garant de ce système. C’est-à-dire : vérifier les modifications des membres de l’équipe et maintenir l’ensemble propre (nomenclature claire, architecture cohérente).
- Notre équipe de QA testeurs valide les modifications de papercraft comme ils le feraient pour du code.
À vous de jouer 🙂
Comment profiter de ces avantages dans votre organisation ? La première étape et la plus importante à mon sens : identifiez les tâches qui reviennent le plus souvent.
Construisez ensuite le système qui permettra aux principaux concernés (souvent les PO ou l’équipe marketing) de s’en charger eux-mêmes !
PS: Pour maximiser l’impact de votre équipe produit & tech, pensez à installer un workspace surpuissant.
