L’Obeya permet de réduire le nombre d'inconnues avant de partir sur le développement d’un produit. En ce sens, c’est davantage un outil de Discovery que de Delivery.

L'un des principaux défis d’une scale-up est la montée en charge des équipes produit et des équipes techniques. Il semble en effet que ces équipes sont toujours trop lentes : la feuille de route du produit déborde de fonctionnalités à développer et tous les directeurs de la société - ventes, marketing, support client, opérations - bataillent sans relâche pour faire prioriser leurs propres demandes. C’est un défi difficile pour le CEO, et un véritable casse-tête pour le Product Manager.

Au premier abord, cela s’apparente à un problème de productivité : comment pouvons-nous amener les développeurs à produire les fonctionnalités plus rapidement ? Mais à y regarder de plus près, il apparaît que :

  1. Les développeurs passent beaucoup de temps à traiter des spécifications incomplètes ou incohérentes du fait que les besoins des utilisateurs ne sont pas clairs.
  2. Les utilisateurs demandent de nombreuses modifications en cours de développement, ce qui augmente d’autant le coût des nouvelles évolutions et fait perdre un temps précieux aux développeurs.
  3. Les évolutions génèrent de nouveaux problèmes pour les utilisateurs internes et externes, soit parce que des détails importants ont été omis lors de la spécification, soit parce que l’équipe technique s’est précipitée pour sortir rapidement les fonctionnalités et a introduit des défauts. Cela conduit alors à de nouvelles demandes de « fonctionnalités » pour remédier à la situation.
  4. Malgré tous les efforts déployés, les résultats business sont décevants.

En fait, le problème ne concerne pas le « Delivery », c’est-à-dire l'organisation des personnes et des tâches qui permet de délivrer plus efficacement les fonctionnalités. C'est plutôt une question de « Discovery » : explorer et définir ce que le produit devrait être pour faire mouche du premier coup et rendre le pari moins risqué.

Qu'est-ce que le lean nous enseigne sur le Discovery ?

Comprendre la valeur : une question de travail d'équipe

Dans une perspective lean, le Discovery consiste d’abord à comprendre comment le produit crée de la valeur pour le client, et ensuite à concevoir et construire le produit de manière à ne pas lui imposer le coût de nos propres gaspillages.

La valeur et les gaspillages doivent être pris en compte tout au long de la chaîne de valeur, et pas seulement au niveau du cœur de produit, c’est-à-dire le produit technologique proprement dit. Le Discovery englobe le produit complet - de l’expérience client aux processus internes de l’entreprise.

Prenons par exemple un service de VTC (voiture de transport avec chauffeur). Le cœur de produit est l'application utilisée par les clients pour réserver un trajet, ou bien le système qui attribue des courses aux chauffeurs. En revanche, le produit complet englobe toute la gamme de systèmes et de services qui forment l'expérience utilisateur. Dans cette perspective, un élément essentiel de la performance du point de vue du client est le temps d'attente pour une voiture. Ce temps dépend de l’algorithme d’allocation de courses, mais également du nombre de chauffeurs présents sur les routes à un instant donné. Cela signifie que pour concevoir un service qui tienne pleinement ses promesses du point de vue des utilisateurs, il faut prendre en compte toute l'expérience chauffeur et persuader des milliers d'entre eux d'utiliser la plate-forme. Ceci requiert à son tour un système scalable pour intégrer des milliers de chauffeurs, ainsi que des équipes complètes pour gérer les inévitables problèmes quotidiens.

Pour que le produit soit un succès, il faut donc concevoir un ensemble complet de produits et de processus. Par conséquent, l'équipe produit doit inclure des représentants de tous les départements de l’entreprise : produit, tech, marketing, ventes, opérations, juridique, etc.

Il est difficile de faire en sorte que toutes ces personnes travaillent vers un objectif commun, car elles ont généralement des priorités différentes et ne voient que rarement l’impact de leurs décisions locales sur l’ensemble de l’entreprise. Cette difficulté est traditionnellement pensée comme un problème d’organisation, gérée en termes de rôles et de processus, mais le lean approche le sujet sous un angle totalement différent, celui d’un exercice d’apprentissage : « Qui a besoin d’apprendre quoi pour que le produit soit un succès ?» Mais comment amener un tel groupe de personnes aussi diverses, poursuivant des objectifs différents, à apprendre ensemble et avancer dans la même direction ?

