🕍 🦁 👩🏻‍🤝‍👨🏼 Comment développer un gestionnaire de développement 👩🏿‍✈️ 🕵️ 🛥️

Quand quelqu'un devient chef du développement, un grand nombre de nouvelles tâches inattendues lui incomberont sûrement et l'adaptation prendra certainement du temps. Cependant, la période d'adaptation prendra fin un jour, puis la question sera de savoir comment évoluer. La question de la préparation d'un employé au futur rôle de leader n'est pas moins pertinente. Comment travailler avec le développeur pour que le futur leader se détourne de lui au plus vite?

Nous avons choisi la voie de développement pour les responsables du développement comme thème du prochain Meetup Team Leader , qui aura lieu dans la soirée du 28 novembre au bureau de Yandex Moscou. Il sera possible de discuter de ce sujet avec des experts de grandes sociétés informatiques. L'inscription est toujours ouverte.

Cette fois, nos experts sont:

Nikolay Krapivny, responsable du développement backend, Badoo
Roms romains1982 Ivliev, CTO, mos.ru
Alexander Polomodov, directeur de la recherche et du développement, Tinkoff.ru
Boris Tobotras, directeur, Software Solutions Center, Jet Infosystems
Victor Lamburt, responsable des produits recommandés, Yandex
Igor Kuralenok, PDG, League of Experts

Aujourd'hui, à Habré, nous leur posons un certain nombre de questions pour donner le ton aux discussions futures:

1. Quels conseils donneriez-vous à votre collègue - un développeur solide qui est récemment devenu hier chef d'équipe? Quelles actions spécifiques et compréhensibles doit-il commencer son travail dans un nouveau poste?
2. Quels livres ou articles recommanderiez-vous de lire au responsable du développement? Et quelles ressources est-il judicieux d'étudier régulièrement?
3. Combien de temps cela coûte-t-il de travailler sur des tâches techniques et combien - sur des tâches liées à la gestion d'une équipe? Quoi d'autre peut ou devrait un Timlid passer son temps?

Nikolay Krapivny , responsable du développement backend, Badoo

Quels conseils donneriez-vous à votre collègue - un développeur solide qui est récemment devenu hier chef d'équipe? Quelles actions spécifiques et compréhensibles doit-il commencer son travail dans un nouveau poste?

Je recommanderais pour commencer:

Comprendre ce dont il est maintenant responsable et quelles sont ses principales responsabilités en tant que chef d'équipe
Coordonner avec le manager les principaux buts et objectifs pour lui et son équipe
Discutez avec les membres de l'équipe, découvrez comment l'équipe fonctionne maintenant
Consultez le rapport de délégation et apprenez à le faire
Allouer régulièrement du temps pour lire des articles, des livres, consulter des rapports sur de nouveaux domaines de responsabilité pour lui

Quels livres ou articles recommanderiez-vous de lire au responsable du développement? Et quelles ressources est-il judicieux d'étudier régulièrement?

Pour le responsable du développement, je recommande la lecture:

"Comment Google fonctionne" par Eric Schmidt
"Work Rules" par Laszlo Bock
"Le but" par Eliyahu M. Goldratt

Sur une base régulière, je pense qu'il vaut la peine de suivre les documents et les performances avec Teamlead Conf et d'autres rallyes thématiques (par exemple, les rallyes de Badoo de Timoo)

En outre, de nombreux liens et discussions utiles peuvent être trouvés dans les canaux thématiques du télégramme: https://t.me/leadgr et https://t.me/TeamLeadTalks

Combien de temps cela coûte-t-il de travailler sur des tâches techniques et combien - sur des tâches liées à la gestion d'une équipe? Quoi d'autre peut ou devrait un Timlid passer son temps?

Je pense qu'il n'y a pas de réponse correcte unique. La tâche du responsable consiste précisément à évaluer une situation spécifique et à décider lui-même de la manière de répartir votre temps afin d'obtenir des résultats optimaux.

