🤭 🏜️ 🗿 «Que faire lorsque des changements spectaculaires dans les processus démotivent une équipe.» L'expérience de l'ingénieur backend devenu chef d'équipe 🤵🏼 ↘️ 👉🏾

Pendant 7 ans, j'ai travaillé comme ingénieur backend chez Miro, puis suis devenu chef d'équipe. Au cours des dernières années, notre équipe d'ingénierie a doublé, est devenue distribuée et internationale, ce qui a entraîné de nombreux changements.

L'un d'eux a été l'introduction d'équipes interfonctionnelles capables de résoudre complètement le problème, du développement de l'idée à la sortie des fonctionnalités. Pour cela, les ingénieurs du backend et du frontend ont dû apprendre rapidement beaucoup de ce que nous n'avions jamais fait auparavant: tester, travailler avec les versions, mener des rituels de mêlée - sans perdre en vitesse et en qualité.

Les premiers pas dans cette direction ont entraîné une augmentation du nombre d'erreurs, une diminution de la vitesse de développement et de démotivation des équipes. Pendant cette période difficile, je viens de devenir chef d'équipe, donc ma peur personnelle de l'échec et ma propre incompétence ont ajouté au stress général.

En conséquence, nous avons surmonté la tempête, réduit de moitié le délai d'exécution et considérablement amélioré l'efficacité des équipes interfonctionnelles. Cela a été largement aidé par un changement de notre attitude face aux changements en cours, la transition de l'état d'esprit Fixe à l'état d'esprit Croissance.

Vous trouverez ci-dessous une vidéo et une transcription de ma performance à Saint TeamLead Conf 2019, où, en utilisant mon équipe comme exemple, je parle des processus et des outils qui ont rendu ces changements possibles.

Histoire n ° 1. Changer le processus de développement pour réduire les délais

En 2016, notre développement était composé de 20 personnes et 5 équipes. Les équipes ont interagi efficacement les unes avec les autres, échangé rapidement des informations et des expériences. Avec la croissance des employés et des équipes, l'introduction des processus CI / CD et la révision des codes, le nombre d'interdépendances entre les équipes a augmenté.

Par exemple, pour lancer une grande fonctionnalité sur un produit, l'équipe devait travailler avec 6 équipes d'ingénierie supplémentaires:

Donnez du code à la révision du code.
Donnez une fonctionnalité au test d'AQ. Si nécessaire, QA inclura la commande DevOps pour créer un environnement de test spécial.
Relâchez la fonctionnalité à l'aide du gestionnaire de versions, qui est responsable de toutes les versions de l'entreprise.
Connectez des commandes supplémentaires en cas de problème pendant la version.

Et cela sans tenir compte des dépendances avec les équipes marketing, design et support technique, qui sont également activement impliquées dans le lancement des fonctionnalités.

Plus il y a de dépendances, plus le délai est long, c'est-à-dire le temps entre le début du développement et la publication. Plus le délai d'exécution est élevé, moins nous offrons de valeur aux utilisateurs.

Un grand nombre de communications et une faible vitesse de livraison démotivent l'équipe. Que faire? Réduisez les dépendances et raccourcissez les délais.

Nous essayons de construire un convoyeur en développement

Pour résoudre ce problème, nous avons d'abord essayé de construire un convoyeur:

Décrire toutes les étapes et processus;
introduire le SLA (Service Level Agreement, niveau de qualité requis) pour déterminer le temps pendant lequel la tâche doit passer par chaque étape;
redresser les flux pour empêcher la tâche de revenir aux étapes précédentes pour des améliorations.

Malheureusement, le pipeline n'a pas fonctionné: une erreur à tout moment a entraîné la suspension de toute la chaîne, tandis que chaque équipe a été simultanément obligée de résoudre des problèmes à partir de son propre carnet de commandes. Par exemple, QA devait choisir: pour faire face à un bug sur le pipeline ou pour s'engager dans des tâches pour améliorer le processus de test. Ce problème de priorisation a conduit au fait que nous avons soit publié des fonctionnalités, mais n'avons pas eu le temps d'améliorer les processus internes, ou avons été engagés dans l'optimisation des processus et n'avons pas eu le temps de publier les fonctionnalités.

Ensuite, nous avons décidé de reconstruire le convoyeur pour le déplacer à l'intérieur de chaque équipe.

Essayer de créer des équipes interfonctionnelles