Le Chief Engineer

Toyota résout ce problème en nommant un Chief Engineer responsable de toutes les dimensions du produit. C’est une sorte d’entrepreneur, une personne pleine d’énergie, passionnée par le produit et les clients. Une personne disposant à la fois du savoir-faire nécessaire pour approfondir des questions techniques et des compétences de leadership suffisantes pour gérer les aspects politiques du projet. Steve Jobs, bien qu'il soit également CEO d'Apple, était l'archétype du Chief Engineer.

Le Chief Engineer a pour tâche principale de créer les conditions d’une collaboration étroite entre des spécialistes de domaines très différents. Il n'a aucune autorité hiérarchique sur eux, mais il a toute autorité pour faire de son produit un grand succès. Il est donc important que ses compétences soient reconnues et respectées afin que les personnes acceptent de suivre sa vision. Le Chief Engineer doit travailler dur pour construire un business case solide afin de vendre ses idées, il ne peut pas se contenter d'imposer son point de vue aux gens.

Les Chief Engineers sont une espèce rare, et il n'y en a pas deux identiques. Ils ont certes des traits personnels spécifiques, mais ils sont également développés au fil des années pour acquérir un large éventail de compétences en travaillant dans des activités de natures très différentes au sein de l'entreprise. Ils continuent à apprendre et à diriger l'apprentissage de l'équipe produit avec un outil spécifique : l'Obeya.

Qu'est-ce que l'Obeya ?

Au début des années 90, Takeshi Uchiyamada, Chief Engineer chez Toyota, s’est vu confier une mission difficile : concevoir la voiture du XXIe siècle, avec des objectifs de consommation de carburant très ambitieux. En moins de trois ans, la première voiture hybride, la Prius, a été mise sur le marché, avec 15 ans d’avance sur la concurrence. Pour réussir un tel exploit, le Chief Engineer devait également inventer une nouvelle approche de développement de produits et de processus. Il a conçu un nouveau type de management visuel qui s’est depuis répandu dans les bureaux d’études de Toyota : l’Obeya.

Obeya signifie « grande pièce » en japonais. C’est une grande salle dont les murs sont recouverts d’informations : tableaux, dessins, plans, etc.

L’Obeya n'est pas un outil de gestion de projet de plus. L’objectif n’est ni de piloter l’avancement, ni de hiérarchiser les fonctionnalités. Le but est plutôt de réfléchir en profondeur, d’argumenter, de discuter des principaux problèmes du projet. C’est un espace de Discovery.

Les ingénieurs en chef rendent les informations et les connaissances visibles dans l’Obeya car il s'agit d'un moyen puissant pour aligner les personnes. Les malentendus sont rapidement révélés afin que les participants puissent en parler et développer une compréhension commune de la situation. Cela entraîne de longues discussions et des débats houleux, mais c’est justement par ce processus que les personnes s’alignent et apprennent ensemble. Le temps passé à aligner les gens tôt dans le projet est plus que largement récupéré lors des phases ultérieures.

Il n'y a pas de règles spécifiques pour déterminer ce que le Chief Engineer et son équipe doivent afficher sur les murs. Chaque Obeya est unique, car cela dépend de la maturité de l'équipe et de la phase du projet. Il y a cependant quelques sujets clef à explorer, quel que soit le produit. Ces sujets prennent la forme de quatre questions :

Quel est le problème que nous voulons résoudre, et pour qui ?

La création d’un produit performant est moins un problème de construction (« ajoutons cette fonctionnalité ») qu’un exercice de résolution de problème (« que devons-nous faire pour obtenir ce résultat ?»). Le problème est que nous nous précipitons généralement vers la solution avant de définir le problème à résoudre.