Dans mon monde idéal, moins il faut de temps pour diriger une équipe (j'inclus des fonctions techniques et managériales dans la gestion), mieux c'est. Je crois que la clé du succès et de la croissance future du responsable est de construire une équipe qui fonctionne efficacement avec une participation minimale. Dans ce scénario, le leader peut et doit investir le temps libre dans la recherche de nouvelles idées et projets utiles en dehors du domaine de responsabilité actuel.

Roman Ivliev , CTO, mos.ru

Il est temps de télécharger le soft-skiz. L'ingénierie est bonne, mais il y a maintenant des gens avec qui travailler d'une manière complètement différente. L'ingénierie s'estompe à l'arrière-plan. Vous pouvez lire, vous pouvez écouter des conférences, vous pouvez tous ensemble. Il n'y a pas beaucoup d'informations sur ce sujet.
Apprenez que vous n'êtes plus développeur. Le codage disparaîtra en arrière-plan. Ce sera la rupture, mais c'est inévitable. En conséquence, vous devez décider quel travail technique vous reste, pour ne choisir que le plus important. Commencez à distribuer le reste à vos collègues.
Cherchez d'urgence un remplaçant à sa place. Après tout, depuis que vous êtes devenu un leader - quelque part, un trou a été formé au lieu d'un bon ingénieur, et cela se rappellera dans le premier projet :))
Créez immédiatement un mode pour vous-même. Au début, il n'y a pas assez de temps pour tout, énormément, vous devez consacrer beaucoup plus de temps à la planification. Et voyez-vous que quelque chose ne se passe pas comme prévu. La prise de décision impulsive hantera la première fois. Eh bien, l'envie de tout encoder :)
Commencez immédiatement à établir une carte des communications et à établir des communications. Au niveau du lead, la quantité de communication est beaucoup plus importante, il serait préférable de savoir immédiatement sur quels problèmes contacter.

Quels livres ou articles recommanderiez-vous de lire au responsable du développement? Et quelles ressources est-il judicieux d'étudier régulièrement?

Il y a beaucoup de bons livres, je vais me concentrer sur les principaux, comme il me semble.

Brooks «Mois-homme mythique, ou comment les systèmes logiciels sont créés» - il suffit de le lire, car c'est un classique.
Tom Demarco et Timothy Lister. «Le facteur humain. Projets et équipes réussis »- ces gars-là sont généralement cool, ils peuvent être lus dans leur intégralité, ce qui sera utile. En plus de cela, je dirais aussi «ceux qui réfléchissent à l'adrénaline et aux motifs de zombies. Modèles de comportement de l'équipe de projet. »
Patrick Lensioni. «Cinq vices de l'équipe. Les paraboles du leadership. » Patrick est cool, vous pouvez le lire autant que vous le pouvez.
L'eau de pluie. "Comment faire paître les chats", mais ce travail n'est pas pour tout le monde. Parmi ceux avec qui j'ai eu l'occasion de discuter de ce livre, les avis étaient partagés.

Il faut quelque chose au sujet des négociations, de l'intelligence émotionnelle et de la capacité de communiquer avec les gens. Vous pouvez Gavin "Vous pouvez être d'accord sur tout," Goulston "j'entends à travers vous", "Ne grognez pas au chien" de Karen Prior.

Ressource plus difficile. Habituellement, je trouve des documents intéressants sur Medium , Habré , GeekTimes , infoq.com , des blogs de personnes respectées comme Joel Spolsky. Je me suis abonné à plusieurs canaux de gestion, où les liens intéressants sautent constamment, je les regarde, et en même temps j'étudie la ressource sur laquelle ils sont postés. Vous pouvez donc trouver de nombreux sites et blogs peu connus, mais avec un très bon contenu. Vous pouvez lire vc.ru , la newsletter Megaplan lance parfois de bons documents.

Tout dépend de la façon dont le projet, l'équipe, l'entreprise. J'ai rencontré des proportions complètement différentes, mais le plus souvent, c'est quelque chose comme 100% du temps pour les tâches techniques et 46% du temps pour la gestion :))) Ça finit toujours aussi mal. À mon humble avis, en réalité, la proportion la plus correcte ressemble à ceci. Le temps pour les tâches techniques est 100% moins le temps pour la gestion d'équipe. 100% n'est pas 8 heures, si cela. Chacun a son propre 100%. En d'autres termes, le chiffre flotte.

