Les rôles ne font pas les règles

J'ai rejoint Figma en tant qu'indépendant en 2016, alors que l'équipe comptait 12 développeurs. Avant de prendre mes fonctions, je dois admettre que j'étais sceptique quant à la possibilité de construire un outil collaboratif performant sur un navigateur Web. Aujourd'hui, j'ai l'impression que c'était il y a une éternité, mais à ce moment-là, il y avait un regain d'intérêt pour les applications et les appareils mobiles. Mais à l'époque, la construction des expériences sur le Web à la hauteur de leurs équivalents originaux avait été marquée par de retentissants échecs. Figma est le fruit d'une véritable révolution, à la fois technique et culturelle. En effet, l'introduction d'API de navigateur de niveau inférieur, comme WebGL et Web Assembly, nous a permis de repenser ce qu’il était possible de faire sur le Web. Ce bouleversement est le résultat du travail d'une génération qui a grandi avec des outils tels que Google Docs, et s'est encore accéléré ces dernières années avec le travail hybride et à distance, qui a montré toute l'importance d'une collaboration simultanée.

Aujourd'hui, nos outils se doivent d'être toujours plus multijoueurs par défaut. D'ailleurs, nos attentes vis-à-vis des outils ne sont pas les seules à avoir évolué : nos relations interpersonnelles ont également changé, tout comme nos attentes les uns par rapport aux autres. Depuis l'époque où j'ai commencé à écrire du code en tant que freelance, jusqu'à mon rôle de responsable d'équipe, j'ai beaucoup réfléchi à ce que ça voulait dire pour les développeurs. Comment notre rôle évolue-t-il au fur et à mesure que le développement de produit perd en linéarité ? Comment collaborer au mieux quand on est développeur ? Et est-ce toujours pertinent ?

On peut ainsi facilement tomber dans les extrêmes. Si une collaboration étroite permet d'obtenir de meilleurs résultats, pourquoi ne pas demander du feedback en permanence pour s'améliorer encore et toujours ? De manière générale, j'ai remarqué que la limite entre tirer parti de la sagesse des autres et tourner en rond sans avoir d'orientation claire est ténue. En pratique, il est parfois nécessaire de travailler de son côté, d'autres fois de se tourner vers les autres. D'après mon expérience, chaque personne doit trouver son équilibre idéal entre indépendance et convergence, en fonction du contexte culturel, des produits conçus et des optimisations voulues. Pour vous aider à trouver cet équilibre, je souhaiterais vous présenter notre propre approche de la collaboration dans le domaine de la création et du développement de produits.

L'époque où la création de produit commençait par le design et se terminait par le développement est désormais révolue. Pourtant, dans de nombreuses entreprises, les product managers et les designers se chargent de définir la roadmap, tandis que les développeurs l'exécutent. C'est une problématique que j'ai voulu prendre à bras-le-corps avec Yuhki Yamashita, mon homologue au sein de l'équipe produits. Nous travaillons en étroite collaboration et cela se ressent dans l'ensemble de notre organisation. Les développeurs ne se contentent pas de définir comment faire les choses, ils se demandent également quoi faire, en travaillant de façon rapprochée avec leurs collègues d’équipes transverses et en écoutant les retours de clients.

Lors du lancement de nouvelles pistes de travail, nous encourageons toujours les collaborateurs à prendre en compte différents points de vue le plus tôt possible, afin que le document de départ évolue au gré des idées apportées par le reste de l'équipe de développement des produits. Les développeurs doivent rédiger un premier jet pour recueillir les retours de leurs collaborateurs pendant qu'ils travaillent encore sur le projet, pas seulement lorsqu'il semble prêt. Presque tous les projets comportent un document pour garder la trace de ce premier jet ; la difficulté consiste à obtenir rapidement l'avis des autres équipes alors qu'elles ont leurs propres échéances à respecter.

C'est pourquoi nous organisons régulièrement des « critiques » qui réunissent nos équipes design et développement, afin d'avoir un moment et un lieu dédiés à la récolte du feeback des autres équipes. Ces réunions sur le développement jouent un rôle très spécifique et permettent de solliciter des retours de manière précoce et fréquente. Elles permettent également d'obtenir l'aide d'experts sur des designs techniques. En revanche, elles n'entrent pas dans le cadre d'un processus de validation. Rien ne se décide ni ne se résout pendant ces « critiques » de développement, car ces réunions ne sont pas conçues pour cela. L'objectif est de travailler sur les designs jusqu’à ce qu’ils n’aient même plus besoin d’être validés. Nous utilisons FigJam pour animer ces réunions, afin que chacun puisse y participer en temps réel. C'est très ludique !

Les critiques ne servent pas à valider les designs, mais à solliciter le feedback d'autres équipes de manière précoce et fréquente. Nous encourageons les participants à s'impliquer dans le travail en cours, et à attirer l'attention sur les problèmes de manière productive sans se précipiter pour prendre une décision. Voilà le template que nous utilisons chez Figma.

Mais que se passe-t-il quand il y a trop d'avis ou des retours contradictoires ? J'ai vu des projets dérailler face à un manque d'équilibre entre créativité et exploration. Tout cela est particulièrement délicat lorsqu'il y a des compromis difficiles à faire et beaucoup d'ambiguïté à gérer, comme par exemple la définition d'un premier modèle de tarification. Un trop grand nombre d'opinions divergentes et d'idées nouvelles peut facilement aboutir à un blocage.

C'est pourquoi nous découpons les projets en étapes. Cette astuce peut paraître simple, mais le fait de définir et communiquer clairement les étapes d'un projet nous aide à mieux gérer les attentes des autres parties prenantes et à nous rappeler à l'ordre quand il est temps de trouver un terrain d'entente pour progresser et conserver notre élan. Cette notion d'élan est particulièrement importante. Elle donne l'impression que seules quelques étapes nous séparent de nos objectifs. Mais si nous perdons notre enthousiasme, nous commençons alors à tourner en rond et à remettre en question ce que nous faisons.

Chez Figma, ces jalons ne nous aident pas seulement à trouver des points de convergence, ils nous aident également à repérer les moments où l'on dévie du plan initialement prévu. En ouvrant la communication dès l'apparition d'un risque, nous pouvons faire appel à l'expertise et aux ressources des uns et des autres et ainsi retrouver notre élan. C'est précisément dans ces cas-là qu'il est utile de recueillir plus d'avis. Parfois, lorsque je remarque qu'un projet prend du retard, je me plonge dedans. Vu mon poste, les collaborateurs sont toujours surpris de mon implication dans certains domaines, mais à mon sens, il est important de s'entreaider pour surmonter les blocages et qu'aucun de nous ne fasse abstraction des détails qui nous permettent de garder le cap.

Fondamentalement, j'aime à penser que les dépendances au sein de Figma fonctionnent comme un arbre. Les feuilles peuvent changer rapidement sans mettre en danger le reste de l'arbre, mais les racines doivent être solides. Lorsque l'on définit le périmètre d'un projet à sa racine, on prend en compte des aspects totalement différents de ceux qui se trouvent au niveau des feuilles. Pour construire une base de données par exemple, il n'est pas question d'avancer vite de son côté en acceptant de faire de la casse. Les systèmes de base nécessitent de recueillir les bonnes informations et de travailler de manière beaucoup plus réfléchie que pour les éléments en haut de la pile technologique. Quand on travaille sur une fonctionnalité qui modifie l'interface sans toucher au modèle de données sous-jacent, les expérimentations indépendantes comportent souvent moins de risques, même si la casse n'est pas permise au niveau des utilisateurs. Mon rôle consiste en grande partie à faire la différence entre les feuilles et les racines, c'est-à-dire à distinguer les tâches sur lesquelles mes collaborateurs peuvent avancer vite de celles qui nécessitent une approche plus rigoureuse intégrant le feedback des principales parties prenantes.

Les changements apportés aux produits s'effectuent souvent au niveau des racines également. Par exemple, lorsque nous envisageons d'ajouter une nouvelle fonctionnalité de design primitive, comme l'auto layout, nous devons nous assurer que les nouvelles propriétés sont à la hauteur, pour ne pas prendre le risque d'altérer les workflows et les designs existants. Bien souvent, nos exploits techniques et nos lancements les plus significatifs nécessitent de prendre en compte des branches dans leur intégralité, des feuilles jusqu'aux racines, et de réfléchir au-delà d'un système, d'un langage ou des limites de l'abstraction.

Cette façon de travailler peut sembler nouvelle aux développeurs spécialisés, comme ceux qui ont de l'expérience front-end mais qui découvrent la programmation de systèmes ou infrastructures. Je suis convaincu que nous sous-estimons tous notre capacité à intégrer rapidement des connaissances. C'est pourquoi nous formons volontairement les collaborateurs de manière à ce que les développeurs puissent travailler à la fois sur les feuilles et les racines, en offrant une structure qui permet d'opérer à tous les niveaux de la pile technologique. Ainsi, nous pouvons nous appuyer sur l'expertise des uns et des autres et aborder les problèmes de front, plutôt que de les contourner. Les personnes les plus efficaces ne sont pas seulement hautement spécialisées dans leur domaine, elles sont aussi prêtes à relever les défis et à découvrir rapidement de nouveaux systèmes. Elles traquent les failles absolument partout, sans se laisser enfermer par l'intitulé de leur poste. C'est cette façon de travailler qui nous a donné le courage d'amener le design produit au Web à nos débuts.

J'ai eu l'occasion de voir suffisamment de principes, de systèmes et de processus différents dans des entreprises en forte croissance pour savoir qu'il n'y a pas qu'une seule bonne façon de travailler. De fait, les entreprises les plus prospères réussissent souvent en dépit de certaines de ces décisions. Dans un contexte où le développement et la collaboration évoluent en permanence, nous ne pouvons pas accepter que nos expériences passées limitent nos capacités à résoudre de nouveaux problèmes dans toutes leurs nuances. De même, nous devons résister à l'envie de restreindre notre champ d'action à notre fiche de poste. Il est facile de s'attacher à la définition officielle d'un rôle ou d'un processus, plutôt qu'à ce qui est attendu de nous dans la pratique : penser à partir de principes premiers, contrôler son égo et aller toujours plus loin.