Les praticiens du lean utilisent la méthode scientifique, avec le cycle Plan-Do-Check-Act (PDCA), pour résoudre les problèmes de l'entreprise. Le développement de produits ne fait pas exception. Construire un produit est en soi une boucle de PDCA :

  • Plan : définir le problème client à résoudre, développer une compréhension approfondie de la situation et identifier les principales caractéristiques du produit cible.
  • Do : construire le produit.
  • Check : analyser les résultats commerciaux pour voir ce qui fonctionne et ce qui ne fonctionne pas.
  • Act : tirer des enseignements pour améliorer le prochain cycle de développement du produit.

Un bon énoncé de problème décrit un objectif ambitieux. Par exemple, le défi du Shinkansen était de permettre aux voyageurs d’aller de Tokyo à Osaka en trois heures en moins de cinq ans.

Ensuite, ce qu’il faut apprendre et explorer dans l’Obeya est la façon dont les clients perçoivent la valeur. Ce type d’apprentissage est le résultat d’une profonde immersion dans la vie des clients. Cela commence par les plaintes des clients, en essayant de comprendre ce qu’ils essayaient de faire avec les solutions actuelles et en quoi ces solutions leur ont fait défaut. Cela signifie également de passer du temps avec eux pour mieux comprendre comment ils essaient de résoudre leurs problèmes aujourd'hui.

Le Chief Engineer et l'équipe produit doivent avoir une idée de :

  • Qui sont les clients cibles, quel est leur mode de vie et leurs goûts ?
  • Quel est le problème concret qu'ils veulent résoudre ?
  • Dans quels contextes et circonstances spécifiques ?
  • Quelles alternatives peuvent-ils choisir pour obtenir ce qu'ils veulent ?
  • Pourquoi choisissent-ils une alternative plutôt qu'une autre ?
  • Qu'est-ce qu'ils aiment et détestent dans les solutions existantes ?
  • Quels problèmes spécifiques rencontrent-ils avec les solutions existantes ?
  • Quelles préférences devons-nous nous assurer de satisfaire pleinement afin de ne pas les décevoir ?
  • Quel (s) aspect (s) pouvons-nous / devrions-nous améliorer afin d’attirer l’attention des gens ?

Par exemple, le client d’un service de VTC veut se rendre d'un point A à un point B, et pour cela il peut choisir entre des services concurrents, une entreprise de taxis classique, mais aussi des services de train ou de bus. Sa décision sera basée sur un ensemble de préférences pour chaque solution :

  • Une réservation simple
  • Un temps d’attente raisonnable
  • Une course confortable
  • Une expérience agréable avec le conducteur
  • Un prix raisonnable
  • etc.

Il en va de même pour les chauffeurs, qui doivent choisir entre différentes plates-formes. La question décisive qui guidera la vision du produit est la suivante : quelle est la préférence principale des clients cibles ? Comment pouvons-nous différencier la prochaine génération du produit en fonction de ce qui compte le plus pour les clients ? La clef de la conception de produits consiste à concentrer les efforts sur ce qui compte le plus.

Quels sont les gains attendus par l'entreprise avec ce projet ?

Il y a quelques années, une société de production publicitaire a commencé à développer en interne son système de gestion de produits. L’objectif était de fournir aux photographes, aux graphistes, aux chefs de produit et aux imprimeurs une solution tout-en-un afin d’éviter les pertes de temps dues à la multitude de courriers électroniques et de fichiers Excel. Le projet était difficile, principalement parce que l’équipe produit n’avait pas accès aux représentants clés de divers départements qui étaient concentrés sur d’autres priorités. Deux ans plus tard, le produit était enfin opérationnel mais l’équipe dirigeante faisait face à un problème : elle avait investi la majeure partie des bénéfices de la société dans cet outil, mais elle était incapable de déterminer les gains qu’il avait pu apporter.

L'une des premières questions de Discovery à laquelle le Chief Engineer et son équipe doivent répondre au début du projet est la suivante : quels sont les gains attendus pour l’entreprise ? Le but ici est de préparer un business case convaincant qui aidera à :

  • en faire une priorité pour toutes les parties prenantes ;
  • définir la bonne structure de coûts du projet ;
  • vérifier la réalité du retour sur investissement une fois le produit sorti.