Les équipes interfonctionnelles sont capables de gérer la tâche du début à la fin: de l'élaboration de l'idée à la mise en place de la fonctionnalité finale sur le produit. Pour cela, l'équipe doit disposer de toutes les compétences, connaissances et processus nécessaires.

Nous avons décidé de mener une expérimentation sur plusieurs équipes avant de déployer les changements dans l'ensemble de l'entreprise. Mon équipe s'est également lancée dans l'expérience, qui traite principalement de tâches de bas niveau (j'ai écrit sur l'un de nos exemples de travail - implémentation d'ActiveMQ et Hazelcast). L'équipe était composée de 3 développeurs backend, d'un ingénieur QA à temps partiel et moi en tant que chef d'équipe.

Nous déterminons les interdépendances

Tout d'abord, nous avons déterminé les dépendances actuelles dont nous voulons nous débarrasser:

Il n'y a pas d'ingénieur AQ à temps plein, ce qui nous permet d'attendre les tests de quelques jours à une semaine.
, -.
full-time -, , .

Il y avait d'autres dépendances, mais nous avons décidé de nous concentrer principalement sur les trois. Maintenant, nous devions apprendre beaucoup de ce que faisaient auparavant l'ingénieur QA, Scrum master et le gestionnaire de versions.

Nous apprenons à tester de manière indépendante.
Auparavant, les ingénieurs écrivaient indépendamment des tests unitaires et testaient les fonctionnalités de base, le reste vérifiant l'AQ. Nous avons maintenant appris à tester indépendamment des situations limites et à écrire des tests de bout en bout pour tester l'interaction entre le client et le serveur.

Apprendre à se libérer
Nous avons convenu de vouloir sortir au moins une fois par semaine. Pour ce faire, nous avons besoin d'un responsable de publication au sein de l'équipe. L'un des développeurs backend est devenu de son propre gré.

Nous réalisons nous-mêmes des rituels de mêlée
Le scrum master externe n'a pas eu le temps de s'occuper de toutes les équipes, donc au sein de notre équipe nous avons choisi celle qui souhaitait ce rôle. Il avait besoin d'apprendre à réaliser indépendamment la planification, le toilettage et le rétro.

Naturellement, personne ne nous a jetés aux barricades. L'assurance qualité, le responsable des versions et le Scrum Master ont transmis leurs connaissances et conseillé dans les cas difficiles.

Premiers échecs

Les résultats du premier sprint ont été infructueux. Nous avons vraiment commencé à apporter des tâches à la branche principale beaucoup plus rapidement, mais nous n'avons pas pu faire indépendamment une seule version. Il s'est avéré que nos processus et scripts n'étaient pas prêts pour cela. Le script de version a pu libérer uniquement tous les services à la fois, nous n'avons donc pas pu libérer notre partie du service séparément.

Nous avons tordu une partie des processus et à la fin du deuxième sprint, nous avons mis les tâches du premier sprint dans la version. Cependant, quelque chose s'est mal passé. La moitié des fonctionnalités publiées contenaient des bogues critiques, nous avons donc décidé de revenir en arrière. Et ils ont été confrontés à un nouveau problème: notre développeur principal et notre responsable des versions à temps partiel dans l'équipe, ont appris à publier, mais n'ont toujours pas appris à annuler les modifications. Par conséquent, nous avions besoin de l'aide d'un gestionnaire de versions externe.

Tout cela a conduit à la démotivation de l'équipe: nous échouons au deuxième sprint consécutif, libérons des fonctionnalités avec des bugs critiques - le sentiment que nous ne pouvons rien faire par nous-mêmes.

Histoire n ° 2. Un nouveau rôle et la peur des erreurs

Au début de l'expérience avec des équipes interfonctionnelles, Max, l'un des ingénieurs du backend, s'est porté volontaire pour devenir un scrum master. Cependant, après le premier sprint, il est venu vers moi et m'a dit qu'il ne voulait plus être un scrum master. Après Max, Andrei, un autre ingénieur, a déclaré qu'il ne testerait pas: "Je suis un développeur, pas un testeur." En tant que chef d'équipe, il était important pour moi de comprendre les causes des deux échecs.

En règle générale, l'une des 4 raisons qui peuvent fonctionner avec chacun d'eux est la pierre angulaire de la décision d'abandonner la tâche:

   → , , .
(, , ) → , .
  , → : , .
   → .

Max a compris la valeur que le Scrum Master apporte à l'équipe, mais il avait peur de ne pas faire face aux tâches difficiles de l'animation des réunions. En acceptant un nouveau rôle, il savait peu de choses sur le travail du Scrum Master et ne se donnait pas un compte rendu complet des compétences dont il aurait besoin pour cela. Max avait peur de ne pas pouvoir faire face, il perdrait le temps de l'équipe et aurait l'air incompétent aux yeux de ses collègues.

Dans la situation avec Andrei, il s'est avéré qu'il avait testé son code par lui-même et était sûr que tout allait bien. Cependant, juste au cas où, j'ai donné un QA pour vérification, et il a trouvé 5 bugs dans le code. Cela a été répété plusieurs fois, ce qui a démotivé Andrei, et il a décidé de ne plus faire de tests.

Je connaissais bien les situations de Max et Andrei. Je suis moi-même récemment passé d'un ingénieur back-end expérimenté à un chef d'équipe inexpérimenté. Et tout comme j'avais peur de ne pas pouvoir faire face aux tâches, je ne répondrais pas aux attentes et, en général, le leadership d'équipe n'était pas le mien.

Installation sur croissance et installation sur un donné

Quand je suis devenu chef d'équipe, on m'a conseillé de lire le livre " Flexible Consciousness " du professeur Carol Dweck de l'université de Stanford . En bref, il décrit deux types de pensée:

État d'esprit fixe - la croyance que l'intelligence et les capacités sont fixées une fois pour toutes, il est impossible de les influencer et l'échec indique un manque de talent. Les gens avec une telle pensée essaient de ne pas prendre des tâches complexes afin de ne pas perdre leur motivation et leur confiance en eux-mêmes.
La mentalité de croissance est la conviction que l'intelligence et les capacités peuvent être améliorées tout au long de la vie si des efforts sont faits pour le faire. L'échec est une raison pour apprendre quelque chose, donc les gens avec ce genre de pensée essaient constamment de sortir de leur zone de confort et de se lancer dans des tâches complexes.

Naturellement, le monde n'est pas divisé en noir et blanc, dans différentes situations, la même personne peut être dominée par un type de pensée différent. Par exemple, une personne peut considérer que la programmation est une compétence que toute personne peut apprendre, mais en même temps, elle pense que la cuisine délicieusement est un talent inhérent à la nature, et cela ne peut pas être appris.

L'ensemble du dispositif se trouve sur le site Web de Carol Duque.

Cette approche décrit l'attitude d'une personne vis-à-vis des changements en cours.

Personnes ayant une prédominance de mentalité fixe (mise pour acquis)
: « , ».
, . , , .

Growth mindset ( )

, , .
, .
, .

Cette approche m'a aidé à changer mon attitude envers les erreurs. J'ai donc décidé de parler de l'approche de l'équipe, car elle pourrait nous donner un système de coordonnées unique, nous apprendre à traiter les changements différemment et à réduire la peur des erreurs. Comme tout outil, l'orientation vers la croissance fonctionne pour résoudre des problèmes spécifiques, alors j'en ai parlé lors de réunions 1: 1 pour donner à chacun les informations qui lui seraient utiles spécifiquement pour résoudre sa situation.

De plus, j'ai parlé à tous les membres de l'équipe de mon propre exemple de travail avec les paramètres au moment du changement de rôle d'ingénieur en chef d'équipe. Cela a ajouté au reste de la confiance en soi ("Je n'étais pas le seul à rencontrer cela", "il est vraiment possible de changer cette situation").

Suite de l'histoire numéro 2

Une expérience réduit les attentes et le stress. Après avoir discuté de l'approche avec la mentalité Growth & Fixed, nous avons convenu avec Max de lancer une expérience dans laquelle il tentera un nouveau rôle en tant que Scrum Master. Le mot «expérience» réduit bien le degré de stress. Dans l'expérience, il n'est pas effrayant de faire des erreurs, mais il est important de faire le travail sur les erreurs et de faire une expérience utile. Dans la même veine, nous avons parlé du nouveau rôle de Max au sein de l'équipe, ce qui a abaissé les attentes de l'équipe.

Le talent est une expérience acquise.Andrei, en discutant de son refus de tester, a laissé tomber la phrase: "Je suis doué en programmation." Il s'est avéré qu'Andrei considérait la programmation et les tests comme des talents innés. Il avait le premier, mais pas le second. Nous avons commencé à discuter de l’expérience d’Andrei et nous avons réalisé qu’Andrei a traversé la programmation à travers des nuits blanches à la recherche d’erreurs, des jours d’immersion dans les projets des autres, a écrit lui-même des dizaines de milliers de lignes de code. Il s'avère que son expertise en programmation n'est pas un talent, mais une expérience à laquelle il est allé pendant longtemps et à dessein. Juste en apprenant quelque chose, on oublie souvent les premiers pas dans cette direction.

OKR personnels.Afin de rendre nos progrès visibles même avec une légère avance, nous avons convenu avec l'équipe que nous suivrons les progrès de chaque entraînement. Cela vous aidera non seulement à voir le chemin parcouru, mais aussi à comprendre combien vous avez besoin de plus pour atteindre l'objectif prévu.

Au niveau de l'entreprise, nous avons des OKR, nous avons donc décidé de l'appliquer au niveau de la formation personnelle. Les conditions étaient les suivantes:

Nous ajoutons aux OKR personnels uniquement ce qui aide dans le travail en cours;
Les résultats clés devraient être mesurables à tout moment et aider à répondre à la question «Jusqu'où ai-je progressé par rapport à la semaine dernière?
Chaque résultat clé a une liste d'initiatives qui permettent de l'atteindre;
(, ), , ;
OKRs 1:1.

Mettre en œuvre des OKR personnels pour le trimestre
Quelques semaines après le lancement de l'initiative, nous avons réalisé que rien ne se passait. Il s'est avéré que nous étions sur notre propre râteau - surestimé nos propres attentes. L'équipe était inquiète de la nécessité de faire des OKR idéaux pendant longtemps et c'était une stupeur.

Ensuite, nous avons convenu que nous considérerions cela comme l'une des itérations. Les OKR peuvent toujours être revus et affinés, ce n'est pas quelque chose de gravé dans la pierre, mais plutôt la direction que vous souhaitez développer. Cela a aidé à percevoir l'initiative comme un jeu intéressant, et les choses se sont passées.

Exemple d'OKR par Andrey

Bonus, nous avons accepté de partager des OKR personnels au sein de l'équipe. Il aide à apprendre les uns des autres et fonctionne comme un engagement public.

Suite de l'histoire numéro 1

Grâce à un changement d'attitude, rétrospectivement, nous avons commencé à rechercher les causes des difficultés en nous-mêmes et non à l'extérieur. Maintenant, il n'y avait aucune excuse qui aurait pu retentir plus tôt: "Donc, le processus est construit, que puis-je faire." Nous avons commencé à affiner des processus qui ne nous convenaient pas. L'équipe a acquis un sentiment d'appropriation des processus en cours.

Cela nous a permis de commencer à mettre en œuvre de manière stable un petit nombre de tâches. Bien que c'était moitié moins qu'avant, mais nous l'avons mis en vente de manière totalement indépendante et sans bugs.

Tout cela nous a donné confiance en nous. Après un certain temps, Andrey a automatisé indépendamment des cas de test complexes. Roma, qui est responsable des sorties, a optimisé le processus afin que chaque membre de l'équipe puisse désormais sortir indépendamment.

En conséquence, sur la base des résultats du trimestre, nous avons pu réduire le Lead Time de 2 fois en raison de la réduction des dépendances, de l'augmentation des compétences au sein de l'équipe et du changement d'attitude face aux difficultés et aux erreurs.

Notre productivité est affectée non seulement par les connaissances et les compétences que nous possédons actuellement, mais aussi par la façon dont nous nous rapportons aux changements dans l'entreprise. Parfois, de nouveaux processus peuvent démotiver et des tâches trop complexes peuvent saper la confiance en soi. Mais avec cela, vous pouvez travailler à la fois pour vous-même et au niveau de toute l'équipe.

Mon équipe a été aidée à faire face aux changements et à l'attitude envers les erreurs de la mentalité Croissance et Fixe. Nous le traitons comme un outil de travail qui résout des problèmes spécifiques. Bien sûr, l'installation n'a pas changé en quelques semaines et quelques mois. Mais en changeant d'attitude face à des situations spécifiques, nous avons pu avancer significativement au cours du trimestre par rapport aux tâches et difficultés de travail quotidiennes.

«Que faire lorsque des changements spectaculaires dans les processus démotivent une équipe.» L'expérience de l'ingénieur backend devenu chef d'équipe