Jean-Philippe Denis - The Qonto Tech and Product Operating system

[00:00:05] Salut tout le monde. Nous atteignons déjà presque la fin du deuxième jour de la conférence. Euh j'espère que vous avez encore de l'énergie pour accorder votre attention à plus d'informations et à tout ce qui concerne le lead. Je suis donc ici pour vous présenter le système d'exploitation produit et technologique de Conto.
[00:00:23] Alors, commençons. Et juste pour clarifier ce qu'est Conto, si vous ne nous connaissez pas, vous avez peut-être vu quelques publicités dans toute l'Europe récemment. Euh, nous avons commencé l'activité bancaire, euh, pour faciliter les opérations bancaires quotidiennes pour les PME et les freelances, grâce à un compte professionnel en ligne qui est combiné avec des outils de facturation, de tenue de livres et de gestion des dépenses. Et l'année dernière, nous avons atteint une valorisation de 4,4 milliards après seulement six ans d'activité. Nous avons donc grandi très rapidement. Et comme vous pouvez l'imaginer dans ce type d'entreprise, nous ne pouvons vraiment pas nous permettre d'échouer et lorsque nous livrons quelque chose en production, cela doit fonctionner. Nous ne pouvons pas dire à nos clients, désolé, mais pendant les cinq prochains jours, vous ne pourrez pas utiliser vos cartes. Ce n'est pas possible pour nous. Nous devons donc être capables de livrer de la qualité à chaque fois que nous faisons quelque chose. Et maintenant, nous avons 450 000 clients et 1 400 contractants. Ce que je vais partager avec vous peut ou non s'appliquer à votre vie quotidienne car nous sommes déjà assez grands, nous avons structuré notre entreprise en fonction de nos besoins. Notre plan d'ici 2026 est de devenir un vainqueur paneuropéen incontestable. Nous allons donc principalement parler de la façon de construire un produit phare et de la façon de créer le processus de conception et de réalisation de cette fonctionnalité du premier coup autant que possible. Ce sont donc nos trois piliers : construire un produit phare, un support exceptionnel et une tarification transparente. Un produit phare, c'est quand vous ouvrez votre application et que vous réalisez qu'une nouvelle fonctionnalité a été livrée et qu'elle vous fera gagner du temps pour quelque chose qui vous prenait peut-être deux heures chaque semaine à faire et qui est maintenant fait pour vous sans effort supplémentaire. Et juste en le faisant, vous réalisez que cela va simplifier votre vie, vous pourriez même le partager avec vos amis qui pourraient commencer à utiliser l'application. Donc, ce sont tous ces canaux d'acquisition marketing pour développer la base client, pour fidéliser vos clients, pour vendre des produits complémentaires à vos clients. Donc, construire un produit phare est absolument essentiel pour une entreprise technologique. Je suis Jean-Philippe, euh responsable des opérations techniques chez Conto. J'ai rejoint Conto au tout début de l'aventure en tant que premier ingénieur Android et ces deux dernières années, euh, je me suis principalement concentré sur l'optimisation de notre système et de notre façon de travailler pour qu'ils soient aussi efficaces que possible. Et mon activité secondaire est aussi de réduire la bureaucratie autant que possible chez Conto. Et c'est un travail très satisfaisant à faire et si vous avez le temps de le faire dans vos propres entreprises, faites-le. C'est génial. Alors, avant de commencer, je veux juste partager quelques résultats. Tous les deux ans, nous passons du temps.
[00:02:59] À recueillir les retours de l'équipe via une enquête d'engagement pour savoir si l'équipe est contente, se sent satisfaite de nos méthodes de travail. Donc, juste pour que vous sachiez que tout ce que je vais partager avec vous aujourd'hui fonctionne réellement. Nous avons 91% des personnes qui sont fortement d'accord sur le fait que notre façon de travailler fait grandir l'équipe et c'est l'une des principales raisons pour lesquelles nous recrutons autant de personnes si simplement chaque jour. Alors, commençons.
[00:03:23] Peut-être le savez-vous, mais nous sommes très friands du cadre Lean, nous avons donc construit un peu le nôtre. Et si vous êtes familier avec le cadre Lean, vous reconnaîtrez peut-être ce temple Lean. Nous l'avons donc un peu personnalisé pour y inclure davantage de "Contoway". Mais très brièvement, tout tourne autour de nos valeurs, en tête l'orientation client, le travail d'équipe, la maîtrise, l'intégrité et la propriété. Et vous pouvez vous identifier à certaines de ces parties parce que le toit de ce temple est la satisfaction des personnes. C'est donc d'atteindre un NPS élevé de satisfaction, peut-être de la part des clients, mais aussi de vos équipes. Et c'est quelque chose dont nous devons tous nous soucier lorsque vous avez une entreprise, car c'est ainsi que vous maintenez votre activité en vie. Vous devez prendre soin de vos clients et de vos équipes, et des actionnaires, bien sûr. Et tout cela en s'assurant que l'équipe se sente en sécurité, qu'il n'y ait pas de surpression, pas de stress, que tout le monde soit heureux de travailler là, la qualité, le délai, le coût, et aussi l'environnement, en veillant à prendre soin de l'empreinte carbone et ainsi de suite. Et cela repose sur des bases très simples qui, en fait, ont tout leur sens lorsque nous y apposons des noms. Nous avons les 5 S, la résolution quotidienne de problèmes et la maintenance productive totale. C'est, en termes plus simples, de garder l'espace de travail toujours propre, de pouvoir trouver des informations en quelques secondes et d'obtenir ces informations quand vous en avez besoin sans avoir à les chercher. La résolution quotidienne de problèmes signifie que chaque fois que vous êtes confronté à une fenêtre cassée, un retravail ou quelque chose d'autre, vous réfléchissez à un moyen pour que cela ne se reproduise plus. La maintenance productive totale, c'est ne pas attendre que le système tombe en panne pour le réparer. Et tout cela repose ensuite sur deux piliers, le juste-à-temps et l'auto-qualité, où nous voulons que les gens comprennent vraiment que nous travaillons en chaîne, nous avons euh, nous travaillons sur une pièce et nous voulons que cette pièce soit aussi bonne que possible. Nous travaillons donc en flux. Si vous construisez quelque chose et que vous le donnez à la personne suivante dans la chaîne, c'est du respect et du travail d'équipe de lui donner une pièce avec laquelle elle peut travailler sans avoir besoin de vous poser d'autres questions à ce sujet. Il s'agit donc de l'auto-qualité et si vous ne l'obtenez pas, vous mettez en péril le juste-à-temps. Et tout le monde le long de la chaîne pourrait être sous plus de pression pour réparer quelque chose qui donne satisfaction aux gens. Dès qu'un de ces piliers est brisé, ce toit qui doit toujours être stable ne l'est plus. Pour cela, nous avons des standards, une gestion visuelle et cette culture de l'amélioration continue qui nous aide chaque jour. Nous allons donc voir un peu ces choses, mais avant tout, nous avons des vies cycliques. Lorsque nous construisons une nouvelle fonctionnalité, vous pourriez dire que ce n'est pas cyclique, chaque nouvelle fonctionnalité a sa juste part d'incertitudes, nous ne savons pas comment elle va fonctionner, c'est donc toujours différent. D'une certaine manière, c'est vrai, mais d'une autre manière, cela suit une sorte de processus. Où vous avez des chefs de produit qui commenceront à définir la portée de la fonctionnalité, puis vous aurez un moment où les chefs de produit et les équipes techniques spécifieront la fonctionnalité, puis les ingénieurs commenceront à coder la fonctionnalité, puis le contrôle qualité, puis la mise en ligne, puis l'analyse du succès. Nous avons donc des vies cycliques. Et quand on réalise que c'est très cyclique, on veut commencer à le cartographier comme une chaîne de valeur. Parce que lorsque vous commencez à visualiser toutes ces étapes et sous-étapes, et ainsi de suite, juste en le cartographiant, vous pourriez réaliser que votre équipe a créé elle-même des sous-systèmes dans les systèmes et de nombreuses équipes ne travaillent peut-être pas de la même manière que d'autres équipes. Donc, si l'une de ces équipes demande à une autre de l'aider sur une étape spécifique, si elles travaillent différemment, nous avons déjà un problème. Donc, juste en cartographiant la chaîne de valeur, et c'est quelque chose que nous commençons à faire même au-delà du département technique et produit chez Conto, nous réalisons que nous avons de nombreuses étapes qui sont juste complètement inutiles et avec beaucoup de bureaucratie autour. Une fois que vous avez cartographié cette chaîne de valeur, vous voulez l'améliorer pour supprimer toute la bureaucratie. Et puis, lorsque vous avez ces étapes, vous voulez vous assurer qu'il est extrêmement clair pour tout le monde que nous avons la même définition de ce qui est fait et prêt. Un exemple simple est si vous considérez votre travail comme terminé lorsque nous avons fini une étape spécifique, mais que la personne suivante s'attend à ce qu'il soit livré différemment, alors vous aurez un retravail et vous ne pourrez pas l'éviter, et alors vous briserez le flux pièce par pièce de tout le monde et ainsi de suite. Ces définitions de "terminé" et "prêt" sont donc vraiment des choses à améliorer et à s'assurer qu'elles sont alignées entre chaque équipe. Et une fois que vous avez ce cycle très bien défini, cela peut se traduire très naturellement dans votre gestion visuelle. Lorsque vous avez ce Kanban qui peut avancer le long des différentes étapes, il devrait suivre naturellement ces différentes étapes. Et c'est assez simple au final d'avoir un management visuel qui est très direct et utile pour tout le monde. Quel est le rôle du management visuel ?
[00:08:05] Si vous dites reporting, je commence à pleurer tout de suite. Non, le management visuel est une question de travail d'équipe. Et la gestion visuelle consiste à simplifier la vie de chacun. Vous avez besoin d'une gestion visuelle simple, elle est là pour nous aider à faire notre travail de manière simple. Si vous avez l'impression que votre gestion visuelle est pénible, alors peut-être qu'elle est trop compliquée, peut-être qu'elle est excessivement bureaucratique, ou peut-être qu'elle n'apporte pas la valeur et les informations que les gens recherchent lorsqu'ils la consultent. Et je serai honnête avec vous, nous venons de refaire entièrement notre gestion visuelle au sein du département tech et produit, nous avons supprimé des centaines de propriétés qui étaient complètement inutiles et maintenant l'équipe remplit réellement toutes les informations importantes et tout est fiable. La gestion visuelle est donc vraiment une question de travail d'équipe, mais c'est aussi une question d'apprentissage. Et c'est quelque chose de très important dans la méthodologie Lean. Vous voulez être capable de visualiser chaque fois que quelque chose doit être amélioré. Et quand vous avez des délais, parce que vous voyez toutes ces étapes, vous pouvez voir combien de temps prend chaque étape. Vous pouvez voir quand l'un d'eux est en retard. Vous vous attendez à ce que ce soit fait à un moment précis, mais ce n'est pas le cas. C'est immédiatement visible sur le tableau de bord visuel, déclenchant la question : que s'est-il passé ? C'est ainsi que nous pouvons alors commencer à tirer des leçons et à améliorer le système. Et la gestion visuelle consiste également à s'assurer que tout le monde travaille sur une seule pièce à la fois, car les gens sont généralement très motivés pour aborder de nombreux sujets, mais au final, ce n'est pas la manière la plus efficace de travailler.
[00:09:35] Cela semble-t-il familier à quelqu'un ici ? Regardons-le deux, trois fois, juste pour le plaisir. D'accord ? Est-ce que cela vous évoque quelque chose ? Pouvez-vous vous identifier à cela ?
[00:09:48] D'accord, laissons-le avec la tête bien enfouie dans le sable. Alors, c'est nous chaque fois que nous avons un problème quelque part et que nous ne le résolvons pas. Nous avons des vies cycliques. C'est aussi simple que ça. Si, pendant le cycle, vous rencontrez un problème et que vous ne le réparez pas, lors du prochain cycle, nous serons confrontés au même problème. Vous-même, mais peut-être d'autres personnes. Un exemple stupide que l'on peut prendre est si vous avez un tapis mal posé sur le sol et que vous tombez à cause de cela, si vous ne le réparez pas, vous allez tomber à nouveau et peut-être quelqu'un d'autre ou vous pouvez prendre cinq minutes et le réparer. C'est la même logique chaque fois que vous avez un problème au travail sur n'importe quel sujet.
[00:10:29] Nous avons poussé ce système du concept de la "red bin" (boîte rouge). Je ne sais pas si vous êtes familier avec ça. Mais dans la chaîne de production, ils ont tendance à avoir ces bacs rouges où ils peuvent enregistrer toutes les pièces cassées ou défectueuses afin de pouvoir les analyser plus tard. Et cela fonctionne de la même manière pour une entreprise technologique. Nous pouvons simplement enregistrer tout ce qui a nécessité un retravail. Nous avons construit quelque chose, ce n'est pas bon du premier coup, nous ne pouvons pas l'utiliser directement, il faut que les gens se resynchronisent, qu'ils aient une autre réunion, qu'ils redéfinissent quelque chose pour pouvoir avancer. Donc ici, nous enregistrons tout le monde chez Conto, chaque fois que nous rencontrons un retravail, nous l'enregistrons dans une base de données. Et c'est absolument essentiel pour nous d'aller mieux, de nous améliorer chaque jour. Nous avons formé toute l'équipe à le faire et cela nous a pris pas mal de temps, pour être honnête. Parce que lorsque vous commencez à enregistrer ces fèves rouges, cela signifie que vous enregistrez quelque chose que vous avez généralement mal fait. J'ai travaillé sur quelque chose et j'ai dû le refaire, ce qui pourrait signifier dans la tête des gens que je dis à tout le monde que j'ai échoué quelque part. Ce qui n'est absolument pas le bon état d'esprit dans la logique Lean. La bonne mentalité est : j'ai échoué ici parce que le système n'est pas infaillible ici. Si le système était meilleur, je n'aurais pas échoué. Donc, pour être très efficace, nous devons avoir des personnes qui maîtrisent vraiment leur travail, mais nous devons aussi avoir un système qui aide les gens à progresser dans des conditions très sûres. Ainsi, tout retravail que nous enregistrons dans cette base de données est en fait très précieux pour que chacun puisse améliorer le système. C'est donc la première étape qui nous a vraiment aidés à adopter cette mentalité d'amélioration continue chez Conto et cela nous a pris quelques années pour y arriver.
[00:12:14] Donc, si nous enregistrons simplement tous les retravails que nous avons. Nous avons une grande base de données pleine de retravail. Qu'avons-nous ? Nous avons juste une quantité massive de douleur, mais nous la visualisons simplement. Mais maintenant nous voulons réparer ces choses. Nous connaissons ces problèmes. Nous savons exactement où ils se situent dans notre système d'exploitation car nous avons tous ces gaspillages qui correspondent à une étape spécifique du cycle de production. Nous savons donc quelle étape est cassée. Donc, plus nous avons de gaspillage autour de cette étape, plus nous savons que nous devons améliorer cette étape. C'est juste logique.
[00:12:48] Comment résoudre ce gaspillage ? Il existe donc de nombreuses méthodes que nous n'avons pas inventées, nous les réutilisons simplement car elles sont super puissantes lorsqu'elles sont utilisées correctement. Ce sont les PDCA, les Kaizen et les A3. Levez la main, êtes-vous familiers avec ces concepts ?
[00:13:03] Wow, super. Mais chaque fois que je pose la même question chez Conto à des personnes qui les utilisent réellement, j'obtiens généralement des résultats moyens. Alors, faisons-le rapidement. Donc, PDCA, vous connaissez, planifier, faire, vérifier, agir, je ne vais pas trop approfondir, mais vous avez juste une étoile polaire quand vous voulez en commencer un. C'est que vous avez un problème et votre ambition est que ce problème ne se reproduise plus jamais nulle part dans l'entreprise.
[00:13:27] Et c'est le 'n'importe où dans l'entreprise' qui compte beaucoup. Ou du moins, si vous ne pouvez pas trouver un moyen pour que ce problème ne se reproduise plus, trouvez un moyen pour que la prochaine fois que cela arrive, ce soit moins douloureux, beaucoup moins douloureux.
[00:13:40] Un exemple très rapide d'un orateur qui a fermé la présentation par erreur lors d'un événement en ligne devant beaucoup de monde. Nous avons juste abordé l'idée fausse selon laquelle nous avions donné à cette personne un clicker qui faisait juste son travail. La cause profonde était que le clicker avait trop d'options, la contre-mesure est testée localement, très simplement, nous utilisons un nouveau clicker très simple à utiliser avec seulement deux boutons, donc nous ne pouvons pas le faire échouer du tout. Pendant la vérification, où nous voulons reproduire le même problème pour nous assurer que la contre-mesure a fonctionné, nous avons essayé de cliquer sur tous les boutons pour nous assurer que personne ne pouvait fermer cette présentation par erreur. Ça a fonctionné. Et ensuite nous agissons, nous nous assurons donc de purger le stock de risques que ce problème se reproduise plus tard en achetant le même clicker très simple dans chaque bureau différent, et ensuite nous nous assurons également de protéger l'avenir pour que cela ne se reproduise plus, nous mettons à jour la norme du clicker à acheter pour l'avenir également. Ce genre de problème ne peut donc plus se produire chez Conto. Mais c'est un exemple très simple, cela peut être beaucoup plus compliqué avec une partie très technique. Mais en toute logique, c'est toujours aussi simple. Vous obtenez un énoncé de problème très clair, très factuel, vous trouvez une contre-mesure très bon marché parce que vous ne faites aucune analyse, vous arrivez à une contre-mesure très locale, vous voulez juste la tester localement et ensuite vous agissez en l'implémentant partout. Et chez Conto, l'année dernière en 2023, dans le département technique, nous avons eu 423 actions, ce qui signifie qu'il y a 423 problèmes que nous n'aurons plus jamais à affronter, espérons-le, à l'avenir. Donc, c'est vraiment pour dire que toutes les équipes de Conto sont entièrement formées pour d'abord enregistrer le gaspillage et ensuite, prendre l'habitude d'organiser des sessions de résolution de problèmes pour éliminer ce gaspillage pour toujours. Le PDCA n'est pas le seul.
[00:15:33] Maintenant, il y a le Kaizen, cette culture d'amélioration continue et nous en faisons beaucoup chez Conto. Parce que c'est la meilleure façon d'atteindre le niveau supérieur de maîtrise. Un Kaizen est une amélioration continue sur le même sujet, donc vous gardez un sujet problématique et nous réalisons amélioration après amélioration après amélioration jusqu'à ce que vous ameniez ce niveau ce sujet au niveau supérieur de maîtrise. Et généralement, vous vous fixez un objectif très ambitieux. Pour vous donner un exemple, euh récemment nous avons mené un Kaizen sur le temps, le temps de compilation sur le CI qui durait environ 10 minutes, c'était trop long car les ingénieurs attendent, c'est coûteux. Nous avons donc voulu lancer un Kaizen pour dire que cela devrait être au maximum trois minutes, puis nous examinons toutes les raisons pour lesquelles cela prend un peu de temps et nous les résolvons une par une jusqu'à ce que nous y parvenions. Donc 10 minutes, 9 minutes, 8 minutes et on s'arrête quand on a fini. Donc, voici une photo de notre tout premier Kaizen que nous avons réalisé chez Conto. Et il s'agissait de toutes les constructions qui ont échoué en staging, nous en avions pas mal, c'était très douloureux et c'était avant le COVID, donc c'était encore au bureau sur le mur, c'était très drôle. Maintenant, nous faisons ça sur Notion. Euh, et très vite, après moins d'un mois et demi, nous n'avions plus aucune occurrence de ce problème. Donc, c'est vraiment quelque chose qui n'est pas dans les équipes, tout ce qui est douloureux, c'est notre travail de le réparer. Ce n'est pas le travail des responsables, des managers ou de qui que ce soit de vous dire que c'est un sujet que nous devons résoudre. Si c'est douloureux pour vous, c'est votre responsabilité de dire, d'accord, je vais m'en occuper maintenant parce que c'est douloureux pour moi, je veux améliorer ma vie. Et d'autres en bénéficieront. C'est vraiment l'état d'esprit clé que c'est une pratique personnelle de mener ces sessions d'amélioration continue. Aujourd'hui, nous menons réellement un grand nombre de Kaizen, nous avons plus de 50 Kaizen en cours autour de Conto. C'est donc vraiment l'état d'esprit clé de chacun, pas seulement de la technologie et du produit. Et si vous pouvez voir ce graphique à droite, nous faisons de plus en plus chez Conto, donc la dernière ligne semble un peu plus basse, mais nous ne sommes qu'au début de mars, donc normalement nous en aurons plus et ça continue de croître et à gauche, ce sont tous des exemples de types de Kaizen que nous menons. Pour atteindre zéro incident causé par une situation spécifique, zéro défaut sur autre chose et pour tous, cela apporte vraiment le niveau supérieur de maîtrise pour ces sujets spécifiques.
[00:17:53] Et la dernière méthodologie que nous utilisons sont les A3. Et l'A3, c'est comme un super Kaizen où l'on veut impulser un grand changement, généralement aligner les parties prenantes et opérer un changement qui sera juste du premier coup. Donc pour vous donner un exemple, s'il vous plaît ne le lisez pas, c'est juste un exemple. Euh quand vous commencez un A3, cela signifie qu'il y a une situation dans votre système qui est cassée et généralement vous ne savez même pas à quel point elle est cassée. La première chose à faire est donc de comprendre la situation actuelle exacte et toutes les ramifications qu'elle peut avoir, car le jour où vous voulez la changer, vous ne voulez pas que quelqu'un vous dise : cette solution ne me convient pas, c'est une mission, car tout ce que vous avez imaginé ne fonctionne pas pour moi. La première étape est donc de faire cette grande analyse, vous examinez tous les gaspillages, nous les enregistrons heureusement tous dans une base de données, nous n'avons donc qu'à les collecter, de plus vous allez parler à différentes personnes clés pour recueillir tous leurs besoins afin de vous assurer de ne rien oublier. Et quand vous avez cette image complète, vous en faites une grande synthèse et cette synthèse est comme votre récit pour embarquer tous ceux qui feront partie des besoins de changement. Ils ne réalisent peut-être même pas qu'il y a un besoin de changement, mais juste en le lisant, ils sont à bord. Ils veulent le changer, ils sont convaincus que nous ne pouvons pas avancer avec ça, c'est cassé. Et ensuite, vous construisez une solution avec les parties prenantes clés. Et ensuite, vous rédigez le plan d'action, le plan de mise en œuvre, et cela vous permet d'avancer et de modifier le système de manière juste du premier coup. Les A3 sont donc généralement un outil d'alignement important, garantissant l'accord de tous pour modifier le système de manière assez radicale. Donc, contrairement au Kaizen, celui-ci est plutôt une action ponctuelle, tandis que le Kaizen est davantage une séquence d'amélioration. est comme votre narration pour intégrer tous ceux qui feront partie des besoins de changement. Ils ne réalisent peut-être même pas qu'il y a un besoin de changement, mais juste en le lisant, ils sont partants, ils veulent le changer, ils réalisent que l'on ne peut pas avancer avec ça, c'est cassé. Et ensuite, vous construisez une solution avec les parties prenantes clés, puis vous rédigez le plan d'action, le plan de mise en œuvre, et cela vous aide à avancer et à changer le système du premier coup. Donc les A3 sont généralement un outil d'alignement important. S'assurer que vous avez l'approbation de tout le monde et pour changer assez radicalement le système. Donc contrairement au Kaizen, celui-ci est plutôt une action unique, plutôt que le Kaizen qui est une suite d'améliorations. Alors maintenant, parlons un peu du flux pièce par pièce.
[00:19:46] Il est assez essentiel de pouvoir livrer en toute sécurité, de pouvoir se concentrer sur une seule chose à la fois. Et pour cela, il y a quelques points clés sur la façon de construire en flux pièce par pièce. Bien sûr, si vous construisez de la qualité, cela vous aidera à rester concentré sur une seule pièce à la fois. Travailler juste à temps est également important, et votre gestion visuelle elle-même peut vous dire directement si vous travaillez sur plus d'une pièce à la fois. Alors, comment protégeons-nous le flux pièce par pièce en produisant simplement de la qualité ? Premièrement, si vous avez de nombreux incidents qui se retrouvent dans votre assiette parce que vous livrez une mauvaise qualité en production. S'il s'agit d'un incident, bien sûr, vous devez arrêter ce que vous faites et vous devez le résoudre. Parce que ce serait une priorité, ce qui signifie que vos clients ne peuvent pas utiliser l'application comme prévu. Donc cela briserait votre flux pièce par pièce et vous n'avez pas d'autre choix que de vous concentrer sur cette partie. Toutes les retouches également en cours de route lorsque vous construisez une nouvelle fonctionnalité. Si, disons, vous êtes ingénieur et que vous recevez une spécification et que vous commencez à travailler sur cette fonctionnalité, vous la codez et vous réalisez que quelque chose n'est pas clair, alors vous devez synchroniser avec le chef de produit ou le concepteur de produit. Pour vous assurer que vous le comprenez correctement et que vous pouvez avancer en toute sécurité sans créer plus de gaspillage. Cela signifie donc que vous devrez dé-focaliser le flux pièce par pièce des concepteurs de produits ou du chef de produit.
[00:21:04] Qui a peut-être commencé un nouveau morceau en même temps. Donc la qualité est très importante. Et bien sûr, nous connaissons le coût du changement de contexte, surtout pour les ingénieurs, il est assez élevé si vous êtes concentré sur une branche spécifique, sur une fonctionnalité spécifique, et que vous devez la changer. Vous devez ranger votre code, vous devez récupérer une nouvelle branche, éventuellement fusionner des conflits et ainsi de suite, et reconstruire l'application, cela peut prendre plus d'une demi-heure. Juste pour passer à un contexte et revenir au contexte initial. Donc le flux pièce par pièce est quelque chose d'assez douloureux pour l'équipe, il est donc important de le protéger.
[00:21:38] Comment travaillons-nous également à la même vitesse ? Comment nous assurons-nous que les équipes, produits et tech, sont réellement alignées sur le travail ? Une pièce à la fois et nous synchronisons tout le monde. Alors, qu'essayons-nous de faire ? Si vous regardez cette diapositive, oups, désolé, j'ai dû ajouter des couleurs aux fonctionnalités. Nous allons ajouter visuellement des couleurs à la fonctionnalité. Euh, nous avons un code pendant que la tech construit la fonctionnalité A, disons. En attendant, les équipes produit commenceront à travailler sur la définition de la portée de la fonctionnalité B, d'accord ? Et quand les ingénieurs auront fini de coder la fonctionnalité A, nous voudrons être exactement à l'heure pour commencer à spécifier ensemble, tech et produit, la fonctionnalité B. Ce qui signifie que dès que les ingénieurs ont fini de coder la fonctionnalité A, les chefs de produit et les concepteurs de produit devraient être prêts à définir la portée de la prochaine fonctionnalité pour être prêts à travailler ensemble à la spécification de la fonctionnalité B. Et ensuite les ingénieurs commencent la fonctionnalité B et le produit commence à définir la portée des fonctionnalités et ainsi de suite. Nous devons donc nous assurer que cela peut se produire. Donc pour cela, nous travaillons avec cette méthodologie Shape Up, je ne sais pas si vous connaissez cette méthodologie. Mais cela nous aide à définir un coût fixe de combien de temps nous prévoyons de passer pour que les ingénieurs construisent la fonctionnalité. Cela signifie qu'à la fin de la définition de la portée d'une fonctionnalité, nous décidons combien de semaines nous allons passer à la construire. Ce qui signifie que nous devons concevoir cette fonctionnalité de manière à ce qu'elle corresponde à ce coût. Donc bien sûr, le volume du nombre d'écrans et ainsi de suite dépendra du temps dont nous disposons pour construire cette solution. Nous avons donc besoin, pendant cette phase de spécification, de ce que nous appelons l'ingénierie de la valeur, nous le verrons juste après. Nous devons concevoir cette solution qui s'adaptera et correspondra à cette contrainte, donc le coût fixe, bien sûr, signifie la portée variable.
[00:23:36] Et bien sûr, quand nous savons que la fonctionnalité est dans six semaines, les équipes produit savent que d'ici six semaines, elles doivent être prêtes pour la prochaine fonctionnalité.
[00:23:45] Et maintenant, comment appliquons-nous cela avec un simple supermarché ? C'est donc un endroit où vous avez le nombre d'articles qui peuvent être en stock pour un sujet spécifique. Et ici, si vous regardez cette diapositive, vous avez tous les éléments de l'équipe transversale des prix. Et vous pouvez voir que nous avons deux pipelines ici. Pipeline en haut, pipeline en bas, ce qui signifie que cette équipe peut travailler sur deux fonctionnalités en même temps. Pas plus, juste deux. Et ce que cela nous dit, il y a deux informations là-dedans. Il y a une prochaine date de disponibilité. Et cette prochaine date de disponibilité est quelque chose qui est rempli par les personnes de la tech, les ingénieurs qui vous disent, je travaille toujours sur la fonctionnalité précédente jusqu'à cette date. Ce qui signifie que jusqu'à cette date, je suis occupé. Ne me donnez pas une autre fonctionnalité à commencer à travailler, je ne suis pas libre de commencer à travailler sur cela. Et ici, cela nous donne quelques informations. Nous voyons que les ingénieurs back-end et les ingénieurs web seront libres de travailler le 11 mars sur une nouvelle fonctionnalité. Mais les ingénieurs iOS et Android travaillent toujours sur cette fonctionnalité jusqu'au 1er avril. Nous savons donc que les ingénieurs back-end et web pourraient éventuellement travailler sur une fonctionnalité uniquement web. Ou si nous voulons attendre une fonctionnalité full stack, alors nous devons attendre jusqu'au 1er avril et les ingénieurs web et back-end pourraient travailler sur la mise à l'échelle, l'amélioration continue ou autre chose. Et puis le vide que vous voyez juste au-dessus est la prochaine fonctionnalité qui est toujours en cours de définition de portée. Et cela ne sera prêt qu'au moment où nous serons prêts à commencer à y travailler, à commencer à spécifier la fonctionnalité. Cela nous force donc à travailler à la même vitesse sans risquer d'avoir plus d'un élément dans un backlog. Et nous ne voulons pas avoir un stock de fonctionnalités en cours de définition de portée, car si nous avons trop de fonctionnalités et personne pour les coder, elles sont bloquées et nous savons ce qui se passe avec le stock. Elle est dépréciée, elle est dépriorisée et cela nous fait perdre du temps et de l'énergie. C'est ainsi que nous appliquons le travail en flux pièce par pièce.
[00:25:47] Maintenant, je veux parler rapidement de notre chaîne de valeur.
[00:25:51] Donc pour nous, la façon dont nous construisons une fonctionnalité, premièrement, nous avons une phase que nous appelons l'analyse de la valeur, pendant cette phase qui appartient principalement aux équipes produit, nous allons définir ce que nous voulons réaliser avec la fonctionnalité, je vais entrer dans les détails. Puis une ingénierie de la valeur, qui est la phase où nous travaillons ensemble, de manière collaborative, les équipes produit et tech, pour concevoir entièrement jusqu'à toutes les spécifications de haute fidélité, et ensuite la livraison lorsque nous commençons à coder.
[00:26:20] Donc l'analyse de la valeur est une partie très importante. Pour s'assurer que nous faisons les choses correctement. Donc à ce stade, et ici vous avez un exemple de ce qui est la norme chez Conto, c'est la définition de « terminé » des livrables attendus. Donc ici, l'analyse de la valeur devrait se terminer par la définition d'un succès. Quel KPI, quelle métrique prévoyons-nous de faire évoluer ? Euh, parce que nous voulons construire la fonctionnalité pour une raison spécifique. Un prototype, donc une conception conceptuelle qui devrait être aussi proche que possible de ce que nous construirons réellement plus tard.
[00:26:59] Et un coût de livraison fixe. Donc bien sûr, en fonction du succès et du KPI que nous prévoyons de faire évoluer, nous serons prêts à investir plus ou moins de temps dans la construction de la fonctionnalité. Alors maintenant, la première étape lorsque nous faisons une analyse de la valeur est bien sûr de savoir quelle est la situation actuelle de notre propre application. Parce que lorsque vous voulez commencer à construire quelque chose, vous avez un point de départ, vous essayez de définir une destination et vous devrez construire ce pont entre les deux. La situation actuelle est donc le premier élément pour savoir d'où nous partons. Bien sûr, nous écoutons nos clients, tout ce que nous faisons est pour eux. C'est ce qu'ils demandent, donc nous construisons simplement ce dont ils ont besoin. Bien sûr, nous regardons ce que fait la concurrence, ils le font aussi, c'est de bonne guerre. Euh, nous devons également nous assurer que nous ne manquons pas de vérifier toutes les dépendances. Nous sommes une grande entreprise maintenant, nous sommes environ 500 personnes de la tech et du produit. Alors peut-être que nous construisons juste une nouvelle fonctionnalité pour notre propre périmètre, mais peut-être que nous aurons aussi des impacts sur d'autres fonctionnalités, sur d'autres domaines, et nous devons nous assurer que ce que nous prévoyons de faire ne casse rien nulle part, ou du moins que nous devons savoir quel type d'impact cela aura. Ensuite, nous devons nous assurer que nos experts internes peuvent nous dire que nous n'oublions rien, peut-être les ingénieurs d'exploitation, nous en avons également besoin. Euh, et puis toutes les équipes de risque et conformité, légales et de sécurité, vont aussi parfois pour des fonctionnalités spécifiques, euh s'assurer que tout est légal et que nous le faisons correctement.
[00:28:27] Alors maintenant, jouons vite fait à un jeu.
[00:28:32] Disons que je suis chef de produit maintenant, je viens de rejoindre Conto. Et on me demande de commencer à travailler sur un écran dans la section des cartes et je veux mettre à jour cet écran. Et c'est quelque chose que peut-être nous avons tous vécu plusieurs fois dans nos vies. Donc ma première partie est que je veux obtenir la situation actuelle. Et quel serait mon premier pas ? Je veux aller sur l'application et je vais vérifier cet écran pour me faire une idée de son fonctionnement. Et c'est ce que je vois. Je vois cet écran.
[00:29:01] Donc bien sûr, la première question que vous devriez vous poser est : cet écran est-il exhaustif ? Est-ce que je vois quelque chose de fiable ? Puis-je commencer les changements que je veux construire à partir de cet écran ? Ai-je une chance d'avoir raison du premier coup si je commence mes modifications avec cet écran ? Très probablement non, mais au moins vous avez l'hypothèse qu'il existe probablement de nombreux états différents qui changent l'apparence de l'écran. Mais comment obtenez-vous cette information ? La première chose que vous devez savoir est donc d'avoir une vision sur un écran exhaustif. Deuxièmement, vous voulez connaître le comportement de chaque élément et de chacun de ces éléments. Peut vous donner des informations que vous ne devez absolument pas oublier pour vous assurer que les changements que vous proposez ne cassent pas la situation existante et cela pourrait aussi vous aider à définir ce que vous voulez construire. Parce que s'il y a un statut ou un élément spécifique à considérer et que vous les oubliez. Très probablement, vous n'avez aucune chance d'y penser si vous ne les lisez pas sur l'élément suivant.
[00:30:02] Et la dernière question à laquelle vous voulez vraiment vous assurer de ne rien casser ailleurs. C'est si vous voulez changer un élément spécifique à l'intérieur de cet écran, vous voulez savoir si vous aurez un impact ailleurs dans l'application. Nous construisons des composants, ces composants sont utilisés dans toute l'application, si vous voulez mettre à jour un composant sur un écran, peut-être que vous voulez qu'il soit appliqué partout dans l'application, mais peut-être pas. Et si vous ne le savez pas, alors vous êtes un peu perdu. Donc connaître la situation actuelle n'est pas si évident et c'est principalement pour cette raison. Un écran est généralement la combinaison de nombreuses fonctionnalités et chacune de ces fonctionnalités avait plusieurs spécifications. Donc si vous regardez un élément dans un écran, c'est peut-être une fonctionnalité A qui l'a ajouté et ensuite l'écran suivant, l'élément suivant juste en dessous a été ajouté via la fonctionnalité B, une spécification différente peut-être six mois plus tard. Donc au final, pour avoir une image complète de la façon dont n'importe quel écran fonctionne réellement, c'est assez douloureux. Et la seule façon d'obtenir une réponse concrète est de demander aux ingénieurs car ils ont la base de code et la source de vérité. Sinon, vous devrez peut-être fouiller pendant des heures dans toutes les pages Confluence ou Notion et vous n'obtiendrez peut-être même pas la bonne réponse. Nous avons donc construit une solution pour cela. Parce que nous voulons avoir cette logique d'une source unique de vérité. Donc dans le lean, nous avons tendance à parler de qualité et de juste à temps et d'une source unique de vérité et ainsi de suite. Mais nous voulons aussi nous assurer de travailler le plus efficacement possible. Donc la seule source de vérité que nous voulions construire. Était là pour répondre à quelques questions. La première est : comment simplifier l'intégration de toutes les personnes qui nous rejoindront au sein du département tech et produit ? Vous devez leur donner un moyen d'avoir une vision complète de toute l'application et nous ne voulons pas attendre plusieurs cycles de développement de fonctionnalités pour qu'ils aient une image complète du fonctionnement des choses. Nous voulons donc cette source de vérité qui peut être un onboarding très rapide pour eux. Aussi, si nous pouvons avoir une seule source de vérité, nous n'aurons pas besoin que les chefs de produit et les concepteurs de produits aient à solliciter les ingénieurs. Pour leur répondre, comment fonctionne cet écran ? Et si vous faites ça, vous cassez leur flux pièce par pièce, ils changent de contexte, de commutation de contexte. Même histoire qu'avant et c'est aussi. L'ingénieur pourrait ne pas vous donner une réponse parfaite car il pourrait répondre trop vite parce qu'il est occupé par autre chose. Nous avons donc besoin de cette source de vérité. Et de même, peut-être six mois plus tard après avoir livré une fonctionnalité, pendant l'exécution de votre fonctionnalité tant qu'elle est en vie, vous avez un bug. Et si vous ne trouvez pas immédiatement l'endroit qui vous indique comment il est censé se comporter, alors il est possible que vos ingénieurs aient du mal à savoir comment il était censé fonctionner au départ. Alors peut-être que l'équipe Android demandera à l'équipe iOS : « Pouvez-vous me dire comment ça marche ? » Alors que vous devriez avoir cette source de vérité unique très accessible.
[00:32:54] Nous avons donc construit quelque chose de très simple, qui est en fait juste très simple. Nous utilisons Figma, la plupart d'entre nous utilisons Figma. Euh, et la façon dont nous construisons nos designs maintenant est de maintenir une source unique de vérité toujours fiable pour tout écran qui serait le seul endroit où chercher si vous avez une question concernant l'écran. Donc quand vous voyez une spécification de cette manière, ce n'est rien de révolutionnaire. C'est juste comme un écran avec un numéro sur un élément et à côté, vous avez une carte de spécifications où nous avons tout le contenu concernant le comportement de chacun de ces éléments.
[00:33:31] Et si vous le regardez, vous avez comment cela fonctionne actuellement en production, vous avez tous les détails sur les conditions. Quels appels d'API, quels sont-ils activés, désactivés, que se passe-t-il au clic, quel événement de suivi j'envoie et ainsi de suite. Donc si je veux savoir comment fonctionne cet écran, je n'ai qu'à aller sur cette page Figma, regarder cet écran et je sais comment il fonctionne. Mais comment le maintenir toujours à jour ?
[00:33:56] Nous avons une solution très simple, c'est chaque fois que nous construisons une nouvelle fonctionnalité qui touche cet écran. Nous allons directement ajouter la nouvelle spécification au-dessus de cet écran. Ce qui signifie que ce que vous voyez ici en bleu est ce qui est en direct en production et ce que vous voyez ici en orange, c'est ce qui est en cours de construction. Donc cela signifie, juste en le faisant, non seulement nous le maintenons toujours à jour, mais nous savons aussi que quelque chose est en cours de développement. Et comme nous sommes de nombreuses équipes avec de nombreux domaines fonctionnels et que parfois nous avons des équipes qui ont un impact sur d'autres équipes, nous savons déjà que quelqu'un est en train de changer quelque chose. Et comme le code n'a pas encore été fusionné, nous savons toujours qu'un changement est en cours et nous devons nous attendre à ce qu'il se produise bientôt. Nous devons donc considérer le changement à venir. Et quand nous avons fini de livrer la fonctionnalité, nous convertissons ces cartes oranges en cartes bleues, de retour à la source de vérité pour tout le monde. C'est ainsi que nous maintenons ce système toujours fiable. C'était donc au niveau de l'écran.
[00:34:59] Et ces écrans, si vous zoomez un peu, existent dans le cadre d'un flux, d'une séquence où vous voyez des récits utilisateur ici. Donc ça pourrait être une commande d'une carte physique, disons. Et ici, vous verrez tous les points de départ et d'arrivée, comment entrer dans ce flux. Donc ça pourrait être un deep link, ça pourrait être une partie spécifique de l'application, ça pourrait être une notification, ça pourrait être n'importe quoi. Mais au moins, vous verriez immédiatement tous les points de départ pour entrer dans ce flux. Et ensuite, vous avez cette progression horizontale du parcours utilisateur. Et ensuite, vous voyez tous ces écrans un par un horizontalement, comme l'écran par défaut et verticalement, vous avez les différentes variantes des écrans. Donc si vous avez, euh, généralement vous avez des écrans qui peuvent avoir leur état chargé, état vide, état d'erreur. Et si vous les avez tous les uns sous les autres, alors vous avez une visibilité totale sur le fonctionnement réel de votre application. Et toutes les spécifications pour les seules variantes ne contiennent les spécifications que pour ces variantes, la plupart des informations se trouvent sur l'écran par défaut. Nous ne dupliquons donc pas la carte de spécifications. Et juste en le faisant de cette manière, par conception, en nous forçant, lorsque nous codons une nouvelle fonctionnalité, à utiliser ce modèle, nous avons une vision entièrement exhaustive du fonctionnement réel de l'application chez Conto. Et quand nous intégrons quelqu'un dans une équipe spécifique, il leur suffit d'aller lire toutes ces choses assez rapidement et ils ont une vue d'ensemble qu'ils n'auraient jamais eue autrement. Sauf en lisant tous les anciens documents de notion et en essayant de recompiler lequel a écrasé quelle partie du précédent et ainsi de suite.
[00:36:37] Donc c'était pour le front-end. Mais nous n'avons pas seulement le front-end, nous avons aussi le back-end. Nous voulons donc vraiment conserver cette logique chaque fois que nous construisons quelque chose pour transformer cela en valeur. Il est trop simple de créer des documents et encore plus de documents pour livrer une fonctionnalité. Mais livrer une fonctionnalité fait partie de notre travail. Mais nous avons juste une grande application que nous maintenons depuis des années et nous continuerons à la maintenir pendant des années. Ainsi, tous les documents que nous rédigeons lorsque nous spécifions une fonctionnalité, nous voulons capitaliser dessus. Nous avons donc juste fait le même type de logique pour avoir une source de vérité unique pour tout le flux back-end également. Et pour cela, c'est très simple, nous avons juste, vous savez ces diagrammes whimsicle. Vous avez des services qui parlent à d'autres services et ainsi de suite. Nous gardons la même logique, mais nous ajoutons cette logique de les maintenir toujours à jour par conception. Donc quand nous construisons une nouvelle fonctionnalité. Nous venons d'ajouter une logique de couleur, si vous transformez une ligne grise qui est la réalité en production en rouge, cela signifie que vous prévoyez de la supprimer dans le cadre d'une fonctionnalité. Et toutes les lignes vertes que vous ajoutez sont ce que vous ajoutez dans le cadre de votre fonctionnalité. Alors, qu'est-ce que cela signifie ? Si vous êtes ingénieur de données ou n'importe qui, n'importe qui d'autre qui est intéressé à savoir comment fonctionnent les flux back-end ? Vous allez simplement à cette source de vérité de ce flux back-end. Et immédiatement, vous voyez comment cela fonctionne et vous voyez les changements en cours. Et lorsque le code est fusionné à la fin de la fonctionnalité, nous supprimons les lignes rouges et nous transformons les lignes vertes en lignes noires. Et c'est de nouveau la source de vérité. Donc de toute façon, même quand nous voulons livrer de nouvelles fonctionnalités, les ingénieurs backend écrivent toujours leur document d'architecture. Où ils écrivent ces couloirs de nage et généralement ils réécrivent et refont ces couloirs de nage à chaque fois pour chaque nouvelle fonctionnalité. De cette façon, ils mettent simplement à jour ceux qui existent, ce qui le rend beaucoup plus rapide qu'auparavant et aide aussi tout le monde à trouver des informations plus simplement.
[00:38:34] Et une autre chose ici, dans ces euh codes que vous pouvez voir ici. Vous voyez aussi que nous avons les liens vers les anciens euh vers les points d'extrémité, donc vous pouvez directement obtenir la documentation de l'API ouverte du code. C'est donc assez simple d'obtenir des informations.
[00:38:52] Dernier exemple de la façon dont nous essayons de construire des fonctionnalités avec cette mentalité de construire pour l'avenir. Euh, les deep links. C'est quelque chose que nous voulons construire pour chaque nouvelle fonctionnalité, chaque fois que nous devons ajouter un e-mail pour nous envoyer directement à une partie spécifique de l'application ou une notification pour nous envoyer quelque part de spécifique. C'est donc assez simple quand vous commencez à penser avec cette logique de construire une seule fois, pas juste à temps, mais juste une seule fois, euh, si vous centralisez simplement cette information quelque part. Pour les deep links, c'est un exemple très simple. Premièrement, vous connaissez tous les deep links qui existent. Vous n'avez donc pas à recréer quelque chose qui existe déjà car c'est très simplement disponible. Et ensuite, vous verriez directement quelle pile l'utilise et tous les paramètres, les propriétés dont vous avez besoin qui existent déjà et que vous pouvez réutiliser et vous n'avez pas à trop réfléchir à son fonctionnement car c'est la seule source unique de vérité et l'endroit concernant les deep links que nous avons.
[00:39:48] Naturellement, vous obtenez toutes les réponses dont vous avez besoin chaque fois que vous commencez à penser à un deep link. Vous n'avez donc pas besoin de trop réfléchir pour obtenir cette information. C'est là. Donc cette logique de construire une seule fois est quelque chose qui accélère vraiment la façon dont nous livrons les fonctionnalités. Sécurise, nous sécurise pour s'assurer que nous travaillons correctement du premier coup avec tous les apprentissages que nous avons eus auparavant. parce que c'est très simplement disponible. Et ensuite, vous verriez directement quelle pile l'utilise et tous les paramètres, propriétés dont vous avez besoin qui existent déjà et que vous pouvez réutiliser et vous n'avez pas à trop réfléchir à son fonctionnement. parce que comme c'est la seule source de vérité unique et le seul endroit concernant les liens profonds que nous avons, naturellement vous obtenez toutes les réponses dont vous avez besoin chaque fois que vous commencez à penser à un lien profond. Donc, vous n'avez pas besoin de trop réfléchir pour obtenir cette information. Elle est là. Donc, cette logique de construire une seule fois est quelque chose qui accélère vraiment la façon dont nous livrons les fonctionnalités. sécuriser, sécuriser, pour nous assurer que nous travaillons de la bonne manière du premier coup et avec tout l'apprentissage que nous avons eu auparavant.
[00:40:16] Donc maintenant nous avons parlé de la phase d'analyse de la valeur. D'accord ? Donc maintenant à ce stade, nous avons un prototype. Nous avons un succès qui est défini et nous avons un coût fixe. C'est donc l'entrée que nous avons, que nous devons avoir, lorsque nous démarrons cette phase d'ingénierie de la valeur. Et la phase d'ingénierie de la valeur, c'est quand nous avons tous ensemble pris des gens du produit qui devront spécifier très clairement tout ce qui concerne la conception que nous construisons pour cette fonctionnalité. À la fin de l'ingénierie de la valeur, nous avons toutes les spécifications fonctionnelles front-end qui sont parfaitement alignées, c'est ce que je vous ai montré avant, ces designs et Figma avec toutes ces cartes de spécifications remplies pour chaque élément. Il n'y a donc absolument aucun risque de retravailler à ce stade, car nous rédigeons les spécifications ensemble, en collaboration avec le produit, il n'y a donc aucun risque de euh mauvaise compréhension. que quelqu'un pourrait comprendre une carte d'une manière différente de celle du chef de produit. Ainsi, la technologie et le produit sont complètement alignés. Nous nous assurons d'avoir pensé à tous les e-mails et les notifications push liés à cette fonctionnalité. Tous les flux backend, juste celui que je vous ai montré avant, sont mappés, nous savons quel flux nous modifions, il est parfaitement clair que cela fonctionne sur le backend et nous n'avons plus aucune question. Nous définissons le contrat d'API entre le backend technique et le front-end et nous sommes clairs sur la stratégie de migration et de déploiement, les indicateurs de fonctionnalités, etc. Et bien sûr, lorsque nous sommes prêts avec tout, nous pouvons construire le calendrier de pull, c'est-à-dire comment nous organiserons le travail d'équipe au fil des semaines. Donc, à la fin de cette ingénierie de la valeur, la technologie et le produit sont entièrement alignés. La portée de la fonctionnalité correspond au volume de semaines que nous avons prévues pour la fonctionnalité et les ingénieurs sont prêts à commencer à coder de manière autonome.
[00:42:07] Et maintenant, la livraison commence.
[00:42:10] Cela commence par plusieurs actions différentes en parallèle, car nous avons cartographié notre cycle, nous avons donc visualisé toutes les étapes que nous devons produire pour nous assurer que nous construisons une fonctionnalité correcte du premier coup. Donc, la première partie que nous faisons au sein du département technique est, avant de commencer le codage, de rédiger un 'dive in', un 'dive in' à nouveau pour être dans cette logique de toujours travailler correctement du premier coup. Il s'agit de rédiger ce type de document d'architecture où nous nous mettons d'accord sur la façon dont nous prévoyons de coder cette fonctionnalité entre ingénieurs. Car, comme vous le savez, nous ne nous contentons pas de déployer du code en production, nous construisons du code, nous avons des revues d'autres ingénieurs, et ce n'est qu'après accord que nous pouvons le fusionner, etc. Nous faisons donc cette première étape d'exploration pour nous assurer d'être plus juste du premier coup sur chaque demande de fusion que nous ferons plus tard. Et nous divisons tout ce travail en très petites étapes, de sorte que nous contrôlons entièrement notre agenda. Ensuite, nous affinons ces spécifications visuelles, de sorte que les designers s'assurent clairement que chaque élément de la spécification visuelle du front-end est parfaitement aligné et que tout est parfaitement fluide, tout le texte est la copie finale. Ensuite, nous demandons la localisation dans toutes les langues, donc nous sommes en France, en Espagne, en Italie et en Allemagne, donc comme vous pouvez l'imaginer, nous avons pas mal de langues à gérer dans l'application. C'est donc à ce moment-là que cela se produit.
[00:43:28] Ensuite, nous demandons les ressources de marque, les chefs de produit et la technologie s'alignent sur le plan QA, et ce n'est qu'alors que nous pouvons commencer à coder la fonctionnalité. Et à la fin de la livraison, nous devrions avoir zéro retour QA. Cela peut paraître un peu ambitieux, mais en fait, notre objectif est d'avoir moins de deux retours QA par cycle et nous y parvenons sur plus de 80 % de nos fonctionnalités. C'est donc en fait très aligné avec notre ambition de livrer une qualité automatique pour que tout le monde soit très responsable de ce qu'il livre. Ce travail d'équipe et ces principes de respect que je vous ai montrés au début. Donc, toute cette phase d'ingénierie de la valeur donne aux ingénieurs les moyens de s'assurer que nous n'oublions rien, et que tout est sous contrôle. Et fait amusant, euh, enfin, avant cela, lorsque nous pouvons livrer la fonctionnalité, nous la mettons en ligne, et ensuite l'étape finale pour s'assurer que la fonctionnalité a atteint son objectif est de vérifier si le succès que nous avons défini en premier lieu lors de l'analyse de la valeur est réellement atteint. C'est donc la phase finale et généralement elle a lieu 30 jours après la mise en ligne de la fonctionnalité.
[00:44:44] Euh, juste une chose, nous n'avons pas d'ingénieurs QA chez Konto. Et c'est juste un résultat direct du fait que nous livrons de la qualité tout le temps. C'est vraiment notre objectif de livrer de la qualité.
[00:44:55] Encore une fois, si nous ne livrons pas de qualité, nous l'enregistrons comme un gaspillage et ensuite nous revenons à cette mentalité d'amélioration continue jusqu'à ce que nous atteignions nos objectifs. Donc il s'agit vraiment de la qualité automatique et des gens qui livrent autant de bons éléments que possible. Qu'en est-il des bugs dans tout ce système d'exploitation ? Euh, aujourd'hui, nous avons 91 bugs enregistrés chez Konto. Donc si vous le regardez en volume, 91, ça peut paraître beaucoup, mais si vous réalisez que nous sommes 500 personnes dans le département technique et produit, c'est environ un bug pour moins de trois ingénieurs. Nous maîtrisons donc entièrement notre stock de bugs et nous voulons que cela continue ainsi. Et pour cela, nous avons la propriété des bugs. Nous sommes divisés en équipes fonctionnelles. Nous sommes divisés par domaine. Donc si un ingénieur travaille sur une fonctionnalité, s'il y a un bug qui apparaît après la mise en production de la fonctionnalité, ce sera son travail de le corriger. C'est aussi une raison pour laquelle, puisque chacun est responsable de sa portée, livrer une bonne fonctionnalité inclut également de ne livrer aucun bug. Ainsi, le fait d'avoir cette responsabilité et de la déléguer à une équipe QA et ainsi de suite, et peut-être à une autre équipe chargée de corriger les bugs, oblige nos ingénieurs à avoir clairement la pleine responsabilité et le contrôle sur ce qu'ils livrent. C'est ainsi que nous évitons réellement l'apparition de bugs. Et nous voulons maintenir un faible volume de bugs et pour cela, nous refusons d'ajouter une étiquette de priorisation sur les bugs que nous avons car le jour où nous devrons réellement ajouter un niveau de priorisation, alors nous aurons un plus gros problème et alors nous devrons peut-être arrêter la production de fonctionnalités pour reprendre le contrôle de ce que nous faisons. Un bug est clairement le moyen le plus rapide de perdre de la qualité visuellement pour les clients.
[00:46:33] Donc juste une rapide conclusion de ceci. Euh, visualisez votre chaîne de valeur. C'est vraiment un élément clé. C'est très rapide à faire. Demandez à vos équipes de noter toutes les étapes qu'elles doivent suivre pour faire leur travail sur un cycle. Nous avons des vies cycliques. Choisissez un sujet spécifique. Ici, je vous montre un peu comment nous livrons des fonctionnalités, mais nous livrons aussi des mises à l'échelle, nous corrigeons aussi des bugs et ainsi de suite. Mais quand vous avez fait cette cartographie, et vous pouvez jouer à un jeu pour demander à une autre personne de la même équipe de cartographier sa propre chaîne de valeur et vous verrez qu'il y aura des différences et juste en la cartographiant, vous savez déjà comment corriger beaucoup de gaspillage. Ensuite, donnez les moyens à votre équipe d'améliorer tout. Tout ce gaspillage que nous avons partout en chemin, formez votre équipe à enregistrer ce gaspillage. Il ne s'agit pas d'eux, il s'agit du système. Et ensuite, laissez-les réparer le système. Laissez-leur de la place pour briser les normes. Laissez-leur de la place pour essayer de nouvelles choses et pour que cela devienne la nouvelle norme de demain.
[00:47:32] Et ensuite, protégez votre équipe lorsque la paix circule. C'est très important pour l'ambiance de l'équipe et ainsi de suite et ne créez pas de contenu jetable. Lorsque vous créez une fonctionnalité, lorsque vous rédigez des documents, si vous rédigez un document quelque part et que vous ne l'utilisez pas après l'étape même sur laquelle vous travaillez, vous travaillez sur quelque chose qui sera déprécié la minute où vous aurez terminé ce document. Donc probablement, si vous devez l'écrire, il peut éventuellement être utilisé d'une manière qui peut évoluer et rester une source de vérité pour plus tard. Et si vous pouvez simplement réutiliser une ancienne source de vérité pour en faire une source de vérité pour l'avenir, alors vous gagnez.
[00:48:09] Voilà. Euh, c'est un rapide aperçu de la façon dont nous travaillons chez Konto. Euh, il y a tellement plus à dire mais euh nous avons peu de temps, alors je ne sais pas si vous avez des questions.
[00:48:39] Merci pour la présentation.
[00:48:40] De rien.
[00:48:41] Euh, d'après votre présentation, on dirait que vous avez atteint la perfection, mais ce n'est pas possible. Alors, quels sont vos points faibles en fait et sur quoi travaillez-vous concernant ce que vous nous montrez ?
[00:48:55] Alors, euh, pour revenir à ce tableau des gaspillages que nous enregistrons, aujourd'hui, en moyenne, nous enregistrons environ 20 gaspillages par jour. Ce n'est donc pas ce que l'on peut appeler la perfection. Clairement, mais au moins nous avons une visualisation presque parfaite de ce qui ne va pas. C'est donc la première étape pour s'améliorer et en fait, euh, quand on voit que nous travaillons sur plus de 50 KAIZEN en même temps, cela signifie qu'il y a 50 sujets que nous pensons ne pas être là où ils devraient être. Donc clairement, nous ne sommes pas à la perfection, mais nous visualisons cela très bien et c'est un très, très grand pas en avant. Et c'est, je dirais, l'étape zéro pour commencer à s'améliorer. Donc je ne sais pas si vous avez cette pratique de consigner tous les gaspillages, mais si ce n'est pas le cas, c'est super puissant. Oui, donc non, nous ne sommes pas du tout à la perfection et c'est enregistré là où nous ne sommes pas parfaits. Merci.
[00:49:55] Euh, donc, euh, avant d'enregistrer tous les gaspillages, il faut pouvoir les voir, et si ça vient de votre équipe, ça veut dire qu'ils, qu'ils peuvent les voir.
[00:50:08] Euh, dans mon équipe, j'ai du mal avec ça. Euh, euh, je ne suis pas parfait non plus, mais euh, c'est c'est très difficile de voir le gaspillage quand on n'est pas habitué à l'exercice. Alors, avez-vous formé les gens ou comment ça a marché ?
[00:50:22] Clairement, nous formons les gens. Nous avons un bureau Lean chez Kundo. Nous avons deux personnes dont le travail est clairement de former tous les managers. J'ai personnellement formé plus de 300 % des individus chez Kundo à la façon de faire cela, donc c'est beaucoup de temps, beaucoup d'efforts. Et avant ces formations, nous ne le faisions pas, et pire encore, nous avions des gens qui essayaient de mener ces sessions de résolution de problèmes PDCA et ainsi de suite, mais c'était perçu comme un véritable point douloureux pour tout le monde, comme une punition, le P de PDCA était une punition, d'accord ? Parce que tu échoues ici, tu dois faire un PDCA. Les gens n'ont donc pas compris que, d'accord, le système était en panne ici, comment le réparer ? C'est plutôt, tu as échoué, maintenant tu es puni. Donc ça a pris du temps et même quand nous menons un mauvais PDCA, les gens pourraient avoir l'impression de perdre leur temps. Donc si vous n'avez pas la bonne méthodologie pour gérer un PDCA, ils en feront juste un, pensant que c'est une perte de temps. La formation est donc obligatoire ici, c'est vrai. Oui, c'est comme ça que nous y sommes parvenus, beaucoup de formation, oui.
[00:51:21] D'accord.
[00:51:26] D'autres questions d'abord ?
[00:51:30] J'ai une question.
[00:51:31] S'il vous plaît.
[00:51:33] Euh merci pour la présentation d'abord. Euh, comment formez-vous les gens à votre système d'exploitation ?
[00:51:41] D'accord, alors euh il y a plusieurs aspects. Comment formons-nous les gens à notre système d'exploitation ? Tout d'abord, il y a la session d'intégration pour tout nouveau venu, où nous passons un peu de temps à expliquer pourquoi nous l'avons construit de cette façon, où nous en étions quelques mois auparavant, ce qui a changé depuis et que ce sera très probablement très différent dans six mois encore. Ainsi, la façon dont nous formons les gens est de leur expliquer pourquoi nous le faisons de cette manière. Il ne s'agit pas de chaque étape, il s'agit de ce que nous essayons d'atteindre à chaque étape. Donc si quelqu'un veut le faire différemment, mais que le résultat est là, c'est bon. Alors, la façon dont nous les formons est simplement par l'intégration et ensuite sur le Gemba quand nous allons parler aux gens et voir comment ça fonctionne réellement en parlant aux gens, alors nous pouvons obtenir une formation et améliorer tout le monde.
[00:52:28] Et j'ai aussi une question.
[00:52:30] Oui.
[00:52:33] Euh, vous avez commencé à en parler. Ma question est : combien d'énergie faut-il pour maintenir de telles méthodes de travail ? Je veux dire, travaillez-vous seul avec une équipe ? Avez-vous des chefs d'équipe dans chaque équipe ?
[00:52:42] Bien responsable de l'application de la méthode Conto dans leurs équipes ? Nous avons donc cette formation de manager à la méthode Conto. Chaque manager a donc cette mentalité maintenant. C'est la façon de vraiment nous améliorer. Ce n'est donc pas seulement une question de personne, c'est chaque manager qui montre la voie. Encore une fois, c'est une pratique personnelle. Mais cela commence par les fondateurs. Comment nous avons commencé avec ça, c'était avec les fondateurs de Konto qui ont commencé à montrer la voie et ensuite tout le monde montre l'exemple pour cela. Il s'agit donc vraiment que les gens comprennent l'idée.
[00:53:12] Hmm. D'accord. Et euh, à quelle résistance faites-vous face ? Comme vous avez vos sessions d'intégration, mais les gens viennent peut-être d'autres entreprises avec d'autres habitudes de travail et parfois ils peuvent peut-être oublier d'écrire la nouvelle spécification dans une plage ou des choses comme ça. Et est-ce que vous voyez que c'est un travail quotidien ? pour s'assurer que tout est fait comme écrit dans la méthode Contour ou est-ce que c'est fluide grâce à toutes les formations et tout ça.
[00:53:39] C'est très drôle parce qu'en fait, la plupart des gens qui nous rejoignent, c'est parce que nous leur avons expliqué pendant le processus de recrutement que c'est notre façon de travailler. ils veulent juste essayer. Donc généralement, ils sont prêts à le tester par eux-mêmes. Bien sûr, au début, ils enregistrent des choses de manière incorrecte et ainsi de suite, mais c'est bien, mais au moins c'est l'état d'esprit. Donc c'est juste cool et euh ça ça bouge plutôt bien de cette façon, ouais. Bien sûr, nous avons des managers qui aident les gens à faire les choses correctement. Mais ce n'est pas une douleur de convertir les gens à travailler avec la méthodologie Lean parce que c'est en fait une évidence que cela fait avancer l'entreprise si vite. Et je crois vraiment que c'est l'une des raisons pour lesquelles nous avons grandi si vite.
[00:54:14] D'accord, merci.
[00:54:19] Pas de question. Merci beaucoup.
[00:54:23] Merci.
[00:54:24] Merci, Jean-Philippe.

Transcription (Traduit)