Dans cet exemple, l’analyse de rentabilité aurait pu consister à réduire le nombre de pertes de clients en offrant une interaction plus agréable avec leurs équipes. Cela aurait pu aussi consister à réduire de moitié le délai de création de nouvelles campagnes publicitaires, ou à augmenter la productivité de l'équipe de graphistes, mesurée en nombre de créations produites par personne et par mois. Elle aurait aussi pu contribuer à la croissance de la société en débloquant des ventes qui étaient impossibles sans ce produit.

Quelles décisions techniques devons-nous prendre pour créer un produit cohérent et rentable ?

Le Chief Engineer et son équipe développent leur compréhension du produit en explorant comment ses différentes fonctions contribuent ou non à la valeur perçue par les clients, et comment ces fonctions interagissent entre elles. Ils cherchent à savoir quels problèmes doivent être résolus avant d’entamer la construction du produit.

Dans notre exemple du VTC, prenons le système de majoration tarifaire qui s’applique lorsque le service est fortement sollicité. Cette fonction permet de réduire le temps d'attente des conducteurs en incitant un plus grand nombre d’entre eux à prendre la route lorsque la demande est forte. Cependant, cela nuit à l'expérience passager avec des prix élevés au moment où ils ont le plus besoin du service. Cela rend également les prix moins clairs pour les conducteurs, qui peuvent se sentir trompés lorsqu'ils ont l'impression que la demande devrait être forte mais ne voient aucune augmentation de leurs revenus. À l'échelle d'un tel service, cela signifie des centaines, voire des milliers d'appels supplémentaires pour les équipes de support utilisateur et chauffeur, et donc un impact important sur les coûts opérationnels.

Pour déceler et résoudre ce type de problèmes avant que la fonction ne soit développée, le Chief Engineer commence par demander à l'équipe de cartographier le lien entre les fonctions du produit et les préférences du client, et de rechercher les solutions alternatives possibles. L’objectif est de trouver un moyen de mieux satisfaire ces préférences tout en maîtrisant les coûts. L’équipe essaie également de comprendre les interactions entre les différentes fonctions du produit afin de détecter les frictions susceptibles de rendre celui-ci plus complexe et difficile à construire et maintenir.

L'équipe peut ensuite apprendre les différents moyens d’obtenir les meilleurs trade-offsen essayant différentes combinaisons et en analysant leurs performances. Tous ces apprentissages sont résumés dans l’Obeya.

À ce stade, l’un des principaux risques est de modifier les aspects des produits qui ne doivent pas être touchés - ce que nous appelons « le patrimoine technologique » - tout en conservant les aspects qui créent une complexité inutile et empêchent l’innovation - ce que nous appelons la « technologie héritée ». Pour l’équipe produit, c’est un véritable défi, car il n’est pas toujours facile de distinguer les deux.

Le patrimoine technologique est tout ce qui définit l’essence même du produit et justifie son existence. Un exemple courant est celui des claviers QWERTY et AZERTY, qui n’ont pas changé en 150 ans depuis l’invention des machines à écrire. Ces claviers étranges ont été créés à l'origine pour compenser un défaut mécanique : les touches les plus couramment utilisées s'emmêlaient. Quelques fabricants de clavier ont depuis lors essayé de proposer des vitesses de frappe plus élevées avec des agencements plus efficaces, mais ils ne sont plus là pour en parler. Les utilisateurs dans le monde entier s'y sont tellement habitués qu'ils ont fermement résisté au changement. C'est l'essence du patrimoine technologique.

Inversement, le système de ressorts qui fait rebondir les touches peut être considéré comme une technologie héritée, car les nouvelles approches permettent une saisie plus silencieuse et plus rapide. Des entreprises telles qu’Apple investissent constamment dans d'autres aspects de la technologie (forme et espacement des touches, distance de déplacement vertical, etc.) pour améliorer les solutions existantes tout en conservant la même présentation patrimoniale.

Cela étant, peut-être l’agencement des touches pourrait-il un jour être considéré à son tour comme un "héritage", surtout si la technologie de reconnaissance vocale devenait suffisamment fiable pour remplacer complètement la dactylographie. Il s'agit d'une discussion sans fin au sein d'une équipe produit, qui devrait avoir lieu régulièrement dans l’Obeya.

