Je suis devenu chef d'équipe deux fois
J'ai ce trait: essayer d'établir un ordre parfait dans tout, de systématiser, de construire des processus. J'ai donc toujours été attiré par plus que le codage. Ma première startup, appelons-la "T", était dans le chaos total dans le processus de développement.
Maintenant, je commençais à peine à travailler là-bas, mais c'était alors très atmosphérique. Imagine seulement. De nombreux clients parallèles. Le responsable est allé directement (et ponctuellement) aux développeurs. Nous avons souvent manqué les délais annoncés et nous nous sommes levés tard. Je me souviens comment un jour le patron a appelé à 20 heures et lui a demandé de venir travailler pour peaufiner la fonctionnalité pour le client, car "il a annoncé la date limite demain matin". Mais chez T, nous étions de la famille.
Et ils ont tout fait eux-mêmes - du mieux qu'ils pouvaient. Je me souviens avoir mis Ubuntu sur un serveur rack que l'un des investisseurs nous a donné. Quand je l'ai allumé, il a fait le bruit d'un hélicoptère qui décollait!
Là, j'ai grandi au statut de directeur technique et travaillé avec une équipe de 10 personnes. En fait, la première, sur un coup de tête, l'expérience du leadership d'équipe s'est déroulée là-bas.
En D, où je suis venu en tant que développeur, les choses étaient différentes - surtout en ce qui concerne les processus.
La société a implémenté Scrum classique: des sprints clairs, des graphiques de burndown, des démos, du planning, des story points, du toilettage pour préparer le futur sprint. J'ai été étonné de la qualité du processus, j'ai écrit le code tranquillement et j'ai observé comment tout fonctionnait. Puis il est devenu ami avec le Scrum Master et a commencé à lui poser des questions. Il a répondu avec empressement et a partagé des livres sympas.
Je me souviens surtout de "Scrum and XP: Notes from the Front Line" de Henrik Kniberg. Le processus en «D» a été construit près de cette méthodologie: en conséquence, tous les cadres et commerciaux savaient parfaitement quand le résultat serait.
J'ai également rejoint Skyeng en tant que développeur. Contrairement à mes autres entreprises, l'intégration continue est parfaitement mise en œuvre ici: chaque jour, des fonctionnalités sont mises en production. Dans mon équipe, le processus ressemblait le plus à Kanban.
Nous avions un excellent chef d'équipe Petya. Lors d'appels individuels, nous pourrions discuter de tout: des problèmes de non-respect des délais aux paramètres du suivi des tâches. Parfois, je faisais simplement des commentaires, parfois je conseillais quelque chose.
Petya a donc vu à travers moi et a appris l'expérience du leadership d'équipe chez T et de l'apprentissage à distance Scrum chez D.
À un moment donné, il m'a suggéré de tenir un stand-up.
L'opération «successeur» dans mon cas ressemblait à ceci et a pris 6 minutes)
Et une semaine plus tard, il s'est avéré qu'une nouvelle direction était en train d'être ouverte dans l'entreprise, et Petya avec une partie de l'équipe est allée à ce projet. Les gars restants ont besoin d'une nouvelle avance.
Tout se passe tout seul, comme si la loi invisible de l'attraction vous poussait dans la direction du leadership d'équipe.
Lorsqu'une entreprise a besoin d'un chef d'équipe et que tout le monde se dit: «Où puis-je l'obtenir?», Ils prennent souvent des personnes qui:
- mieux organisé
- sont rapidement impliqués dans les processus et les idées de l'équipe,
- motivé et gagnant en crédibilité aux yeux des autres développeurs.
Ces personnes sont rapidement notées dans la direction, en fait, par conséquent, lorsqu'une vacance apparaît, elles vont vers elles. Cela a donc fonctionné pour moi et au moins pour plusieurs collègues d'autres entreprises avec qui j'ai parlé à ce sujet. Et c'est drôle que tout le monde ait noté que la transition n'a pas eu à faire presque aucun effort.
Ici, nous devons expliquer qui est le chef d'équipe dans notre cas.
, (, - , ). : , . , .
Skyeng :
Skyeng :
Mais c'est une chose d'assumer les tâches d'un chef d'équipe, et une autre de les assumer.
Ce qui a changé et comment je l'ai géré
Les premiers jours, vous vivez avec une sensation d'euphorie, de triomphe et de plaisir. Pourtant: vous êtes à la tête de toute une équipe, un enjeu est fait sur vous, vous avez plus d'opportunités et de responsabilités! Plusieurs années se sont écoulées depuis mon départ de T, j'ai acquis de l'expérience, analysé mes erreurs, vu des processus et des méthodologies avancés et travaillé dessus. Tout cela m'a donné force et confiance pour la deuxième entrée dans la direction d'équipe.
Cependant, au fil du temps, le sentiment d'euphorie est passé et la vie quotidienne a commencé. Voici ce que j'ai remarqué.
Vous devez être mentalement prêt à vous séparer du «zen tous les soirs» ... et à vous lier d'amitié avec le «trimestriel». Le résultat du travail d'un chef d'équipe n'est généralement pas vu en un jour ou même une semaine. C'est à la fois un avantage et un inconvénient.
Dans son rapport "Pannes et pannes pendant la transition d'ingénieur à chef d'équipe", Artem Kalichkin frappe droit au but, affirmant que "les programmeurs sont l'une des personnes les plus heureuses du monde".
Lorsque vous êtes développeur, vous avez chaque jour une compilation compilée, une tâche terminée, une nouvelle fonctionnalité en production - et il y a un certain plaisir à cela. Une sorte de zen: j'ai fait le boulot, vous pouvez aller vous reposer le soir l'esprit tranquille.
Le chef d'équipe a rarement quelque chose à partager au stand-up: parce qu'hier vous avez «fait le planning, étiez sur les appels téléphoniques, lu le courrier et ajouté des tâches au backlog». Les résultats tels qu'une nouvelle section sur le site ou une grande fonctionnalité de l'application sont constitués de petites étapes que vous et votre équipe franchissez chaque jour. Pendant ce temps, vous ne pouvez pas écrire une seule ligne de code, mais en général, vous glisserez dans un volume de travail que vous n'auriez jamais maîtrisé pendant ce temps.
Par exemple, mon équipe a créé une section Sujets d'étude pour l'application Skyeng sur iOS et Android: nous avons implémenté une carte de niveau d'exercice, une échelle d'énergie pour différentes catégories d'élèves, des objectifs quotidiens, des suiveurs de progression des tâches, différents mécanismes pour les cartes de tâches, la voix et plus encore.
La même section en annexe.
Vous pouvez estimer le nombre d'écrans et la mécanique d'une leçon sur le GIF: le déplacement est accéléré
C'est en grande partie une histoire de délégation. Vous devez combattre l'habitude de tout faire vous-même. Fondamentalement, pour devenir un véritable chef d'équipe, vous devez apprendre à programmer avec les mains des développeurs de votre équipe.
Un chef d'équipe inexpérimenté peut facilement devenir le «goulot d'étranglement» d'une équipe . Moins le développeur est distrait du travail, plus le résultat et l'équipe sont idéaux. Par conséquent, il a un arriéré de tâches avec des priorités, un stand-up et quelques autres réunions par semaine. Et si vous avez besoin de planifier une nouvelle fonctionnalité pour le travail, un bogue critique est détecté, la prod est interrompue ou l'équipe a une question, elle tire le chef d'équipe. Pour que tout et chacun travaille, il faut beaucoup communiquer.
« -» — , - .
Ici, je veux dire
Les pratiques que j'ai apprises ont aidé à éliminer la défocalisation. J'ai averti tout le monde que je vérifierais les appels entrants 1 à 2 fois par jour, que je commençais à organiser des jours sans réunions ni appels, que je planifiais ma journée de travail par écrit (j'ai même essayé d'introduire cette pratique dans l'équipe, mais les développeurs n'aiment pas cela). Je n'ai changé de priorités que si quelque chose de vraiment critique se produisait. En conséquence, les choses que j'avais prévues n'étaient plus reportées.
En général, je devais briser mes habitudes et maîtriser de toute urgence un tas de techniques utiles.
Les compétences requises pour un lead ne sont pas développées au cours du développement. En tant que chef d'équipe, vous devenez un participant actif dans la relation commerciale entre les affaires et le développement. Le but de toute entreprise est le profit, de sorte que le client souhaite obtenir de nombreuses fonctionnalités de haute qualité du développement en peu de temps. Les développeurs s'efforcent de faire de la qualité, mais pas pressés. Sur cette image, le chef d'équipe doit garder le juste équilibre entre qualité, rapidité et volume de tâches à résoudre.
Pour ce faire, vous devez construire une relation de confiance avec le client afin qu'il comprenne ce que fait l'équipe, combien de temps il faut pour couper une fonctionnalité particulière, que nous ayons le temps ou non, ce qu'il faut faire pour avoir du temps. Vous devez développer ces «compétences générales» et en même temps défendre fermement la position et les principes de l'équipe. Et pensez également aux processus, aux formats, à l'architecture du pipeline: comment les tâches vous parviennent, comment elles sont exécutées, comment elles sont corrigées, comment elles passent en production.
Bien sûr, les compétences elles-mêmes peuvent être développées. Mais vous devez être prêt à ce que cela conduise à une certaine transformation de la personnalité.
Plus de chef d'équipe: comment ne pas se perdre et se retrouver
Il y a deux ans, je croyais que le chef d'équipe était la prochaine étape dans l'évolution d'un programmeur. Maintenant, je pense que c'est une autre branche parallèle du développement. Le résultat de la transition dépend fortement de chaque personne - et vous ne le saurez pas avant d'essayer.
Ce rôle doit être testé. Et pas un mois, pas deux. Au moins six, je pense. Encore mieux - un an ou deux. Il y a une forte probabilité que ce soit difficile, vous voudrez revenir en arrière sans obtenir de résultat. Je vous conseille de vous fixer un délai et de dire: «Je ne tire pas de conclusions intermédiaires avant la fin de ce délai. Je vais le tester et à la fin je déciderai si c'est à moi ou non. " Personnellement, c'est exactement ce que j'ai fait.
Après avoir travaillé comme lead pendant un an et demi (de septembre 2018 à février 2020), j'ai consciemment décidé de quitter ce poste et de reprendre le développement. Dans le même temps, chef d'équipe, canalque j'ai lu a grandi en tant que CTO dans mon entreprise.
Nous sommes toujours distants, la communication principale se fait dans Slack: donc "tous les coups sont enregistrés". Tout s'est avéré comme sur la photo: le collègue que j'ai proposé s'essaye en tant que chef d'équipe, et je profite de la "soirée zen" dans le cadre d'une autre équipe.
Et cet été, avec quelques autres gars qui ont emprunté le même chemin, nous avons fait une rencontre interne sur notre expérience. Et la question la plus importante qui s'est posée du public: ok, comment comprendre, quand on réfléchit à où se développer davantage, le rôle de l'équipe dirigeante est-il le vôtre ou non?
L'idée est donc venue d'en discuter dans un format public avec:
- Egor Tolstoy (podcast et cours Podlodka) - il a fait un choix en faveur de la gestion de produit et parlera du moment où il s'est rendu compte qu'il était fatigué du leadership du développement,
- Vadim Martynov (Kontur et la communauté RndTech) - il est retourné aux développeurs et racontera comment il s'est recyclé pour écrire du code et comment tout cela a affecté les finances,
- et Eugene Kot (Wrike et la même conférence sur les douleurs des chefs d'équipe) en tant que modérateur.
Tout se déroulera en ligne mercredi prochain (2 septembre) à 19h Moscou / Kiev / Minsk sur YouTube: les téléspectateurs auront un chat et une simple opportunité d'allumer par la voix. Et si vous avez encore la force, parlons en zoom.
Ici, vous pouvez ajouter un rappel à votre calendrier .
Rejoignez la discussion "MoreNeTimlead" ou regardez-la dans l'enregistrement. J'espère que notre expérience vous sera utile, car il y a deux ans, je pensais aussi que ...