Arnaud Porterie - Beyond developer productivity: what's next?

[00:00:06] Bonjour tout le monde. Merci d'être venus. Euh, je m'appelle Arnaud et nous allons parler un peu de ce qui va au-delà de la productivité des développeurs. Alors, un peu à propos de moi.
[00:00:20] Mon nom est euh Arnaud Porterie, comme vous pouvez l'entendre, je suis français. Je vis cependant à Amsterdam et c'est bon de rentrer à la maison parfois. Euh, je suis actuellement le fondateur d'une entreprise appelée Echoes et nous avons un stand ici, euh, si vous souhaitez venir nous rendre visite plus tard pour voir ce que nous construisons. Avant cela, j'étais directeur technique adjoint dans une entreprise appelée VP et avant cela, je dirigeais l'équipe principale chez Docker, que beaucoup d'entre vous connaissent, j'en suis sûr. Et ce qui a été une grande inspiration pour moi concernant tous les sujets qui touchent à l'expérience développeur, à l'open source et à ce que c'est que de parler de productivité des développeurs. D'accord. Alors, d'abord, une clause de non-responsabilité. Oui, je suis le fondateur d'une startup, je ne vais pas présenter mon produit du tout, ce ne sera pas un argumentaire de vente. Je vais parler de la philosophie entre ce que nous faisons, derrière ce que nous faisons et ce que nous pensons être les bonnes façons de communiquer et de définir le succès de l'ingénierie.
[00:01:16] Alors, de quoi allons-nous parler ? Tout d'abord, nous allons parler de la productivité des développeurs, c'est un sujet brûlant, je suis sûr que vous le savez tous. Nous allons parler des raisons pour lesquelles c'est un sujet brûlant et peut-être pourquoi cela ne devrait pas l'être autant.
[00:01:30] Nous allons parler du succès de l'ingénierie, euh en commençant par un parallèle avec les sports d'équipe. Et ce qui rend le succès dans notre domaine si difficile à caractériser.
[00:01:42] Et enfin, nous allons parler d'un cadre pour raisonner sur le succès de l'ingénierie. Ce que nous appelons les trois composantes du succès de l'ingénierie et comment les appliquer en pratique.
[00:01:54] Alors, la productivité des développeurs, un sujet brûlant certes, mais pour de bonnes raisons ou non.
[00:02:00] Mesurer la productivité des développeurs est un sujet à la mode. À moins que vous n'ayez vécu sous une roche ces derniers mois, je suis sûr que vous avez vu, eh bien, bien sûr, des travaux de recherche très populaires avec Dora, avec l'espace. Je suis sûr que vous avez vu des publications assez controversées, euh notamment de McKinsey. Et un flot de startups et de produits trop prometteurs concernant la mesure de la productivité des développeurs, la promotion de la productivité des développeurs, la productivité des développeurs, la productivité des développeurs. Ce qui est intéressant avec le fait que ce soit un sujet si brûlant, c'est qu'aujourd'hui, les développeurs sont plus productifs que jamais. Comme, il n'y a pas, il n'y a pas eu de moment dans le passé où nous avons été aussi productifs. Nous avons des assistants IA intégrés dans nos IDE, nous avons des frameworks, des langages et des outils assez impressionnants aujourd'hui. Pourquoi sommes-nous obsédés par la productivité des développeurs maintenant, alors qu'il semble que nous soyons plus productifs que jamais ?
[00:02:58] Eh bien, mon sentiment ici est que la productivité des développeurs est vraiment l'arbre qui cache la forêt. Les attentes envers la technologie ne font que croître.
[00:03:08] Nous sommes malheureusement à une époque où nous parlons, vous savez, de réduction des effectifs et de réduction des coûts. Nous avons des conseils d'administration et des investisseurs qui exigent plus de visibilité sur la performance des équipes. Et nous sommes quasiment constamment sollicités pour faire plus avec moins.
[00:03:25] Le problème est que simultanément, notre responsabilité en tant qu'industrie ne suit pas vraiment. Ce que je veux dire par là, c'est que nous souffrons toujours, et probablement pour de bonnes raisons, d'une perception d'opacité de notre fonction. La réalité aujourd'hui est qu'il y a beaucoup de PDG qui ne peuvent pas dire avec certitude si leur département d'ingénierie fait du bon travail. Et la vérité est que, et c'est aussi vrai pour les CTO, nous voyons beaucoup de CTO qui ne sont pas très confiants quant à la qualité de leur travail et nous ne savons pas comment caractériser cela.
[00:04:04] Donc, la raison pour laquelle je pense que la productivité des développeurs est un sujet si brûlant en ce moment est la suivante : notre incapacité à mesurer le succès de l'ingénierie est devenue intenable. Les attentes augmentent. La responsabilité ne suit pas. Les mesures de la productivité des développeurs comblent un manque. Ce n'est pas le meilleur, ce n'est pas génial, mais cela apporte une réponse à la question : faisons-nous du bon travail ? Bien.
[00:04:34] Même si ce n'est probablement pas le goulot d'étranglement pour la plupart des organisations. Et cela ne capture qu'un aspect étroit du succès de l'ingénierie.
[00:04:47] Alors, qu'est-ce que je veux dire par « ce n'est pas le goulot d'étranglement » ? Cela ne veut pas dire que la productivité des développeurs n'est pas importante, ne vous méprenez pas là-dessus. Mais dans de nombreux cas, l'amélioration de la productivité des développeurs ne sera pas corrélée et ne montrera pas d'améliorations commerciales. Je suis sûr que beaucoup d'entre vous connaissent la théorie des contraintes. Essentiellement, cela signifie que l'amélioration de la productivité des développeurs n'est qu'une illusion car ce n'est très probablement pas le goulot d'étranglement de votre organisation. Et c'est vraiment intéressant. Parce que nous constatons que beaucoup d'entreprises croient que la productivité des développeurs freine d'une certaine manière l'activité.
[00:05:20] Alors que les mêmes entreprises freinent souvent la productivité des développeurs par leur complexité et l'activité elle-même, n'est-ce pas ? Donc, ça semble un peu à l'envers.
[00:05:35] Et c'est un aspect étroit du succès de l'ingénierie. Lorsque vous mesurez le succès d'une organisation d'ingénierie en utilisant la productivité des développeurs. Ce que vous faites essentiellement, c'est simplifier la mission de l'ingénierie à la production de code. Je pense qu'en 2024, nous savons que la mission de l'ingénierie va au-delà de l'écriture de code. Cela perpétue l'idée que l'ingénierie n'est guère plus qu'une usine à fonctionnalités. Et c'est exactement la même fausseté malavisée qui a jadis conduit les gens à mesurer le succès par le nombre de lignes de code. Et, vous savez, je dis cela comme un artefact archéologique car je ne pense pas que quiconque le fasse encore, espérons-le. Sauf peut-être chez Twitter apparemment, mais c'est à peu près tout.
[00:06:23] Donc, cela dit, si la productivité des développeurs n'est pas la réponse pour mesurer le succès de l'ingénierie, qu'est-ce que le succès de l'ingénierie ? Nous allons commencer par une analogie, euh
[00:06:35] Il y a eu une conférence il y a quelques années, appelée Tech Rocks, donnée par euh Fabien Galtier. Donc, je ne connais rien au sport, alors j'espère que je ne vais pas dire quelque chose de faux. Mais Fabien Galtier était un ancien joueur de rugby et je crois qu'il est maintenant, ou du moins l'était à l'époque, l'entraîneur de l'équipe nationale française. J'ai bien compris ? Cool. Euh, il a partagé son histoire, euh, la relation de sa discipline avec la technologie lors de cette conférence et c'était absolument fascinant. Ce qu'il nous a dit, c'est que sa première relation avec la technologie dans sa discipline était en tant que joueur. Quand, avant un match, son entraîneur, je crois Bernard à l'époque, lui a dit : « Oh, au fait, pendant ce match, nous allons suivre tes performances. » Il a dit, d'accord, bien sûr.
[00:07:23] Et c'était essentiellement une version très précoce de l'analyse de données que nous avons aujourd'hui et c'était quelque chose qui observait ses mouvements sur le terrain, etc., etc. Alors il a joué son match et à la fin du match, son entraîneur lui a dit : « Hé, tu n'as pas beaucoup couru. » Il a dit, d'accord, mais il a marqué. Il était accessoirement le meilleur joueur du match, dans ce match en particulier, mais le feedback était quand même : « Tu n'as pas beaucoup couru. » D'accord.
[00:07:53] Et il faisait le parallèle avec ce qu'il fait aujourd'hui en tant qu'entraîneur avec les données, où ils utilisent maintenant des analyses beaucoup plus complexes pour pouvoir voir non pas si les joueurs courent assez, mais s'ils courent au bon moment, s'ils ont le bon impact, si la dynamique d'équipe est la bonne, etcetera, etcetera. Comme vous pouvez le voir, c'est incroyable les parallèles que nous pouvons faire avec notre domaine.
[00:08:18] Ils ont en rugby quelque chose que nous n'avons pas, c'est un critère de succès très simple, c'est-à-dire : soit nous avons gagné le match, soit nous avons perdu. Nous n'avons pas cela, bien sûr, en ingénierie. Mais quand nous mesurons la performance, nous sommes un peu à l'ère du « tu n'as pas beaucoup couru », vous savez. C'est un peu comme dire aux développeurs, eh bien, oui, vous n'avez pas écrit tant de code. Ou vous n'avez pas fermé autant de tickets et genre Bien sûr, d'accord, mais peut-être qu'il était le meilleur joueur du match.
[00:08:49] Alors, pour revenir euh au développement logiciel, pourquoi notre domaine n'est-il pas aussi facile que le rugby dans ce contexte particulier ?
[00:08:58] Eh bien, d'abord, le développement logiciel est super complexe. Euh, nous jonglons avec les priorités. Nous devons coordonner les efforts inter-équipes, euh, nous devons gérer la dégradation logicielle.
[00:09:08] Tout en livrant de la valeur à l'entreprise. Le fait que ce soit si complexe signifie que nous n'obtiendrons jamais le KPI magique qui capture le succès dans son ensemble. C'est juste, c'est juste trop complexe.
[00:09:24] L'autre difficulté de notre domaine est qu'il est extrêmement contextuel. Comme, la façon dont chaque équipe va opérer, va varier en fonction du secteur, différentes équipes vont avoir différentes exigences de conformité. Un rythme de changement différent.
[00:09:39] Euh, vous savez, tout le monde veut aller vite et casser des choses, bien sûr, d'accord, il y a des industries et des entreprises où vous ne pouvez pas aller vite et casser des choses parce que la vie des gens est en jeu.
[00:09:49] Et cela dépend aussi de la maturité et de la trajectoire de l'entreprise. Je pense que c'est quelque chose de très spécifique à notre domaine, à savoir que tout le parcours de l'entreprise, toutes les acquisitions, tous les changements de stratégie, toutes les toutes les décisions sont en quelque sorte intégrées à la plateforme. C'est très unique, je pense, à notre domaine, car nous devons gérer quelque chose qui est un morceau de l'histoire de l'entreprise dans son ensemble. Et parce que c'est si contextuel, cela signifie que les repères en tant que mesure de succès ne fonctionneront probablement pas. Parce que nous le voyons constamment, nous parlons avec des CTO qui veulent être, vous savez, rassurés qu'ils font les bonnes choses et que leur organisation va bien. Et ils aimeraient avoir des retours là-dessus et se comparer aux autres, mais le problème est que vous allez prendre des entreprises de même taille. Qui ont la même, vous savez, maturité, le même type de maturité commerciale, je dirais. Et même dans le même espace, ils vont fonctionner de manière entièrement différente et les benchmarks ne signifieront rien. Un exemple que je donne souvent à ce sujet est nous avons, nous avons des entreprises très prospères qui sont extrêmement heureuses de livrer des produits raisonnablement inachevés, en supposant qu'elles verront ce qui fonctionne et, vous savez, poliront à la fin. Et qui sommes-nous pour dire que ce n'est pas la bonne approche si cela fonctionne pour eux ? Et de l'autre côté de l'autre, pardon, l'autre extrémité du spectre, vous allez avoir des entreprises qui veulent livrer le produit parfait.
[00:11:16] Avant qu'il ne soit montré au monde et encore une fois, qui sommes-nous pour dire si c'est la bonne approche pour eux ou non ? Donc, il y a juste trop d'éléments qui se rejoignent pour dire que le benchmark sera un moyen raisonnable de comparer les entreprises et de définir le succès de l'ingénierie.
[00:11:35] Donc, la seule conclusion que nous pouvons tirer est que le succès est plutôt relatif. Il n'y aura pas de mesure universelle du succès de l'ingénierie. La seule chose que nous puissions essayer de mesurer est l'écart entre ce que nous sommes et ce que nous pourrions être, compte tenu de nos contraintes, de notre contexte, de notre histoire. En d'autres termes, notre organisation est-elle la meilleure version possible d'elle-même ?
[00:12:05] Il y a cependant des choses que toutes les organisations d'ingénierie ont en commun. Et cela pourrait nous donner un moyen de raisonner sur le succès de l'ingénierie dans son ensemble. Alors que le succès est relatif, il est intéressant de noter que l'échec est plutôt universel.
[00:12:18] Nous ne savons pas nécessairement où tracer la ligne entre le succès, ce qui définit le succès, mais nous savons cependant reconnaître les schémas d'échec. Nous savons que lorsqu'une équipe ne livre pas ou livre régulièrement les mauvaises choses, c'est un signal d'alarme.
[00:12:34] Nous savons quand le rythme de développement est lent, nous savons quand la qualité des résultats n'est pas au rendez-vous. Nous savons quand le turnover est élevé et quand les gens sont épuisés. Ce sont des erreurs universelles, même si nous ne savons pas nécessairement où tracer la limite entre ce qui est absolument bon. Bien.
[00:12:52] L'autre chose qui est assez universelle est notre énoncé de mission. Quand on y pense, la plupart des organisations d'ingénierie ont une seule mission : livrer de la valeur à leur entreprise, fréquemment et durablement. Cela nous donne probablement un cadre suffisant pour discuter du succès de l'ingénierie d'une manière qui s'applique à toutes les entreprises.
[00:13:13] En décomposant cette phrase, nous pouvons examiner ce que nous appelons les trois composantes du succès de l'ingénierie.
[00:13:20] Le premier est l'alignement. Plaçons-nous nos efforts au bon endroit ?
[00:13:25] Je vais les passer en revue en détail par la suite. La deuxième est la performance de livraison. Livrons-nous des logiciels efficacement ? Et c'est bien sûr là que des questions de productivité des développeurs peuvent se poser, bien sûr.
[00:13:39] Et le troisième est la santé. Créons-nous un contexte favorable à un succès durable ?
[00:13:50] Aucune des composantes du succès de l'ingénierie ne peut être négligée trop longtemps.
[00:13:55] Si vous n'avez aucun alignement, finalement vos efforts ne produisent pas de valeur et ce n'est pas une bonne position dans laquelle être.
[00:14:04] Sans performance de livraison, les progrès finiront par s'arrêter.
[00:14:08] Sans un environnement sain, les résultats ne dureront pas.
[00:14:12] Quelle est, vous savez, quelle est la valeur d'une équipe qui a les métriques de productivité des développeurs parfaites, si finalement elle ne travaille pas sur les bonnes choses ou si elle le fait au détriment des membres de l'équipe ? N'est-ce pas ?
[00:14:29] L'importance relative de ces trois composantes variera au fil du temps et en fonction du contexte. C'est souvent le cas que nous voyons, par exemple, les startups accorder beaucoup plus de valeur à la performance de livraison parce qu'elles veulent aller vite sur le marché. Et nous voyons, surtout avec le temps, nous avons vu avec le Covid beaucoup de mouvements là-bas. Certaines entreprises, notamment dans la Silicon Valley, très axées sur l'autonomie, lorsque le Covid a frappé et que la situation économique est devenue un peu plus tendue, nous avons constaté une forte impulsion vers l'alignement. Genre, bien sûr, vous pouvez travailler à distance, bien sûr, oui, mais nous avons, vous savez, cinq piliers d'entreprise et nous voulons que vous travailliez dessus et et et nous voulons nous assurer que cela se produise. Et c'est naturel, ça va changer, ça va changer d'une entreprise à l'autre et avec le temps. Alors parlons un peu d'alignement. Plaçons-nous nos efforts au bon endroit ? Donc, on peut dire que c'est le plus important à l'ère actuelle. Encore une fois, le travail dans le monde post-Covid est souvent distribué, ce qui signifie que vous voulez vous assurer qu'il y a un alignement entre les personnes, même si la communication n'est pas nécessairement aussi bonne qu'avant.
[00:15:39] Nous n'avons plus la même capacité d'embauche dans le contexte économique actuel. Et cela signifie encore une fois que nous sommes censés faire plus avec moins, et cela signifie que nous n'avons pas autant de liberté qu'avant pour faire des choses qui ne sont pas nécessairement prioritaires.
[00:15:54] Et pour l'instant, le modèle d'ingénierie produit est la norme de facto. Ce que je veux dire par là, c'est que nous voyons de plus en plus d'organisations où il y a fondamentalement une ligne de produits qui collabore avec une ligne d'ingénierie. Cette collaboration est absolument essentielle, bien sûr, au succès de l'organisation dans son ensemble et cela signifie que vous voulez vous assurer qu'il y a un fort alignement. Ce que j'entends par un alignement fort, c'est s'assurer que les développeurs comprennent ce qu'ils poursuivent en termes d'objectifs commerciaux et s'assurer que les chefs de produit comprennent qu'ils devraient également être incités sur la qualité de la plateforme.
[00:16:30] Cela exige une certaine clarté et une stabilité raisonnable des objectifs, bien sûr, ce n'est jamais parfait.
[00:16:37] Et encore une fois, des incitations partagées. C'est plus facile à dire qu'à faire. Euh, nous l'avons vu dans ma précédente entreprise où nous avions des équipes incitées ensemble à la fois sur l'atteinte des objectifs commerciaux et la qualité technique de la plateforme. C'est parfois une pilule difficile à avaler pour un chef de produit d'être incité sur le SLA de la plateforme. Ou pour un ingénieur d'être incité à atteindre des objectifs commerciaux. Mais je pense que c'est ça, l'alignement, c'est s'assurer que les gens sont dans le même bateau et qu'ils partagent les problèmes ensemble parce que sinon, ce sera une lutte constante pour décider ce qui est le plus important pour l'un ou l'autre selon la personne à qui vous parlez.
[00:17:27] Comment mesurez-vous l'alignement ? C'est donc un sujet très compliqué.
[00:17:32] Ce que je pense, c'est que vous pouvez en connectant le travail quotidien à son objectif et en mesurant l'allocation des efforts à travers les objectifs et les initiatives. C'est beaucoup plus facile à dire qu'à faire. Et malheureusement, aucune des méthodes traditionnelles pour résoudre ce problème n'est vraiment satisfaisante.
[00:17:47] Typiquement, ce que nous avons vu est une feuille de temps manuelle. C'est probablement le pire, bien sûr. Euh, des feuilles de temps manuelles pour dire, eh bien, cette semaine, j'ai, vous savez, passé 40% de mon temps là-dessus et 20% de mon temps là-dessus.
[00:17:58] Tout le monde déteste ça. Euh, c'est manuel, donc c'est imprécis. Mais, vous savez, cela donne des données sur la manière exacte dont nous sommes alignés en tant qu'organisation. La deuxième méthode, extrêmement courante, est d'imposer des tickets Jira pour chaque tâche.
[00:18:17] Tout le monde déteste ça. Deuxième édition. Euh, ce n'est pas une excellente expérience développeur, mais encore une fois, vous savez, euh, cela existe et beaucoup d'entreprises le font.
[00:18:29] Euh, la troisième façon est ce que nous avons fait, euh, lors d'une expérience passée, c'est-à-dire recueillir des estimations approximatives pour les discussions et nous assurer que nous comprenons exactement ce que nous poursuivons et comment nos efforts d'ingénierie correspondent aux objectifs commerciaux.
[00:18:46] Le fait est que je ne sous-estimerais vraiment pas les avantages de mettre tout le monde au même niveau de compréhension de l'effort textuel. Le simple fait de pouvoir comprendre et montrer dans une grande organisation comment nos efforts d'ingénierie contribuent à différents OKR, à, vous savez, notre étoile du nord, à différents objectifs commerciaux, etc., cela change entièrement la nature des conversations, nous ne parlons plus de, vous savez, combien de tickets nous fermons ou combien de requêtes de tirage ou de points d'histoire ou quoi que ce soit. Nous parlons de la contribution stratégique de la technologie et cela fait toute la différence. En termes de relation entre la technologie et la direction. Cela apporte ou peut restaurer la confiance avec l'équipe de direction. Et honnêtement, je l'ai expérimenté de première main. C'est parfois tout ce qu'il faut pour s'assurer que vous avez une direction qui comprend que nous faisons partie de l'ensemble et pas seulement une usine à fonctionnalités.
[00:19:46] Cela donne du sens au travail quotidien. Parce que c'est quelque chose que vous allez montrer à l'équipe également pour montrer comment le travail quotidien participe à la vue d'ensemble. Et cela aide également à boucler la boucle de rétroaction entre la planification et l'exécution. Ce que je veux dire par là, c'est que nous voyons beaucoup d'entreprises où la planification et l'exécution sont étrangement séparées, de telle sorte que les personnes qui décident ce que nous allons faire ne sont pas nécessairement suffisamment exposées aux conséquences de leurs décisions en termes d'exécution. Cela signifie qu'il est très facile pour un dirigeant expérimenté de dire : nous allons lancer ce nouveau projet que je crois être la bonne chose pour l'entreprise. Et il est très facile de passer à la chose suivante sans nécessairement comprendre à quel point cela sera perturbateur pour l'équipe. La simple capacité de montrer comment les efforts d'ingénierie contribuent aux objectifs commerciaux aide à boucler cette boucle de rétroaction en termes de capacité à exprimer que notre focus est divisé et qu'il est divisé à cause de ceci et cela. Et que la seule chose que nous puissions faire en tant qu'organisation est de faire des arbitrages différents, mais nous n'allons pas créer magiquement de la capacité d'ingénierie. Et je pense que c'est vraiment, vraiment crucial.
[00:20:55] Comment utilisez-vous la mesure de l'alignement ? Eh bien, comme je le disais, deux choses. Montrer à leurs équipes leur contribution à la vue d'ensemble.
[00:21:04] Montrer à la direction la contribution technique à la stratégie globale et comment le budget est utilisé. passer à la chose suivante sans nécessairement comprendre à quel point cela va être perturbateur pour l'équipe. La simple capacité de montrer comment les efforts d'ingénierie contribuent aux objectifs commerciaux aide à boucler cette boucle de rétroaction en termes de capacité à exprimer que notre attention est divisée et qu'elle est divisée à cause de ceci et de cela et de cela. Et que la seule chose que nous puissions faire en tant qu'organisation est de faire différents arbitrages, mais nous n'allons pas créer magiquement de la capacité d'ingénierie. Et je pense que c'est vraiment, vraiment crucial.
[00:20:54] Comment utilisez-vous la mesure de l'alignement ? Eh bien, comme je le disais, deux choses : montrer à leurs équipes leur contribution à la vue d'ensemble.
[00:21:03] Montrer à la direction la contribution technologique à la stratégie globale et comment le budget est utilisé.
[00:21:11] Passons à la performance de livraison. Livrons-nous des logiciels efficacement ? Nous avons donc des métriques standard de l'industrie. Vous connaissez tous ce livre, Accelerate. Je ne vais pas le passer en revue. C'est une norme de l'industrie aujourd'hui, nous obtenons quatre métriques qui sont vraiment solides pour mesurer la performance de livraison des équipes. Et bien sûr, cela doit être fait au niveau de l'équipe et inclure la collaboration inter-équipes, pas au niveau individuel. Cela dit, je ne vais pas parler en détail des métriques Dora, que vous connaissez probablement déjà. Je vais juste parler de la façon dont elles peuvent facilement être mal utilisées et des pièges les plus courants que nous observons dans de nombreuses entreprises.
[00:21:52] Le premier est que les métriques de performance de livraison devraient appartenir à l'équipe comme un outil d'amélioration continue et d'excellence opérationnelle, et non comme une mesure de succès. C'est la même raison que j'ai dite plus tôt. Si vous croyez que les métriques Dora sont la mesure du succès de votre équipe, vous réduisez essentiellement votre mission à la livraison de code, ce qui n'est pas ce que devrait être votre mission en tant qu'équipe d'ingénierie. Il ne doit pas être utilisé comme un KPI pour communiquer avec la direction.
[00:22:24] Pourquoi ? Simplement parce que ce n'est pas actionnable entre les mains de la direction. Alors, qu'est-ce qu'ils vont en faire ? J'ai eu une discussion récemment avec un VP de l'ingénierie qui m'a dit qu'il utilisait le nombre de requêtes de tirage fusionnées chaque mois pour ses rapports au conseil d'administration. Et bien sûr, vous pouvez imaginer ce qui s'est passé. Un mois, il a montré qu'ils avaient fait 100 requêtes de tirage. Le mois suivant, il a montré qu'ils avaient fait 90 requêtes de tirage. Et on lui a demandé, genre, où sont les 10 manquants ?
[00:22:57] Qui s'en soucie ? Est-ce vraiment si important ? Et vous savez, peut-être que les 10 manquants sont pertinents parce qu'ils indiquent qu'il y a eu un changement de rythme ou un changement de processus ou quoi que ce soit, mais entre les mains du conseil d'administration, je ne pense pas.
[00:23:18] Les métriques de performance de livraison, comme chaque métrique existante n'est précieuse que lorsqu'elle entraîne des actions. Cependant, et je pense que c'est une erreur que beaucoup d'entreprises font actuellement à cause du sujet brûlant de la productivité des développeurs et des métriques Dora. Beaucoup de gens supposent que mettre des chiffres sur le tableau de bord, comme calculer les métriques Dora et les mettre dans une feuille de calcul, va d'une manière ou d'une autre provoquer un changement de comportement observable. Et la plupart du temps, ce n'est pas le cas. Pourquoi ? Parce que bien sûr vous êtes mesurés, mais après quoi ? La plupart des managers ne savent tout simplement pas quoi en faire. Encore une fois, ils ne savent pas ce qui est bon. Ils ne savent pas ce qu'ils devraient faire différemment en fonction de cela. Et je pense que c'est une erreur très, très courante.
[00:24:07] Alors, comment je recommanderais d'utiliser ces métriques de performance de livraison, eh bien, d'abord et avant tout en les exposant aux équipes. C'est là qu'elles appartiennent et c'est là qu'elles sont actionnables.
[00:24:18] Et les exposer avec des attentes claires. Comme en tant que VP de l'ingénierie, bien sûr, je vais rendre ces métriques disponibles pour les équipes. Et maintenant ? Qu'est-ce que je veux ? Ai-je un seuil que j'attends de chaque équipe qu'elle atteigne ? Est-ce que je recherche un certain niveau d'amélioration ? Est-ce que je ne recherche aucune dégradation ? Genre, qu'est-ce qui est bon ? Et je pense que c'est la partie qui manque très souvent dans le déploiement de ce genre d'efforts.
[00:24:45] Comment les utiliser non pas comme une mesure de succès pour une équipe, sauf peut-être dans le cas très spécifique d'une équipe plateforme.
[00:24:52] une équipe plateforme ou des efforts plateforme, essentiellement lorsque vous changez de plateforme ou que vous modifiez la façon dont l'entreprise livre des logiciels dans son ensemble et que vous voulez mesurer si cet effort particulier est réussi, alors oui, les métriques Dora sont probablement le meilleur indicateur que vous avez. parce qu'en fin de compte, elles vont elles vont capturer la capacité de l'équipe à livrer plus souvent et plus rapidement.
[00:25:19] La santé est le contexte favorable à un succès durable. C'est la plus difficile. Le mieux que nous ayons sont des indicateurs indirects. Nous ne pouvons pas mesurer cela avec précision car, bien sûr, il y a une composante humaine significative et ce n'est pas quelque chose que nous pouvons facilement mesurer. Les meilleurs indicateurs indirects sont le turnover, l'enquête de satisfaction ou les schémas de travail inhabituels. Donc, par exemple, voir quand, vous savez, quelqu'un a travaillé tous les week-ends ou toutes les nuits, quelque chose qui pourrait mener à l'épuisement professionnel.
[00:25:54] la façon dont vous voulez les utiliser est de vous assurer que vos résultats sont durables. Donc, essentiellement, que l'équipe ne paie pas le prix de, vous savez, la pression que l'entreprise leur met ou en termes de performance que vous essayez d'atteindre. Mais il est vraiment important de ne pas perdre de vue les objectifs.
[00:26:12] Ce que vous visez à comprendre, c'est ce qui va vous nuire à long terme, pas, vous savez, les chocs et les variations quotidiens qui peuvent se produire. Nous sommes des humains. Nous ne sommes pas parfaitement constants dans notre humeur, nous ne sommes pas constants dans notre engagement, dans nos activités, et c'est très bien. J'insiste là-dessus parce que je vois aussi des entreprises qui pensent, ok, peut-être que je vais utiliser, vous savez, comme encore une fois, des métriques de productivité ou des métriques d'activité pour remarquer quand quelqu'un ne contribue pas. Genre, oh, il est désengagé. Je dois lui parler, je dois leur parler. Eh bien, d'abord, vous devriez probablement leur parler de toute façon. Et avant ça.
[00:26:51] Et et deuxièmement, qu'est-ce que cela signifie lorsqu'une métrique d'activité diminue ? D'accord, peut-être que cette personne n'a pas contribué de code cette semaine-là, ce qui est totalement sans rapport avec la valeur qu'elle a produite. Peut-être qu'ils parlaient avec un client, peut-être qu'ils faisaient quelque chose qui avait beaucoup plus de valeur pour l'entreprise que d'écrire du code, mais ce n'est pas quelque chose que les métriques montreront. Et en général, bien sûr, aucune métrique ne devrait jamais remplacer les discussions individuelles.
[00:27:19] points clés de cette discussion.
[00:27:22] Notre incapacité à mesurer le succès de l'ingénierie est devenue insoutenable. La productivité des développeurs est une réponse aujourd'hui qui comble un vide mais est une mesure incomplète du succès.
[00:27:32] Le succès de l'ingénierie nécessite l'alignement, la performance de livraison et la santé. Merci beaucoup de votre attention. Je serai ravi de répondre aux questions et bien sûr, nous avons un stand si vous souhaitez poser des questions après et voir ce que nous construisons. Merci.
[00:27:46] Merci.
[00:27:55] Salut. Ah. Euh, ma question est que vous dites que certaines de ces mesures, si nous voulons en prendre, devraient être dans l'équipe. L'équipe l'apporte-t-elle alors aussi à l'équipe ? Parce que d'habitude, c'est comme ça que je le sais aussi, c'est que les CTOs ou les managers viennent et disent, nous faisons des métriques Dora maintenant ou, hé, j'ai regardé votre vélocité et ça a l'air bizarre. Euh, mais je vois souvent aussi que les équipes ne veulent pas être mesurées du tout. Euh, donc il est difficile d'apporter des mesures à l'équipe qui soient bonnes et précieuses pour les équipes.
[00:28:29] Je suis tout à fait d'accord. C'est, euh, je dirais qu'en général les équipes qui veulent utiliser les métriques Dora pour se mesurer le font probablement déjà. Donc, à cet égard, vous avez absolument raison. Néanmoins, je pense qu'il y a des avantages dans les mesures et c'est quelque chose que vous pouvez dire aux équipes. Euh, ce que nous voyons le plus souvent, c'est qu'il y a des entreprises qui sont assez, il y a une défiance vis-à-vis des métriques, ce qui n'est pas toujours justifié parce qu'il y a elles ont un rôle décent à jouer en termes d'amélioration continue, en termes de meilleure livraison de logiciels. Mais encore une fois, cela doit venir avec des attentes claires. Cela ne fonctionnera pas si, en tant que CTO, je viens à l'équipe pour dire, hé, nous mesurons maintenant ceci. Et maintenant quoi ? Genre, vais-je être jugé là-dessus ? Euh, est-ce que je m'attends à ce que ce nombre augmente ? Qu'est-ce que je fais ici ? Et je pense que c'est vraiment le plus gros euh, le plus gros point ici. Mais je ne les rejetterais pas dans leur ensemble parce qu'il y a je pense qu'il y a une façon raisonnable de les utiliser, surtout lorsque vous essayez, vous savez, de faire passer une organisation à des modes de travail plus modernes, euh, et y compris des choses comme, oui, livrer des logiciels différemment.
[00:30:23] Bon, plus de questions. Merci, Arno.
[00:30:25] Merci. Ah, il y en a un ici.
[00:30:27] Non, pourquoi dois-tu parler dans le micro ?
[00:30:32] Alors, étant donné que personne n'a posé de question, j'en pose une, peut-être qu'elle n'est pas bonne, mais
[00:30:40] vous parlez de productivité en ingénierie, mais cela a-t-il un sens, n'est-ce pas que nous produisons quelque chose lorsque nous travaillons avec le produit et le business ? Donc, mesurer l'ingénierie n'est-ce pas le reflet d'une vision brisée de ce que nous faisons réellement ou non ?
[00:30:59] Oui, c'est le cas d'une certaine manière. Et le problème est que la façon dont les entreprises sont organisées aujourd'hui, je pense, ne permet pas d'utiliser la satisfaction client ou l'impact commercial comme seule mesure de succès. C'est aussi simple que cela. J'aimerais pouvoir dire que ce devrait être la seule mesure qui compte et je pense que cela devrait probablement être le cas, mais ce n'est pas ce que les entreprises attendent aujourd'hui.
[00:31:23] Vous savez, au niveau personnel, ayant été moi-même CTO dans une assez grande organisation, c'est embarrassant. Parce que nous sommes, lorsque nous sommes dans un XCO avec d'autres C-levels, tout le monde a une mesure de succès. Tout le monde peut dire où ils réussissent d'une manière facile à communiquer et d'une manière facilement contestable. L'ingénierie n'a pas cela. Et cela, je pense, restera un problème même dans un monde parfait où nous serions incités uniquement sur le succès de notre entreprise.
[00:31:56] Bonne matière à réflexion. Merci.
[00:32:11] Merci.
[00:32:21] Et je pense que c'est l'heure de la pause-café, je suppose. Et n'hésitez pas à rencontrer Arnaud et son équipe au stand de Hiko avec les stands partenaires pour en savoir plus sur leurs produits.

Transcription (Traduit)