Il est nécessaire de consacrer du temps à l'auto-éducation, d'élargir ses horizons dans des domaines connexes (gestion de produit et de projet; si vous êtes un backend, mettez une baguette à l'avant, test, fonctionnement et vice versa, bien sûr), en conservant la forme technique - nouveaux cadres, bibliothèques, langues, tout ce qui est en quelque sorte lié au travail. Sinon, il y a un risque de perte de crédibilité auprès des ingénieurs. Vous devez assister à des réunions et des conférences afin d'élargir vos horizons et chercher des réponses à vos questions.

Alexander Polomodov , directeur de la recherche et du développement, Tinkoff.ru

Arrêtez-vous et répondez à vos questions:

Ce qu'on attend de moi dans un nouveau poste.
Qui et quels rôles jouent actuellement dans l'équipe:
- Qui est sur la liste des clients de l'équipe (est-ce un ou plusieurs)
- Qui devra signaler
- Quels employés font déjà partie de l'équipe
- Qui devra communiquer horizontalement (autres pistes de développement, pistes d'infrastructure, tests, ...)
Quels sont les objectifs de l'équipe et quelles sont les attentes des résultats de ses activités

En outre, compte tenu des résultats des réponses à ces questions, il est nécessaire d'élaborer un plan pour qui remettre les anciennes responsabilités et comment accepter les nouvelles. Il faut tenir compte du fait qu'après la transition vers le poste de chef d'équipe, il y aura plus de communication, mais moins de temps pour le développement. Il est très important de prendre en compte des critères de réussite, selon lesquels vous et votre manager comprendrez que vous réussissez à faire face à un nouveau poste.

Si nous passons à la deuxième question sur les actions spécifiques et compréhensibles, je peux dire qu'il n'y a pas une telle liste d'actions compréhensibles qui s'adapte universellement à toutes les situations, ce qui signifie que vous devez faire une telle liste vous-même en fonction de votre situation.

Quels livres ou articles recommanderiez-vous de lire au responsable du développement? Et quelles ressources est-il judicieux d'étudier régulièrement?

Je voudrais souligner le livre Mythical Man-Month de Frederick Brookes. Il s'agit d'un classique des problèmes de l'équipe dans les grands projets, dans lesquels le projet IBM OS 360 est décrit en détail. Je trouve également les livres de Tom Demarco très utiles, en particulier The Human Factor et The Patterns of Behavior of Project Teams. Et pour une collation, je recommanderais le livre de J. Hank Rainwater, "Comment faire paître les chats".

Parmi les ressources en ligne, j'honore le fil de gestion Habré et je me familiarise avec les discours dans les fils de gestion lors de grandes conférences, telles que RIT, Highload ++, Codefest et autres.

Un de mes hobbies est le développement au sens large du terme, y compris la gestion des équipes de développement. Et je publie mes pensées, impressions sur les livres que j'ai lus, assisté à des conférences et des réunions sur ma page Facebook . Peut-être que cette page vous sera utile.

Il est impossible de dire clairement dans quelle proportion répartir le temps entre les tâches techniques et l'équipe, car cela dépend grandement de l'équipe spécifique et de ses tâches. En général, on peut dire que la solution des problèmes techniques devient secondaire à une équipe travaillant efficacement. À mon avis, le chef d'équipe devrait consacrer du temps à:

travailler avec des clients externes et agir comme interface d'équipe pour le monde extérieur
organisation du processus de développement et livraison rythmique du code
accroître l'efficacité des membres de l'équipe - former et consulter des collègues
interviewer de nouveaux gars avec la croissance de l'équipe
résolution de problèmes techniques (rédaction de code, révision, ...)

Boris Tobotras , directeur, Software Solutions Center, Jet Infosystems

Je lui dirais: cher ami, vous avez une tâche terriblement intéressante: inclure dans votre image du monde non seulement la technologie, mais aussi les personnes, les projets et leurs relations complexes. Cela vous permettra de résoudre des problèmes qualitativement plus complexes qu'un seul développeur leader ne peut pas résoudre à lui seul. Pour ce faire, vous devez apprendre à voir non seulement ce que nous faisons dans le travail de projet quotidien, mais aussi ce pour quoi nous le faisons, comment et pourquoi.

Supposons que le timlid fraîchement préparé tombe dans ce nouveau projet pour lui-même. Vous pouvez commencer par obtenir des réponses à des questions spécifiques:

Comment se déroule le projet sur lequel travaille l'équipe? Quel objectif devrait-il atteindre, qui et comment jugera sa réalisation?
Qui fait partie de l'équipe? De quel genre de personnes s'agit-il, quelle est leur expérience, leur spécialisation, les caractéristiques de leur travail?
Avec qui l'équipe interagit-elle? Qu'attend le projet du développement et qu'attend-il à son tour des équipes concernées (analystes, QA, architectes, force de vente, support technique)?
Avec qui le chef d'équipe interagit-il personnellement? Qu'est-ce que le chef de projet attend de lui, qu'est-ce que l'équipe attend de lui, qu'attendent de lui les responsables des équipes liées? Quels problèmes voient-ils dans le développement?
Quel est l'état du projet? Où en sommes-nous maintenant, ce qui a été fait et ce qui reste? Avons-nous fini ou pas, et pourquoi? Quels sont les problèmes connus du projet actuellement - techniques, organisationnels, humains?

Que faire en premier?

Apprenez à savoir en détail qui fait quoi et où.
Analysez l'arriéré, lisez l'intégralité du suivi de projet, consultez les derniers validations et revues.
Comprendre la méthodologie de gestion de projet (style de code, VCS / branches, assemblages, workflow dans le tracker, versions prises en charge, artefacts émis).
Comprendre en détail l'architecture du système en cours de développement avec son histoire (quelles décisions ont été prises et pourquoi).

Quels livres ou articles recommanderiez-vous de lire au responsable du développement? Et quelles ressources est-il judicieux d'étudier régulièrement?

Brooks, Mythical Man-Month. Rien n'a changé au cours du dernier demi-siècle.
Alan, Colston, la pierre des programmeurs.

Il n'y a presque pas de recettes ici. Eh bien, tirons-le de la lampe de poche: 70% sur la technologie, 30% sur les gens. Mais cette proportion varie avec la taille de l'équipe. Si l'équipe compte 15 personnes (monstrueusement beaucoup d'IMHO par lead), la proportion est de 5% / 95%.

En plus des tâches «internes» (équipement + personnes), Timlid résout également les tâches «externes»: la gestion de la vitesse de développement et de la portée du projet, ainsi que les plans de gestion pour travailler dans le projet, prédit l'emploi des développeurs

Victor Lamburt , responsable des produits recommandés, Yandex

Tout d'abord, je vous conseillerais de savoir ce qui est arrivé à l'ancien chef d'équipe et ce que votre nouveau chef attend de vous. Après cela, parlez à chaque membre de l'équipe, découvrez leurs attentes et leurs problèmes et essayez également de comprendre leurs peurs.

Quels livres ou articles recommanderiez-vous de lire au responsable du développement? Et quelles ressources est-il judicieux d'étudier régulièrement?

Nous sommes nombreux dans cette interview et, à coup sûr, mes collègues citeront des livres importants directement liés à la gestion du développement. Par conséquent, je vais saisir l'instant et mentionner trois livres importants dans des domaines complètement différents.

Ed Catmell. Corporation des génies. Comment gérer une équipe de personnes créatives

Le livre est écrit par le fondateur de Pixar. En lisant, on s'étonne de la sagesse, du tact et en même temps de l'auteur audacieux. Comment lui et une petite équipe de personnes partageant les mêmes idées ont réussi à réinventer le genre d'animation, créant des chefs-d'œuvre qui touchent des millions d'enfants et d'adultes à travers le monde. Comment Ed Ketmell a établi un dialogue avec Steve Jobs, en défendant l'équipe et en utilisant l'expérience de Steve au profit de la croissance de Pixar.

Racontant l'histoire de la naissance des chefs-d'œuvre, l'auteur rappelle qu'ils étaient tous extrêmement maladroits au début, comme les nouveau-nés. Rien ne valait la peine de les écraser juste après la naissance. Et seules la patience, l'amour et un grand nombre d'itérations ont permis aux idées de se renforcer et de se transformer en films oscarisés.

Ed parle également de la façon de créer une atmosphère dans laquelle les gens expriment ouvertement des opinions critiques, et les critiques sont heureux d'utiliser cette opportunité pour améliorer leurs créations.

Si seulement nous pouvions faire ça, non?

David Keirsey. S'il vous plaît, comprenez-moi II: tempérament, caractère, intelligence

Dans la deuxième édition, David Keirsey explique systématiquement et visuellement pourquoi les gens font souvent complètement différent de ce que vous attendez. Il s'avère que des personnes d'une même profession, situées dans le même contexte socioculturel, peuvent prendre des décisions de manières complètement différentes, en appréciant des choses complètement différentes. Et cela arrive tout le temps, avec un être cher, avec des enfants, avec des parents et, bien sûr, dans des équipes de développement.

Malgré certaines critiques, la typologie du MBTI aide les gens à mieux comprendre, rationaliser leurs actions et construire des équipes plus équilibrées.

Daniel Kahneman Pensez lentement ... Décidez rapidement

Le fondateur de la théorie économique psychologique parle avec fascination des distorsions cognitives avec lesquelles nous vivons, sans les remarquer. Le livre est plein d'exemples qui démontrent que vous et moi ne sommes pas sacrément rationnels et que nous pouvons être facilement manipulés.

Le livre enseigne non seulement à reconnaître de telles manipulations, mais vous fait également réfléchir sérieusement à l'opportunité de faire ceci ou cela, semble-t-il, une redistribution très rationnelle des responsabilités.

Je dois avouer que je n'ai pas travaillé sur des tâches vraiment techniques depuis longtemps.

Igor Kuralenok , PDG, League of Experts

Commencez à regarder autour de vous. Remarquez ce que les gens du groupe font, comment ils le font, ce qui les rend heureux, ce qui les rend tristes. Faites attention à toutes les nuances qui composent le microclimat dans l'équipe dont vous êtes désormais responsable. Votre connaissance de vos enfants et de vos filles vous permet de créer une synergie et de ne pas interférer les uns avec les autres.
Arrêtez d'écrire du code. En plus de deux exceptions: quand il définit un vecteur de développement ou définit une mode. Le premier comprend des solutions architecturales qui donnent le ton du développement et vous permettent de garder son vecteur dans la bonne direction. La seconde - ces choses qui arrêtent de tout faire si vous arrêtez de faire: tests, branches, bonnes pratiques et autres petites choses que tout le monde est trop paresseux pour faire, mais sans lesquelles tout s'écroule.
N'essayez pas de corriger toutes les erreurs visibles, de recommencer la vie à zéro ou d'introduire un processus à partir d'un livre. Les points de vue du développeur et du chef d'équipe sont considérablement différents, et ce qui vous semble nuisible en tant que développeur peut s'avérer être le clou sur lequel tout était suspendu. Apportez des modifications lentement et régulièrement. Prenez votre temps, vous en aurez.
Donnez et déléguez. Votre tâche n'est pas de tout faire vous-même, mais de vous assurer que la tâche est accomplie. De plus, l'un des facteurs de motivation très importants est la responsabilité. En mettant sa pièce entre de bonnes mains, vous serez non seulement moins occupé, mais aussi motivez un membre de votre équipe. Mais, si vous avez déjà donné, n'oubliez pas que vous avez non seulement donné la responsabilité, mais aussi délégué une partie du pouvoir de prendre des décisions.

Quels livres ou articles recommanderiez-vous de lire au responsable du développement? Et quelles ressources est-il judicieux d'étudier régulièrement?

À une époque, j'ai beaucoup aimé le travail d'Alistair Cockburn "Développement de logiciel agile". Je le recommande vivement. Je recommande fortement la pratique du travail avec les étudiants: vous préparez vos propres cadres + vous devez vous maintenir en bonne forme, car les étudiants pleins de dents ne vous laissent pas vous détendre, posant des questions délicates :)

Autant que nécessaire pour que le groupe puisse faire face aux tâches. Si une libération intervient dans une semaine, alors c'est étrange de s'occuper de la gestion, et si dans un mois l'une des filles part en congé de maternité, c'est étrange de faire des tâches techniques. Est-ce que tout cela s'est produit en même temps? , :) , , , IMHO .

. , . , , , :))
( , ). , , , .
: , . « 3 » — .
. , 1-2 , .

, , 28 2018 . .

Comment développer un gestionnaire de développement

Nikolay Krapivny , responsable du développement backend, Badoo

Roman Ivliev , CTO, mos.ru

Alexander Polomodov , directeur de la recherche et du développement, Tinkoff.ru

Boris Tobotras , directeur, Software Solutions Center, Jet Infosystems

Victor Lamburt , responsable des produits recommandés, Yandex

Igor Kuralenok , PDG, League of Experts

More articles: