Steve Janaway

[00:00:01] Bonjour à tous. Bonjour. Bonjour. Euh, donc je suis là pour vous parler aujourd'hui de euh, du support de production. Euh, il y a un peu de participation du public là-dedans, donc si vous vous sentez encore un peu fatigué et que vous êtes entré en vous disant, oh, je vais m'asseoir là et je vais m'endormir.
[00:00:22] Euh, peut-être pas. Euh, je prendrai les questions à la fin. Donc si vous avez des questions pendant que nous parcourons cela, gardez-les en mémoire, il y aura amplement le temps à la fin. Donc, euh, ouais.
[00:00:34] Salut, je suis Stephen. C'est ma première fois à Flocon, alors euh, merci beaucoup aux organisateurs de m'avoir invité. J'ai passé un très bon moment hier. J'espère que vous aussi. J'espère que vous avez hâte de passer une très bonne journée à la conférence aujourd'hui également. Euh, si vous avez des questions ou quoi que ce soit que vous souhaitez discuter avec moi après cela et que vous ne parvenez pas à me joindre au reste de la conférence, voici mon Blue Sky, voici mon LinkedIn. Alors, euh, s'il vous plaît, euh, envoyez toutes vos questions ou tout ce dont vous voulez parler là-bas. Donc, je suis le VP Ingénierie chez une entreprise appelée Bloom and Wild. Nous sommes une entreprise de livraison de fleurs. Nous avons trois marques, notre marque française s'appelle Bergamote. Euh, vous avez peut-être eu Je vois quelqu'un hocher la tête. Excellent. Quelqu'un a entendu parler de nous. Génial. Euh, et oui, je suis VP Ingénierie là-bas, je le suis depuis presque huit ans, et donc ce dont je vais vous parler aujourd'hui, c'est un peu une histoire sur le support de production. Et comment nous avons géré les choses, depuis que nous étions une très, très petite startup jusqu'à une entreprise beaucoup plus grande et développée.
[00:01:39] Alors, quand vous pensez au support, le support signifie différentes choses pour différentes personnes. Donc, pour certaines personnes, cela signifie ceci.
[00:01:50] Parfois, l'éteindre et le rallumer est en fait une très bonne chose. Euh, je prenais le train pour euh, pour aller travailler, donc je travaille à Londres, je prenais le train il y a quelques semaines. Et le train est entré dans une gare, peut-être à environ 30 minutes de Londres, et il s'est arrêté. Et il est resté, normalement il reste là environ deux minutes, il est resté là dix minutes. Et puis le garde a pris le haut-parleur et a dit, il y a un problème avec le train. Et nous sommes restés là.
[00:02:18] Et puis toute l'électricité s'est coupée. Et c'est devenu très silencieux. Et puis environ une minute plus tard, toute l'électricité est revenue, beaucoup de choses ont commencé à biper. Et puis nous avons continué notre voyage vers Londres et tout s'est parfaitement bien passé. Donc, parfois, éteindre des choses et les rallumer fonctionne réellement, même sur quelque chose d'aussi grand qu'un train. Mais je ne suis pas là pour vous parler de ce genre de support aujourd'hui. Je ne suis pas non plus là pour vous parler de la façon générale dont nous nous soutenons mutuellement en tant qu'humains et en tant qu'individus.
[00:02:50] Le soutien pourrait aussi signifier quelque chose comme ceci, donc peut-être soutenir une équipe sportive. C'est en fait mon équipe locale qui remporte la promotion. Donc un endroit appelé Woking dans le sud de l'Angleterre. Dont, euh, je suis sûr que beaucoup d'entre vous n'ont jamais entendu parler. Nous, nous jouons cinq ligues en dessous de la Premiership, donc nous sommes très petits. Non, ce dont je suis ici pour vous parler aujourd'hui, c'est le support de production dans le contexte de la façon dont nous développons et dont nous livrons et dont nous supportons le logiciel. Donc, si vous pensez à la façon dont nous concevons, nous testons, nous déployons notre code. Nous l'exploitons et nous le surveillons. Et si nous le faisons bien, c'est la même équipe qui l'exploite et le surveille, que celle qui l'a conçu, écrit, testé et déployé.
[00:03:42] Et ensuite, nous le supportons.
[00:03:44] Et c'est de cette dernière partie dont je suis venu vous parler aujourd'hui. C'est donc l'histoire de la façon dont nous avons soutenu nos clients, nos utilisateurs internes et nos logiciels chez Bloom and Wild.
[00:03:58] Maintenant, ce que je ne suis pas ici pour faire, c'est vous dire comment exécuter votre logiciel en production, si c'est une bonne idée, si vous devriez euh, supporter euh, l'exécuter en production, ou quoi que ce soit de ce genre. Beaucoup d'autres personnes ont fait de bien meilleures présentations lors de conférences sur la façon de le construire et de l'exécuter. Celui-ci de Steve Smith, par exemple, vaut vraiment la peine d'être regardé. Non, ce dont je vais vous parler, c'est comment nous avons supporté notre logiciel. Et beaucoup d'équipes ont du mal lorsqu'elles supportent des logiciels à passer d'un modèle de support centralisé à un modèle distribué. Nous avons en quelque sorte eu le problème inverse, ce que je trouve aussi assez intéressant. Alors, Au fond, c'est l'histoire de comment un groupe d'ingénieurs talentueux ici aide à acheminer de belles fleurs comme celles-ci à de charmants clients ici. Plutôt simple.
[00:04:56] Et c'est un peu une histoire sur ce gars, qui est ce gars aussi. Maintenant, j'ai appelé ça faire du jardinage chez Bloom and Wild. Et donc ça va être une histoire de jardinage.
[00:05:10] Mais ce sera un peu une histoire sur la façon dont on pourrait aussi faire du jardinage. Alors, considérez cela comme un voyage de jardinage, d'accord ? Alors, quand vous commencez, peut-être que vous vous intéressez à la culture des fleurs ou à la culture des légumes. Peut-être commencez-vous avec quelque chose sur votre rebord de fenêtre, peut-être n'avez-vous qu'un petit espace, et peut-être cultivez-vous des herbes ou peut-être un plant de piment ou quelque chose comme ça.
[00:05:37] Alors, j'ai pensé que je profiterais de cette présentation non seulement pour vous apprendre à supporter votre logiciel en production, mais aussi pour vous apprendre un peu sur les fleurs. C'est donc là que la partie participation du public entre en jeu, n'est-ce pas ? Nous allons jouer à un petit jeu pendant que nous parcourons ceci : devinez la fleur. J'ai aussi essayé de traduire ces fleurs en français, j'espère que mes traductions sont correctes. Je verrai sur vos visages si je me suis trompé et je m'en excuse si c'est le cas. Alors, commençons assez facile. Quelle est cette fleur ? Quelqu'un veut être courageux et me le dire ? C'est exact. C'est peut-être la, est-ce la bonne traduction française ? Excellent. Génial.
[00:06:18] Donc, par coïncidence, si vous aimez les marguerites, vous pouvez les obtenir dans ce magnifique bouquet de fleurs de Bloom and Wild.
[00:06:26] Alors les marguerites sont de petites fleurs. Et Bloom and Wild a commencé petit. Nous avions donc un petit monolithe Ruby on Rails, une proposition convaincante dans un seul pays. Ceci est notre premier site web. Il est très, très différent de notre actuel. Mais comme toute start-up, cela signifie une petite équipe, quelques ingénieurs, une coopération très étroite, une boucle de rétroaction super rapide entre tous les acteurs de l'entreprise.
[00:06:55] Et voici à quoi nous ressemblons.
[00:06:58] Donc, c'est à peu près le moment où j'ai rejoint Bloom and Wild il y a environ huit ans. Et cette première phase, quand vous êtes dans ce genre de phase, c'est vraiment que les gens savent ce qui se passe. Les choses arrivent presque par osmose. Il y a très peu de politique, très peu de procédure. Il y a très peu de gestion quotidienne parce qu'il n'y a qu'une étoile polaire. Tout le monde, tout le monde sait où il va, tout le monde sait ce qu'il doit faire, ils font leur truc dans leur propre couloir de nage, mais se dirigent vers cette étoile polaire. Et la chose la plus importante que les ingénieurs peuvent faire à ce stade du parcours d'une startup est de livrer du code. Apprendre de ce qu'ils livrent, corriger le cap et répéter. Faire des erreurs, se remettre de ces erreurs. À ce stade, nous avions un mélange d'utilisateurs internes sur notre plateforme, l'utilisant pour le CRM, pour le marketing, pour la gestion de gamme, pour l'exécution, pour le support client. C'était votre classique, un monolithe fera tout.
[00:07:59] Et comment vous supportez votre code en production à ce stade, c'est assez facile. Quand quelque chose se casse, vous le réparez. Vous avez un très petit nombre d'ingénieurs, quand un système clé tombe en panne, tous ces ingénieurs se mobilisent sur le problème et le problème est rapidement résolu et les choses reprennent leur cours.
[00:08:19] Et dans ce modèle, le support peut être vraiment, vraiment ad hoc. Donc, vous pouvez crier par-dessus le mur de votre bureau virtuel ou réel, selon la configuration de votre startup. Il y a très peu de monde, cette boucle de rétroaction est vraiment très courte. Vous n'avez pas besoin de processus car tout le monde est super engagé dans ce qu'il fait.
[00:08:41] Et quand vous recevez des rapports de clients, il est très probable que le responsable du support client soit une seule personne. Et ils sont probablement ici. Ou vous êtes tous dans un même canal Slack. Donc, ça devient très, très facile si quelque chose ne va pas, quelqu'un vous crie dessus, vous le réparez.
[00:08:59] Et cela nous amène à notre premier apprentissage. Notre premier apprentissage est donc le suivant : lorsque vous débutez et que vous êtes petit pour supporter votre code en production, vous n'avez en fait pas besoin de grand-chose. Et le piège ici est d'essayer d'introduire trop de processus et trop de bureaucratie. Si vous introduisez trop de bureaucratie et de processus à ce stade, vous êtes perçu comme lent, vous êtes perçu comme un obstacle, vous commencez à briser ces boucles de rétroaction super courtes. Parce que la vie en startup semble parfois folle et incontrôlable. Et c'est en fait presque délibéré. C'est un peu le chaos pour bouger vite, trouver l'adéquation au marché. Et c'est à ce stade, en particulier en tant que leader de l'ingénierie, qu'il faut commencer à construire des relations car dans une startup, il arrive souvent que ceux qui sont là au début deviennent des leaders seniors dans l'organisation future. Ainsi, ce responsable du support client qui pourrait n'être qu'une seule personne pourrait finir par diriger une équipe de support client de 50, 60, 70 personnes dans quelques années. Et donc, bâtir ces relations étroites est super, super important.
[00:10:02] Bon, disons que vous avez progressé dans votre parcours de jardinage. Donc, vous avez quitté votre rebord de fenêtre, vous avez peut-être une terrasse ou un petit patio, vous y avez des pots, vous y cultivez des plantes un peu plus grandes. Allons-y pour une fleur un peu plus difficile à deviner. Alors, quelqu'un sait ce que c'est ?
[00:10:28] J'aime vos visages pensifs. C'est génial. Je vais vous sortir de votre misère. C'est un stock. Ce qui est apparemment la même chose en français. Que vous pouvez obtenir dans ce magnifique bouquet de fleurs de Bloom and Wild. Voyez-vous un thème ici ?
[00:10:42] Non, donc, dans notre parcours avec Bloom and Wild, nous avons un peu avancé. Donc, nous avons un peu augmenté. Nous avons lancé une proposition en Allemagne et une proposition en France sous la marque Bloom and Wild. Euh, nous avons lancé des applications mobiles. Nous nous sommes attaqués aux problèmes épineux de la localisation et des différentes devises dont nous n'avions pas à nous soucier lorsque nous vendions uniquement en Angleterre.
[00:11:08] L'équipe s'est agrandie. Bien que, comme vous pouvez probablement le voir ici, nous ayons adopté une convention de nommage très peu évolutive pour nos équipes.
[00:11:17] La troisième équipe ne s'appelait pas et.
[00:11:20] Euh, Mais nous faisons un grand effort pour la localisation à ce stade, un grand effort pour l'internationalisation. Nous embauchons plus d'ingénieurs, ce projet est super, super stimulant. Et la qualité de ce qui a été livré n'était initialement pas particulièrement bonne. Et ce que cela a entraîné, c'est que cela a conduit à beaucoup de comportements difficiles. Ainsi, de nombreuses autres parties de l'entreprise canalisaient en coulisses les ingénieurs dans les canaux Slack pour tenter de faire réparer les choses parce qu'elles avaient leur ingénieur préféré.
[00:11:53] Euh, nous avons essayé de résoudre ce problème en créant un seul canal Slack pour le support. Ça a été très chaotique, très rapidement. Parce que tout le monde arrivait avec des choses différentes qu'ils pensaient nécessiter un soutien et c'était et c'est devenu très, très euh, difficile à prioriser. C'était donc la phase pour réellement commencer à établir une certaine confiance entre l'équipe d'ingénierie et le reste de l'entreprise concernant le support de production.
[00:12:22] Donc, voici ce petit gars. Alors, ce petit gars est celui que nous appelons Supporty. Et Supporty est un petit, c'est un petit bot Slack, euh, écrit en TypeScript. Et nous introduisons Supporty pour tenter d'apporter un peu d'ordre au chaos. Parce que le problème d'avoir tout notre support dans un seul canal et toutes nos requêtes de support dans un seul canal, c'est qu'il n'y avait aucun mécanisme de priorisation efficace. Il était souvent très difficile pour les ingénieurs de savoir sur quoi ils devaient travailler et quand. Je ne pouvais pas voir sur quoi les ingénieurs travaillaient réellement.
[00:13:02] Donc je ne savais pas s'ils travaillaient sur les bonnes choses. C'était vraiment très difficile d'obtenir des statistiques pour apprendre. Sur ce sur quoi les gens ont travaillé. Parfois, les mauvaises choses ont été travaillées. Et parfois, seules des choses de support étaient travaillées, ce qui lorsque vous êtes une startup avec des ressources très, très limitées, n'est pas une bonne chose. Parce que c'est là que le PDG vous tape sur l'épaule et vous dit : "Hé Steve, cette fonctionnalité, celle qui devait être livrée la semaine dernière, elle n'est pas livrée." Et puis vous passez trois ou quatre heures à essayer de comprendre quel était le problème et vous découvrez que quelqu'un était en train de corriger de petites erreurs de grammaire sur le site web au lieu de travailler sur la fonctionnalité et vous n'en aviez absolument aucune idée. Alors tout devient vraiment, vraiment chaotique. Et donc, ce petit gars est là pour mettre un peu d'ordre dans le chaos.
[00:13:58] Donc, Supporty est un petit bot TypeScript, il a fallu à un ingénieur quelques après-midis pour écrire Supporty.
[00:14:04] C'est très, très simple comment Supporty fonctionne. Nous l'avons mis dans le canal de support. Les utilisateurs l'appellent, ils reçoivent un petit formulaire, ce petit formulaire leur demande des informations. Donc, nous obtenons une entrée claire et cohérente. Nous avons un ensemble de priorités afin de pouvoir comprendre sur quoi il faut travailler et quand. Et si vous prenez un problème de support, vous savez sur quoi vous devriez travailler et quand. Nous pouvons trier ces problèmes vers différentes équipes. Les ingénieurs peuvent répondre. Tout est fait en fils de discussion, et par conséquent ce canal reste propre et net. Ce qui est super, super important. Et puis nous avons d'autres fonctionnalités où nous pouvons le connecter à Jira et ainsi de suite et ainsi de suite. Et puis, très important, nous envoyons également un tas de statistiques dans notre entrepôt de données à partir de cela.
[00:14:56] Alors, Voici un exemple de ce à quoi ressemble notre petit canal. Comme vous pouvez le voir, vous avez différentes escouades, vous avez différents problèmes. Et vous avez une vue très simple de l'état actuel des problèmes ouverts.
[00:15:11] Et ce qui est vraiment important ici, c'est que c'est un canal Slack complètement ouvert. Ainsi, toute personne de l'organisation peut rejoindre ce canal Slack, je pense qu'actuellement il y a environ 250 personnes qui y sont sur une entreprise d'environ 350 personnes. Et c'est très important pour instaurer la confiance, être ouvert et transparent. Et je pense que c'est très, très important lorsque vous parlez de support de production. Il peut être un peu piégeux d'essayer de le cacher, en pensant que c'est une mauvaise chose.
[00:15:37] Il existe évidemment des solutions prêtes à l'emploi qui peuvent faire cela, euh, de manière assez efficace, elles sont assez coûteuses, vous payez par utilisateur. C'était une solution bon marché et joyeuse, qui convenait à l'étape où nous en étions à l'époque, donc au fur et à mesure que nous augmentions d'échelle.
[00:15:55] Maintenant, J'ai un peu parlé de la confiance, ce qui est aussi très, très important ici, c'est d'avoir des priorités claires. Parce que des priorités claires établissent la confiance entre vous, l'équipe d'ingénieurs, et le reste de l'entreprise. Cela semble très simple, mais avoir ce mécanisme avec des exemples clairs aide vraiment les utilisateurs à comprendre. Et cela leur permet de ne plus s'inquiéter de savoir si quelqu'un n'a pas commenté quelque chose qui doit être réparé dans les 24 heures par rapport à la chose qui doit être réparée immédiatement. Et ces exemples sont super importants. Donc nos P1 sont, le ciel nous tombe sur la tête. Le site web est en panne. Ou nous ne pouvons pas, par exemple, réserver nos livraisons auprès d'un transporteur particulier parce qu'il pourrait y avoir un, disons, un bug dans notre mécanisme de réservation. Alors qu'un P2 est quelque chose d'un peu moins important, un peu moins sensible au temps. Parfois parce que cette sensibilité au temps ne s'est pas encore manifestée. Donc, par exemple, nous arrêtons de réserver des choses auprès des transporteurs pour une livraison le lendemain vers 22 heures le soir. Euh, donc s'il est 9 heures du matin et que vous ne pouvez pas réserver des choses, ce n'est pas aussi important que s'il est 21 heures du soir et que vous ne pouvez pas réserver des choses.
[00:17:12] Et puis P3, c'est un peu tout le reste, mais pour des choses comme les erreurs grammaticales. Des bugs qu'il serait bon de corriger, mais que nous pouvons mettre dans le prochain sprint, par exemple, ils n'ont pas nécessairement besoin d'être corrigés immédiatement. C'est donc très important comme mécanisme d'alignement avec le reste de l'entreprise et cet alignement construit la confiance.
[00:17:37] Cela nous amène donc à notre deuxième apprentissage. Ainsi, à mesure que vous évoluez, vous devrez mettre un peu d'ordre dans votre chaos. Et les outils peuvent vous aider à mettre un peu d'ordre dans ce chaos. Vous pouvez fabriquer les vôtres, vous pouvez les acheter. Jira Service Management, par exemple. Euh, si vous êtes dans l'écosystème Atlassian, je crois que c'est environ 15 $ par mois par utilisateur ou quelque chose comme ça. Vous pourriez les écrire vous-même, nous n'avons certainement pas dépensé autant d'argent pour écrire un support. Assurez-vous de pouvoir obtenir des statistiques et des données de vos outils, quoi que vous fassiez. J'en parlerai dans une minute.
[00:18:14] Il y a un piège. C'est le piège si vous commencez à utiliser des outils. Donc, si vous commencez à utiliser des outils, il est très, très tentant de se cacher derrière les outils. Et commencez à vous couper du reste de l'entreprise. Donc, soyez juste conscient si vous mettez en place un processus de support, vous commencez à mettre un outil en place, je vous recommande fortement de le garder ouvert, visible et transparent.
[00:18:37] Et vous fixez des attentes claires des deux côtés. Ce sont en fait nos attentes pour, je suppose, les utilisateurs de Supporty. Et donc, Nous, par exemple, nous aimons quand les gens signalent des problèmes et nous disent ce qui ne va pas. Nous aimons quand les gens se souviennent qu'il y a des humains derrière Supporty. Donc il y a de vrais ingénieurs et de vraies personnes avec de vrais sentiments. Nous aimons quand les gens entrent dans les détails, nous aimons quand les gens répondent rapidement lorsque nous avons besoin de plus d'informations.
[00:19:08] Nous, disons, n'aimons pas autant quand les gens continuent simplement à envoyer des messages Slack à leur développeur préféré. Euh, parce que alors nous n'avons aucune idée de ce qui se passe. Nos ingénieurs sont maintenant bien meilleurs pour renvoyer les gens dans le canal de support lorsque cela se produit.
[00:19:24] Euh,
[00:19:26] nous préférerions que les gens trouvent des solutions de contournement s'il y en a une connue.
[00:19:30] Et nous ne le faisons pas, si les gens ne vont pas le faire parfaitement, et donc la chose la plus importante, en particulier avec un problème que quelqu'un, ou un problème potentiel que quelqu'un repère en production, est qu'ils vous en parlent. Il est bien préférable de dire qu'en fait ce n'est pas un problème que de laisser quelqu'un s'inquiéter qu'il y en ait un.
[00:19:51] D'accord, la prochaine étape de notre voyage de jardinage. Donc Bloom and Wild a grandi. Donc nous sommes peut-être environ 30 personnes. Nous sommes donc présents dans cinq pays, quatre langues, trois devises. Peut-être que dans votre parcours de jardinage, vous avez quelque chose d'un peu plus. Donc, un parterre surélevé au Royaume-Uni est un grand parterre de fleurs, en bois, euh, des traverses en bois de chaque côté, généralement utilisées pour cultiver des légumes, j'en ai une dans mon jardin, ils cultivent des légumes dedans.
[00:20:21] Alors, faisons un autre devinette de fleur. Quelqu'un sait-il quelle est cette fleur ?
[00:20:28] Ne vous sentez pas mal si vous ne le faites pas. Quand j'ai rejoint Bloom and Wild, je ne savais rien des fleurs.
[00:19:50] D'accord, la prochaine étape de notre voyage de jardinage. Alors, Bloom and Wild a grandi. Nous sommes donc peut-être une trentaine de personnes. Alors, Nous sommes dans cinq pays, quatre langues, trois devises. Peut-être que dans votre parcours de jardinage, vous avez quelque chose d'un peu plus. Donc, un parterre surélevé au Royaume-Uni est un grand parterre de fleurs, avec des traverses en bois de chaque côté, généralement utilisé pour cultiver des légumes. J'en ai un dans mon jardin, ils y cultivent des légumes. Alors, Essayons de deviner une autre fleur. Quelqu'un sait-il quelle fleur c'est ?
[00:20:28] Ne vous sentez pas mal si ce n'est pas le cas. Quand j'ai rejoint Blooming Wild, je ne connaissais rien aux fleurs.
[00:20:36] C'est une Alstroemeria.
[00:20:40] Ce qui est apparemment la même chose en français qu'en anglais.
[00:20:45] Il est disponible dans ce charmant bouquet de Bloom and Wild.
[00:20:50] D'accord. Alors, j'ai parlé un peu de s'assurer que vous avez des données, de s'assurer que vous extrayez ou poussez des données de votre processus de support vers un entrepôt de données dès que vous commencez à mettre en place des outils. C'est super, super important. Voici un exemple pourquoi. Donc, c'est un problème de priorité 2 que nous avons eu il y a quelques années. Et nous avons commencé à recevoir des rapports indiquant que les gens aux États-Unis ne pouvaient pas acheter de fleurs. Nous n'expédions pas de fleurs aux États-Unis, mais la beauté de notre service en ligne est que si des gens vivent aux États-Unis et qu'ils ont des personnes à qui ils veulent envoyer des fleurs au Royaume-Uni, ils peuvent utiliser notre service. Et nous avions mis en œuvre, nous avions changé certaines configurations de sécurité, euh, et nous avons commencé à recevoir des rapports indiquant que les gens ne pouvaient pas utiliser notre application depuis les États-Unis. Maintenant, Il s'est avéré que ce changement de configuration avait bloqué l'ensemble des États-Unis d'Amérique d'utiliser notre application ou notre site web. Ce qui n'était pas une bonne chose. Une grande leçon apprise là. Mais le coût de cet incident P2. Donc, en examinant le support, cet incident P2, le fil de discussion avait 143 réponses de 12 personnes différentes. Et cela a pris environ cinq heures pour être résolu au total. Alors, Cela a coûté à l'entreprise une somme considérable. Parce que ces douze personnes, leurs salaires ne sont pas bon marché. Parce qu'ils font partie de l'équipe d'ingénierie.
[00:22:31] Maintenant,
[00:22:33] Temps bien dépensé. Vous regardez cette évaluation de l'App Store où quelqu'un utilisant notre application Android nous avait donné une étoile, et ensuite ils sont revenus et l'ont changée en cinq étoiles parce que nous avons résolu leur problème.
[00:22:47] C'est génial. Mais il est vraiment important de comprendre son coût. Et c'est là que les statistiques et les données sont vos amis. Alors, à mesure que vous grandissez, on vous demandera inévitablement, si vous êtes en position de leadership en ingénierie, pourquoi votre équipe ralentit-elle ? Donc vous recevez ce petit coup sur l'épaule de la part du PDG. Je l'ai eu plusieurs fois. L'équipe ne semble pas aller aussi vite ces jours-ci, n'est-ce pas, Steve ?
[00:23:14] Et il est vraiment important de comprendre l'impact que le support a sur une équipe et sur la capacité d'une équipe à agir rapidement. Donc, être capable d'avoir les données, être capable de voir, par exemple, et de fixer des KPIs sur des choses comme la rapidité avec laquelle vous résolvez les problèmes. Celui-ci est assez intéressant, c'est combien de problèmes sont soulevés qui entraînent réellement une modification de code de notre part ? Alors, si vous regardez celui-là, vous verrez un grand nombre de problèmes, un petit nombre de changements de code. Maintenant, cela pourrait signifier non pas que c'est une partie très buggée de notre système, mais que c'est une partie incroyablement compliquée de notre système. Et donc souvent, la solution à une charge de support excessive n'est pas nécessairement de s'assurer que votre code est de meilleure qualité, c'est de s'assurer que vos applications sont en fait plus faciles à utiliser. Et c'est certainement le cas pour ce domaine de notre système. Mais nous ne serions pas en mesure d'identifier cela sans pouvoir le visualiser de cette manière.
[00:24:21] Et vous pouvez aller plus loin. Vous pouvez, par exemple, comme je l'ai fait ici, vous pouvez mapper le salaire moyen réel d'un ingénieur. Donc vous pouvez dire en gros, c'est le coût de ce que le support nous coûte réellement. Devrions-nous faire des investissements ciblés dans certains domaines ici, soit pour rendre notre système moins bogué, soit pour le rendre plus facile à utiliser ? Donc c'est vraiment important, à mon avis, les statistiques de support sont tout aussi importantes que toute autre visualisation que vous avez sur d'autres zones de votre système. Elles sont super, super importantes. Donc si vous observez et mesurez les systèmes, vous devriez observer et mesurer le support.
[00:25:05] Alors, rendez-le visible.
[00:25:08] Maintenant, en passant, si vous avez été tapé sur l'épaule par votre PDG et que votre PDG a dit, pourquoi tout va si lentement ? J'ai une présentation pour cela, euh si vous avez besoin de conseils. Bref, revenons à cette présentation. Il y a quelques autres métriques qui, je pense, dans le contexte du support sont vraiment importantes à considérer. Le premier étant le taux d'échec de changement. Alors, le taux d'échec de changement, je suis sûr que beaucoup d'entre vous le connaissent, c'est euh, c'est l'une des métriques Dora. C'est le nombre d'incidents de production divisé par le nombre de changements. Ou en d'autres termes, À quelle fréquence apportez-vous une modification en production qui interrompt la production ?
[00:25:54] Et c'est très utile. Un taux élevé d'échec de changement, par exemple, pourrait indiquer que ce que font vos équipes n'a peut-être pas une maîtrise suffisante des pratiques de test et de qualité tout au long de leur cycle de vie. Il se peut qu'ils aient un processus de déploiement inefficace et sujet aux erreurs. Il y a beaucoup, beaucoup de raisons différentes. Maintenant,
[00:26:14] Il existe de nombreuses façons de mesurer cela. Simpliste, nous mesurons les nôtres en regardant le nombre de déploiements et en regardant le nombre d'incidents majeurs et en reliant les deux ensemble. Euh,
[00:26:30] L'autre chose que je pense est vraiment importante à regarder, c'est le temps de récupération. Alors, Votre temps de récupération vous permet, un temps de récupération court vous permet de passer plus rapidement en pré-déploiement. Parce que vous pouvez récupérer d'un incident particulier ou d d'une erreur beaucoup plus rapidement. Parce que soyons honnêtes, le logiciel est compliqué.
[00:26:53] Nous pouvons avancer très lentement en testant tout, ou nous pouvons avancer plus rapidement en ne cherchant pas la perfection. Parfois, les choses tournent mal et c'est important.
[00:27:04] C'est super facile à mesurer.
[00:27:07] Et c'est important. Ainsi, investir dans une bonne surveillance, de bonnes alertes, une bonne observabilité vous permet de minimiser votre temps de récupération. S'assurer que vous avez des runbooks pour les scénarios clés minimise votre temps de récupération. Si quelque chose tourne mal, vous voulez réduire au minimum la surcharge cognitive pour trouver la racine du problème. Les runbooks sont donc très importants.
[00:27:33] Avoir des pipelines de déploiement aussi rapides que possible est vraiment important, car il ne sert à rien d'arriver rapidement à la cause première du problème et de constater ensuite qu'il faut 45 minutes pour déployer le correctif. Ainsi, investir dans des pipelines de déploiement rapides n'est pas seulement bon au quotidien, mais c'est aussi très important pour le support de vos systèmes et la récupération après une panne. Pratiquer des scénarios de défaillance clés peut aussi vraiment aider. Parce que cela signifie que vos ingénieurs développent une mémoire musculaire efficace pour quand les choses tournent mal, donc quand il y a un peu de stress et de chaos, quand il y a un incident de production majeur, ils savent quoi faire. Et enfin, organiser des post-mortems et s'assurer que vous apprenez de toutes vos expériences et que vous appliquez ces apprentissages pour améliorer les choses la prochaine fois. Donc, c'est la leçon numéro trois. Collectez vos données afin de pouvoir en tirer des leçons et assurez-vous de vous rétablir rapidement. Et découvrez également le coût des incidents. Quel est le coût pour votre entreprise en cas de défaillance ? Savez-vous même ce que cela coûte ?
[00:28:39] D'accord, prochaine étape de notre voyage de jardinage. Je pense que deviner les fleurs précédentes était un peu difficile, alors je vais vous donner une facile maintenant, d'accord ?
[00:28:48] Qu'est-ce que c'est ?
[00:28:51] C'est un tournesol. Devinez quoi ? Il est disponible dans ce magnifique bouquet de Bloom and Wild.
[00:28:59] Alors, À cette époque, tout allait bien pendant les heures de travail. Donc, chez Bloom and Wild, « en heures » signifie de 9h du matin jusqu'à 18h le soir. Nous avions donc un processus mature, des outils, des données. Et les gens suivaient le processus.
[00:29:18] Mais un peu comme Cendrillon, mais un peu plus tôt, à 18h, quand le soleil se couchait ou que l'horloge sonnait six heures, tout cela disparaissait. Et donc, après 18h, ce qui se passait s'il y avait un incident majeur, c'est qu'il remontait généralement au PDG ou au COO. Je recevais un appel téléphonique. Et puis j'essayais de trouver un ingénieur qui pourrait m'aider à résoudre le problème. Et ce n'est pas une bonne chose.
[00:29:50] Cela me faisait me sentir comme ça.
[00:29:55] Parce que quand vous ne savez pas quand votre téléphone va sonner, et que vous ne savez pas si vous pouvez résoudre le problème, c'est une situation vraiment horrible à vivre. C'est une situation particulièrement mauvaise pour la santé mentale, franchement, d'être dans ce genre de situation. Maintenant, ce que cela signifiait, c'est que c'était le moment d'utiliser toutes les données sur le coût du support et sur le coût des incidents pour l'entreprise afin de bâtir un dossier commercial pour un support rémunéré en dehors des heures de travail.
[00:30:26] Maintenant, c'est quelque chose que j'aurais aimé faire beaucoup plus tôt dans le parcours chez Bloom and Wild. Ce fut un changement absolu, non seulement pour ma santé et mon bien-être, mais aussi pour celui de mes ingénieurs.
[00:30:37] Euh,
[00:30:40] Alors, je veux dire, je l'ai juste trouvé sur Internet. Je n'ai aucune idée de ce que cet homme fait ni du contexte du tout. Euh, mais Donc, le support en dehors des heures, vous pouvez le considérer un peu comme un service d'urgence et d'accident à l'hôpital. Donc le rôle de votre support en dehors des heures est effectivement d'empêcher le patient de mourir, puis de le confier à des personnes qui peuvent l'aider à aller mieux.
[00:31:07] Donc, dans le contexte du logiciel, cela signifie que votre support en dehors des heures est là pour atténuer le problème au milieu de la nuit s'il se produit, ils ne sont pas nécessairement là pour résoudre le problème, mais pendant les heures ouvrables, ils peuvent ensuite le transmettre. Maintenant,
[00:31:23] Je pense que toutes les entreprises devraient payer pour leur support en dehors des heures de bureau. Oui, la raison pour laquelle je pense cela est parce que c'est juste, franchement. Avoir votre téléphone qui ne sait pas s'il va sonner au milieu de la nuit n'est pas juste. Penser que votre téléphone pourrait sonner au milieu de la nuit parce que vous êtes l'ingénieur qui répond le plus souvent à votre téléphone au milieu de la nuit, ce n'est pas juste. Que mon téléphone sonne au milieu de la nuit parce que je suis responsable du département d'ingénierie, je dirais que ce n'est pas juste non plus. Donc, le support payant en dehors des heures de travail est juste. Cela aide à établir des attentes très claires. Il réduit massivement le temps de récupération car vous pouvez compter sur le fait que quelqu'un répondra au téléphone et saura quoi faire, quelle que soit l'heure de la journée. C'est donc bon pour l'entreprise. C'est bon pour les ingénieurs. Dans l'ensemble des choses, quand on pense au coût d'un incident de production, ce n'est pas non plus si cher pour l'entreprise. Et il n'est pas difficile d'élaborer un bon dossier commercial pour le support en dehors des heures de travail. Et je pense que toutes les entreprises devraient payer pour leur support en dehors des heures de bureau et elles devraient le faire tôt dans leur parcours d'entreprise. J'aurais aimé le faire plus tôt.
[00:32:35] Maintenant, comme tout processus, quand vous introduisez quelque chose de nouveau, parfois ça ne se passe pas parfaitement. Alors, c'est Bernat. Bernat dort. Bernat est une vraie personne, d'ailleurs, c'est vraiment Bernat. Euh, il dort quand Ops Genie, qui est l'outil que nous utilisons pour le support en dehors des heures, euh, nous recevons une alerte Ops Genie. Maintenant, ce que fait Ops Genie, c'est qu'Ops Genie appelle Bernat. Maintenant, il continuera à appeler Bernat toutes les cinq minutes pendant 45 minutes jusqu'à ce que Bernat réponde au téléphone. S'il ne répond pas au téléphone, il m'appellera. J'ai d'excellents ingénieurs, mon téléphone n'a jamais sonné. Alors, le téléphone sonne. Il réveille Bernat vers 2h du matin. Bernat se lève. Ouvre son ordinateur portable.
[00:33:24] Se connecte, voit quel est le problème.
[00:33:29] J'ai encerclé le problème en rouge.
[00:33:34] Bernat ferme le problème, Bernat se rendort.
[00:33:38] Maintenant, je ne sais pas si vous êtes comme moi et que vous vous demandez ce que c'était, je me demande si c'était Lionel Richie.
[00:33:48] Je ne pense pas qu'il fasse partie de notre équipe de support client.
[00:33:52] D'accord, donc la quatrième leçon ici est de rendre les choses plus faciles, plus justes. En dehors des heures, faites-le tôt, je pense, payez pour votre support en dehors des heures pour votre bien et celui de vos ingénieurs, s'il vous plaît.
[00:34:05] D'accord, nous avons avancé. Vous vous êtes vraiment mis à votre genre de jeu de jardinage, de rue fleurie, vous avez tout un jardin fleuri.
[00:34:15] Quelle est cette fleur ?
[00:34:21] C'est une pivoine, c'est une pivoine Coral Charm. Disponible environ sept semaines par an dans ce magnifique bouquet de Bloom and Wild. Donc, mai est la saison des pivoines, si vous aimez les pivoines.
[00:34:33] Seulement, seulement en mai. Alors, les plus astucieux d'entre vous ont peut-être réalisé, j'ai beaucoup parlé du support de production, mais je n'ai pas parlé de l'angle du support qui est comment faire réellement la maintenance et le jardinage, comme je l'appellerais, de vos systèmes. Alors,
[00:34:53] des choses comme maintenir les frameworks, les langages à jour, corriger les petites choses agaçantes comme les requêtes lentes, les tests instables, les mises à jour. Comme je l'ai mentionné au début, nous avons commencé avec un monolithe Ruby on Rails. Nous avons encore une grande partie de ce monolithe Ruby on Rails aujourd'hui.
[00:35:09] Alors, À peu près au moment où nous commençons à nous diviser et que nous passons d'une équipe à plusieurs équipes, nous commençons à réaliser que nous avons un problème. Alors, parce que nous nous attendons un peu à ce que tout le monde se soucie de tout, cela signifie que parfois personne ne se soucie des bonnes choses. Parfois, trop peu de gens se soucient des bonnes choses.
[00:35:32] Parfois, trop de gens se soucient vraiment des mauvaises choses et sont ensuite très frustrés lorsque ces choses ne sont pas prioritaires. Nous introduisons donc un rôle que nous appelons le jardinier. Nous devons l'appeler le jardinier.
[00:35:45] Donc, les responsabilités du jardinier sont les suivantes. Ils sont donc là pour surveiller et corriger les problèmes de production en heures ouvrables, réparer les environnements de staging. Fusionner les tests, mettre à jour les dépendances pour les correctifs de sécurité par exemple. Aidez-nous à mettre à niveau des choses comme Ruby et Rails. Corrigez les tests partagés qui sont un peu fragiles, corrigez-les. Et puis, en général, aidez les équipes avec nos environnements de staging et de production. Et à ce stade, nous étions d'une taille où c'était une seule personne.
[00:36:21] Et il y avait de réels avantages à cette approche. Cela permet donc aux ingénieurs de comprendre des domaines en dehors de leur base de code principale. Cela a aidé à maintenir une propriété partagée pour les choses qui devaient être partagées en raison de la nature d'avoir un monolithe. Et pour nos responsables d'ingénierie, cela a rendu la gestion de la capacité beaucoup plus facile. Parce qu'ils pouvaient simplement retirer un ou deux ingénieurs du pool et dire qu'ils faisaient cela pendant une ou deux semaines. Plutôt que de les faire travailler sur quelque chose en même temps que leur autre travail. Cela aide donc vraiment à gérer notre monolithe et notre problème de monolithe partagé. Et aussi à partager cette responsabilité au sein de notre communauté d'ingénieurs Ruby.
[00:37:09] Alors, Cela nous amène à notre cinquième apprentissage. Donc, soutenir vos systèmes n'est pas la même chose que soutenir vos utilisateurs. Et particulièrement si vous devez supporter des monolithes et supporter des problèmes partagés et attribuer une propriété unique.
[00:37:26] D'accord, nous avons presque terminé notre parcours de jardinage. Il ne reste plus qu'une fleur à deviner. Et celle-ci est très dure.
[00:37:35] Maintenant, j'ai appelé cette section la parcelle. Une parcelle au Royaume-Uni est essentiellement un jardin potager, un jardin potager partagé. Et euh, J'ai une parcelle, euh, Il m'a fallu neuf ans pour obtenir ma parcelle. Je l'ai obtenu en passant six ans à maintenir le site web de l'Association des Parcelles. Pendant cinq de ces six années, l'Association des Parcelles ne possédait même aucune parcelle. Ce qui rendait mon travail assez facile. Euh, Quelle fleur est-ce ?
[00:38:06] Non.
[00:38:10] C'est Crespedia Globosa. Voulez-vous savoir pourquoi c'est ma fleur préférée ? C'est ma fleur préférée parce qu'elle me rappelle le microphone d'une émission de jeu des années 1970.
[00:38:27] D'accord, voici à peu près où en est Bloom and Wild aujourd'hui. Alors, 65 personnes, plusieurs équipes rationalisées, euh, avec une équipe de plateforme fonctionnant comme un modèle de service.
[00:38:44] Et nous soutenons actuellement une entreprise d'environ 350 personnes.
[00:38:54] Et cela signifie que nous avons des défis de mise à l'échelle. Donc, comme pour tout, quand vous jardinez, quand vous vous occupez de quelque chose, vous tournez le dos et votre beau jardin finit par ressembler à ça.
[00:39:08] Donc, à mesure que l'équipe grandit, nous rencontrons de nouveaux défis. Donc, à mesure que l'équipe grandit, nous construisons plus de solutions, nous construisons plus de fonctionnalités, nous construisons plus de complexité, il devient de plus en plus difficile pour une ou deux personnes de gérer toute cette complexité dans leur propre tête. il devient de plus en plus difficile pour une ou deux personnes de gérer toute cette complexité dans leur propre tête. Cela devient impossible.
[00:39:27] Nous embauchons beaucoup de nouveaux ingénieurs. Certains de nos ingénieurs plus anciens partent. Et malgré nos meilleurs efforts, les connaissances ne sont pas toujours transmises, en particulier les connaissances tacites.
[00:39:40] Et nous constatons que le jardinier ne travaille plus autant. Parce que c'est hebdomadaire, cela se concentre sur des correctifs à court terme. Cela n'ancre pas la responsabilité dans nos escouades. Et nous constatons souvent que nos responsables d'ingénierie et nos chefs de produit commencent à monnayer le temps du jardinier lorsque des tâches hautement prioritaires arrivent dans leurs équipes, car ils disposent d'une certaine capacité disponible. Et ils comprennent beaucoup plus la fonctionnalité qu'ils doivent livrer que la nécessité de mettre à jour ces dépendances cette semaine.
[00:40:12] Et donc nous faisons quelques changements. Des changements assez simples, imaginez-les un peu comme un jardin potager partagé, comme celui-ci. Alors, imaginez-les comme un lotissement.
[00:39:38] Et nous trouvons que le jardin ne fonctionne plus vraiment autant. Parce que c'est hebdomadaire, cela se concentre sur des solutions à court terme. Cela n'ancrée pas la responsabilité dans nos équipes, et nous constatons souvent que nos responsables d'ingénierie et nos chefs de produit commencent à échanger le temps du jardinier lorsque des travaux hautement prioritaires arrivent dans leurs équipes, car ils ont une certaine capacité disponible et ils comprennent beaucoup mieux la fonctionnalité qu'ils doivent livrer, que de savoir s'il est vraiment nécessaire de mettre à jour ces dépendances cette semaine.
[00:40:13] Et donc nous faisons quelques changements.
[00:40:16] Des changements assez simples. Imaginez-les un peu comme un potager partagé, comme celui-ci. Donc, imaginez-les comme un lotissement.
[00:40:24] Nous avons donc déplacé le rôle, et le rôle devient une responsabilité des équipes. Cela ancre donc la responsabilité et la propriété dans les équipes. Cela signifie que les ingénieurs peuvent se concentrer sur leur métier, améliorer leurs capacités et utiliser les experts pour s'occuper du domaine. Notre équipe plateforme leur apporte le soutien dont ils ont besoin, que ce soit l'observabilité, la surveillance, les tableaux de bord, ou la concentration sur la manière d'améliorer leur santé opérationnelle. Nous leur donnons un ensemble de KPI clairs et nous les lions à un jardinier en chef, qui est l'un de nos ingénieurs principaux, pour nous assurer qu'il y a une certaine cohérence dans ce sur quoi ils travaillent, car beaucoup d'entre eux travaillent encore dans des bases de code partagées.
[00:41:09] Et nous nous assurons de rendre cet investissement clair. Nous demandons donc à nos équipes de catégoriser le travail qu'elles effectuent, qu'il contribue à un objectif stratégique, à un travail tactique, ou qu'il soit opérationnel. C'est-à-dire le surcoût que vous avez pour exploiter votre logiciel en production, indépendamment du fait que vous changiez ou construisiez réellement quelque chose de nouveau. Ce genre de vue m'aide aussi beaucoup lorsque je discute des compromis et des décisions d'investissement avec les dirigeants. Parce que je peux dire qu'il y a une charge de base dans ces équipes, nous pourrions réduire cette charge de base si nous réalisions des investissements ciblés pour réduire cette charge de base. Et notamment, par exemple, réduire les domaines de dette technique ou de complexité.
[00:41:53] Maintenant,
[00:41:55] Nous aurions pu simplement créer une équipe de jardiniers, les regrouper tous dans une équipe, puis les faire tourner. Nous ne l'avons pas fait parce que, eh bien, c'est une équipe horrible à intégrer, étant cette équipe qui répare toutes les choses cassées. Euh, et c'est aussi très difficile à justifier parce que, comment dire, il est plus difficile de justifier la valeur directe qu'une équipe comme celle-là génère réellement pour l'entreprise. Cela n'ancre pas la propriété au bon endroit.
[00:42:25] Alors, notre dernière leçon : faites de l'autonomie et de la propriété votre objectif. Ne construisez pas une équipe de jardiniers.
[00:42:34] Alors, tout va bien, n'est-ce pas ? Oh, le monde, le monde ressemble à ça chez Blueman Wild. Bien sûr que non. C'est toujours un travail en cours, n'est-ce pas ? Ce n'est donc pas parfait. Euh, nos monolithes nous retiennent encore. Nous travaillons à une meilleure appropriation au sein de nos monolithes et à la composantisation au sein de nos monolithes pour permettre ce modèle d'appropriation. Nous travaillons sur de meilleurs processus, outils et formations afin que les équipes puissent prendre en charge la propriété. Et on peut dire que nous avons peut-être dépassé le stade de la prise en charge de notre adorable petit slackbot aussi. Oh, au cas où vous vous poseriez la question, c'est mon jardin. Je pense que je dois tondre la pelouse.
[00:43:14] D'accord, alors,
[00:43:17] Si vous voulez, si vous construisez quelque chose, vous devez le soutenir. Alors assurez-vous, lorsque vous faites cela, de définir des attentes claires, assurez-vous que lorsque vous introduisez des processus et des outils, vous le faites au bon moment.
[00:43:32] Dès que possible, collectez des données, assurez-vous de pouvoir en tirer des leçons. S'il vous plaît, s'il vous plaît, payez votre astreinte.
[00:43:42] Et votre objectif ultime ici devrait être de faire de la propriété et de l'autonomie des équipes votre objectif.
[00:43:51] Votre base de code est votre jardin. Donc, si vous le gardez propre et bien rangé, d'autres personnes le remarqueront aussi. Merci.
[00:44:06] Et nous avons maintenant du temps pour les questions. Je prendrai des questions sur les fleurs si vous le souhaitez, mais je préférerais qu'elles portent sur le support de production.
[00:44:14] Euh, merci, Steve. Euh, votre modèle de jardinier que vous avez actuellement, où chaque équipe a un jardinier, mandatez-vous la façon dont ils allouent une personne de leur équipe pour être jardinier ? Donc, certaines équipes ont-elles une personne qui est toujours le jardinier, ou bien tournent-elles toutes régulièrement ?
[00:44:32] Euh, nous ne nous n'imposons pas ce qu'ils font, mais toutes les équipes tournent généralement sur une base bihebdomadaire. Nous avons donc une cadence bihebdomadaire dans toutes nos équipes, et je pense qu'elles tournent toutes les deux semaines principalement parce que cela facilite la gestion de la capacité pour le responsable de l'ingénierie.
[00:44:49] Je pense qu'il est important qu'ils tournent, d'ailleurs, parce que ça partage, ça partage cet apprentissage, ça partage cette opportunité, et ça évite aussi à quelqu'un de devenir un point de défaillance unique ou d'être toujours forcé de faire le travail de support.
[00:45:13] Oui, merci pour la présentation. J'ai une question sur la priorité et le niveau de priorité que les gens définissent lors de la déclaration d'un ticket de support. Est-ce quelque chose que vous examinez personnellement ou faites-vous confiance au rapporteur pour la priorité, ou tout finit-il en priorité un, ou comment cela fonctionne-t-il ? Euh, oui.
[00:45:32] Oui, donc ce qui se passe, c'est que la personne qui fait la demande propose une priorité.
[00:45:41] Et ensuite, nous pouvons choisir d'ajuster cette priorité avec eux. Euh, parce que oui, vous avez parfois exactement le comportement que vous avez expliqué, à savoir que quelque chose de très, très important pour moi, je pourrais penser que c'est une priorité un, mais c'est pourquoi il est vraiment important d'avoir un ensemble d'exemples sur ce qui est une priorité un. et ce qui n'est pas une priorité un, et de rendre ceux-ci vraiment visibles, car alors, si quelqu'un essaie peut-être de le pousser ou de le faire ou fait une petite erreur et se trompe, vous pouvez simplement dire : voici comment nous hiérarchisons les choses et c'est pourquoi nous disons que c'est une P2, par exemple.
[00:46:27] Question de l'arrière.
[00:46:28] Lorsque vous avez une faible priorité pour un bug, le purgez-vous ou gardez-vous des journaux de très vieux bugs qui ne seront jamais corrigés ?
[00:46:39] Alors, quand nous, je suppose qu'avec la chose avec la demande P3, différentes choses peuvent arriver. Donc une demande P3 peut être un bug authentique, et ensuite, euh, ce bug pourrait aller, ce bug irait dans un carnet de commandes. Euh, nous essayons tous les trois ou quatre mois de purger les carnets de commandes, parce que, je pense que lorsque les bugs deviennent trop anciens, ils ont très, très peu de valeur. Euh, et il y a en fait plus de valeur à ce que quelqu'un fasse l'effort de réécrire le bug plutôt que d'essayer de simplement comprendre le bug à partir de quelque chose que quelqu'un a écrit il y a trois, quatre, cinq mois. Euh, je veux dire, le problème avec les demandes de support P3, c'est qu'elles sont souvent utilisées comme une sorte de dépotoir aléatoire pour les choses que je n'aime pas vraiment. Donc, parfois, elles ne se transforment même pas en bugs. Parfois, ce sont des suggestions de fonctionnalités et quelqu'un a simplement essayé d'utiliser un processus légèrement incorrect. Donc encore une fois, pour moi, tant que chaque demande de support est liée à une action qui se produit dans une équipe. Ainsi, la personne qui la soumet sait où elle est allée et sait avec qui elle peut faire le suivi, alors je suis satisfait. Et donc oui, si un responsable d'ingénierie ou un chef de produit peut dire à quelqu'un, d'accord, en fait, je ne pense pas que votre bug soit particulièrement important et nous l'avons donc fermé et nous n'allons pas le réparer. Tant qu'ils ont eu cette boucle de rétroaction, je suis content.
[00:48:13] Avez-vous le même engagement de tous vos ingénieurs et comment éduquez-vous sur ce sujet ?
[00:48:24] Je pense que comme pour tout, il y a des niveaux d'engagement différents. Je pense qu'il y a des ingénieurs qui aiment vraiment être en support. Parce qu'il y a un très très court cycle de rétroaction sur le support. Et donc il y a une sorte de coup de dopamine très rapide, comme : il y avait un problème, j'ai résolu le problème, super. Voici un autre problème, j'ai résolu le problème. Donc, être en support peut parfois vous faire vous sentir plutôt bien pour quelque chose. Donc, certains de nos ingénieurs aiment vraiment être en support, d'autres non.
[00:48:56] Euh, nous l'utilisons comme une nous le vendons comme une opportunité d'apprentissage et aussi une obligation, franchement, autant que toute autre chose. Donc, si vous écrivez du logiciel, vous avez l'obligation de l'exploiter, de le surveiller et de le supporter. Et cela fait partie de nos principes d'ingénierie, c'est non négociable.
[00:49:14] Mais je pense que dans de nombreux cas, parce que nous pouvons, c'est une rotation à court terme, généralement de deux semaines. Même si les gens détestent vraiment ça, ils y vont, ils y vont, c'est quelque chose qu'ils doivent juste faire et ensuite ils s'en retirent. Mais oui, je dirais que l'engagement, l'engagement varie d'une équipe à l'autre, mais c'est une chose très importante que tout le monde fait.
[00:49:38] Alors, pouvez-vous développer un peu sur le support hors heures ouvrées ? Je comprends que vous voulez minimiser les appels aux ingénieurs à minuit. Euh, alors comment trouvez-vous le bon équilibre entre l'intégration et la formation de ce prestataire de services, quel qu'il soit ? Et combien investissez-vous dans leur développement, c'est-à-dire la construction des compétences nécessaires pour ne pas avoir à escalader, ce qui, j'imagine, peut arriver à un moment donné ?
[00:50:02] Oui, donc il y a deux choses. Donc, ce groupe de support hors heures est un petit groupe, il se compose de cinq de nos ingénieurs les plus expérimentés, donc ils sont, je suppose, les plus engagés dans ce que nous faisons.
[00:50:15] Je dirige ce groupe comme un groupe très autonome, donc le groupe prend la décision, par exemple, des alertes qui les déclencheront et les réveilleront au milieu de la nuit. Je ne prends pas ces décisions, et je pense qu'il est vraiment important d'avoir ce niveau d'appropriation et ce niveau d'engagement dans le groupe.
[00:50:33] De cette façon, ce groupe est vraiment convaincu que oui, ils ne veulent pas être réveillés au milieu de la nuit s'ils n'y sont pas obligés, mais B, ils sont indemnisés au cas où cela arriverait. Donc, nous payons, peu importe si leur téléphone sonne, nous les payons un tarif fixe chaque semaine. Euh, peu importe si le téléphone sonne ou non, parce que nous les payons pour l'inconvénient, l'inconvénient potentiel, donc ils sont, nous payons une police d'assurance, en gros. Euh, nous formons ce groupe, nous obtenons que ce groupe nous dise quels runbooks nous avons besoin, et ensuite nous obtenons ces runbooks avec l'équipe pertinente qui possède ce domaine particulier. Lorsque nous développons de nouvelles fonctionnalités, la montée en compétences de l'équipe de support hors des heures de bureau est une définition de «terminé» pour une fonctionnalité majeure. Et donc, en procédant ainsi, ce groupe est aussi bien formé, aussi bien éduqué et aussi engagé à s'assurer qu'il ne soit pas réveillé très souvent. Et cela maintient ce niveau d'engagement et de bonheur élevé au sein de cette équipe. Parce que je pense que si vous ne le faites pas, alors cela devient juste une obligation. Ce que vous voulez, c'est comme un ensemble, c'est une instance d'ordre méta-niveau, je l'exploite et le surveille en production et je le supporte parce que c'est mon travail. Il se trouve simplement que nous ne voulons pas mettre tous nos ingénieurs sur le support hors heures, nous voulons avoir un niveau minimum pour intégrer cette équipe. Pour deux raisons : premièrement, parce que nous voulons des gens dans cette équipe à 2h du matin qui n'ont pas besoin d'escalader, idéalement. Mais aussi, deuxièmement, et c'est une dynamique vraiment intéressante dans une équipe comme celle-là, c'est que s'il y a des membres dans cette équipe qui, être dans cette équipe est important, mais être payé pour être dans cette équipe est important. Plus vous mettez de personnes sur cette liste, moins les gens gagnent au cours d'une année, car ils sont moins souvent affectés au support. Il y a donc une sorte d'équilibre là-bas. Nous faisons donc aussi en sorte que ce soit la décision de l'équipe quant à la taille de l'équipe. Donc, il se trouve qu'ils sont cinq en ce moment. Si je voulais ajouter un sixième, je n'irais pas vers cette équipe en disant que j'ajoute une sixième personne, j'irais vers cette équipe en disant, devrions-nous ajouter une sixième personne ? Il s'agit donc vraiment de rendre cette équipe très engagée de cette manière et d'intégrer les problèmes qu'elle essaie de résoudre.
[00:52:58] Ah, oui. Ça marche ? Oh, oui. D'accord, c'est parti. Merci pour cette conférence inspirante. J'ai une petite question car lorsque je regardais les diapositives plus tôt, je crois n'avoir vu aucun ingénieur qualité dans les équipes. Je me demandais donc comment Blue and Wild travaille pour s'assurer que le code ou les livrables vérifient la case qualité avant d'être mis en production.
[00:53:24] Ah, oui, nous avons en fait quelques ingénieurs de test dans certaines équipes, je crois que ce n'était simplement pas montré sur la diapositive. Donc, certaines de nos équipes ont des ingénieurs de test, d'autres non. Cela dépend principalement de la quantité de biens technologiques orientés client qu'ils possèdent. Ainsi, par exemple, nos équipes qui possèdent des pans de notre parcours client et qui sont orientées client, comme les équipes orientées client externe. Donc, par exemple, les équipes qui possèdent des parties de notre application web ou nos applications mobiles, elles ont des ingénieurs de test car la boucle de rétroaction serait autrement extrêmement longue pour ce client, et aussi le rayon d'impact pour un problème est extrêmement large. Euh, tandis que nos équipes qui possèdent notre logiciel de production et de traitement des commandes, c'est-à-dire le logiciel qui fonctionne dans nos centres de production et qui gère soit les arrivées de fleurs, soit la production des fleurs directement sur les lignes et leur livraison. Il n'y a que très peu de personnes, d'utilisateurs internes de ce système, et ils sont de toute façon très étroitement liés à cette équipe. Donc, cette équipe n'a pas d'ingénieurs de test, ils testent leur propre travail et ils ont aussi un niveau élevé de maturité en matière d'automatisation des tests. Mais ils ont aussi les utilisateurs internes assis très, très près d'eux de toute façon, donc ils jouent un rôle dans le processus QA plus large.
[00:55:02] Bon, merci beaucoup d'être venus. J'espère que vous avez appris quelque chose sur les fleurs autant que sur le soutien.

Transcription (Traduit)