Construisons-nous un produit de qualité à temps pour battre la concurrence ?

Le Discovery s'applique également au processus de développement du produit lui-même. Le Chief Engineer et l'équipe produit s'accordent sur :

  • La façon dont ils définissent et suivent la qualité tout au long du projet ;
  • Les jalons qu’ils doivent respecter pour pouvoir livrer à temps ;
  • La manière de mesurer les coûts.

La qualité fait référence au produit lui-même. Les métriques de qualité indiquent si les fonctions du produit répondent pleinement aux attentes des clients en termes de fiabilité, de performance et de convivialité. Afin de choisir les bons paramètres qui les guideront tout au long du cycle de vie du produit, le Chief Engineer et l’équipe produit doivent se mettre à la place de la clientèle cible : qu’est-ce qui NE devrait PAS aller mal ? Prenez une ampoule à LED : un gage de qualité peut être qu’elle respecte la durée de vie, la luminosité et la couleur attendues, qu’elle ne surchauffe pas ou qu’elle résiste aux chocs. Ces indicateurs de qualité sont souvent le résultat de compromis techniques que l'équipe produit a dû résoudre à l'avance. Par conséquent, il est judicieux de les suivre tout au long des étapes de conception et de développement, afin que l’équipe puisse être alertée rapidement si des décisions ou des événements empêchent de délivrer un produit de qualité.

Outre la qualité, le Chief Engineer et l'équipe produit suivent généralement les délais en utilisant un macro-plan de grande taille et bien visible. Ce plan est utilisé pour aligner tout le monde sur les principaux jalons du projet et voir comment les activités et les décisions de chaque équipe se répercutent sur les autres. Le macro-plan permet aux membres de l'équipe de mieux anticiper les problèmes et de discuter des moyens de les résoudre avant qu'ils ne compromettent la livraison du produit dans les délais. Mais avant tout, le macro-plan permet au Chief Engineer et son équipe de découvrir des moyens d’intensifier la collaboration entre les différentes équipes et les parties prenantes internes et externes à l’organisation.

Enfin, l’Obeya inclut généralement des métriques permettant de surveiller les coûts (non seulement les coûts de développement du produit, mais aussi les coûts nécessaires pour assister les clients une fois le produit mis en service). Cela comprend l'infrastructure, les équipes de support et les opérations quotidiennes. Par exemple, pour une entreprise d’e-commerce, combien de temps faudra-t-il pour ajouter un nouveau produit sur son site, reconstituer un stock ou proposer une nouvelle promotion. Ici l’objectif est de découvrir l’impact des choix techniques de l’équipe sur l’ensemble du processus, et pas seulement sur le développement.

* * *

Au cours des deux dernières décennies, l’agile s'est largement répandu en réaction aux dérives des méthodologies en cascade, dans lesquelles les produits ne voyaient le jour qu'après des mois de spécification, de conception, de développement et de test. La conséquence inattendue de ce changement de paradigme est que les équipes produit ont maintenant tendance à bâcler les phases initiales du projet. En passant d'un extrême à l'autre, nous avons créé de nouvelles sources de coûts, sous la forme de nombreux retours en arrière tout au long du développement, désormais considérés comme une partie normale du processus itératif.

Le problème est qu’en réalité développer rapidement un produit puis le corriger de manière répétée jusqu’à ce qu’il corresponde aux attentes est un moyen très coûteux d'apprendre. Un bon nombre de startups ont brûlé leur capital sans jamais trouver un marché suffisant pour leur produit. L’Obeya fournit une approche révolutionnaire pour réduire les inconnues avant de commencer le développement, ce qui a pour double effet de réduire les coûts et d’accélérer le développement. Vous pouvez donc abandonner une idée avant qu’il ne soit trop tard ou bien décider de continuer pour être le premier à présenter votre produit sur le marché. En ce sens, l’Obeya est plus un outil de Discovery que de Delivery.

Article paru initialement le 4 décembre 2018 sur le site Planet Lean : Where the true strength of an obeya lies