Parfois, il semble que le timlid soit quelqu'un ou quelque chose comme Snark du poème de Lewis Carroll: il existe certainement, est polyvalent et contradictoire décrit dans ses manifestations quotidiennes et commerciales, mais pour autant c'est un mystère. Pour comprendre l'importance de ce rôle (chef d'équipe, pas Snark) dans les équipes d'ingénierie, qui est le mieux placé et quels pièges sont cachés dans le chef d'équipe,
Saint TeamLead Conf 2018 promet d'aider, qui se tiendra du 24 au 25 septembre à Saint-Pétersbourg .
Un mois avant l'événement, nous nous sommes entretenus sans aucune formalité avec le directeur technique du projet Mos.ru
Roman Ivliev , qui dirige le comité de programme de Saint TeamLead Conf 2018. Dans la conversation: qui sont les chefs d'équipe, comment les préparer correctement, qui et quoi préparer, ce qu'ils devraient être un cercle de leurs responsabilités et plus encore.
Aide
Roman Ivliev est né en 1982. En 2005, il est diplômé du département de cybernétique de l'Institut de génie physique de Moscou. Plus de 15 ans en informatique. Spécialisation: charges de travail élevées, gestion des équipes technologiques, formation.
Derniers lieux de travail:
• En 2009-2013, d'abord ingénieur senior, puis chef de projet chez Kaspersky Lab (il était responsable du support et du développement des sites d'entreprise - b2c et b2b).
• En 2014-2016 - Directeur des technologies de l'information Banki.ru
• Il a pris la position de CTO dans le projet Mos.ru fin 2016.- Depuis près de deux ans, vous êtes CTO dans le projet Mos.ru, et avant cela, vous avez travaillé pendant de nombreuses années principalement dans des organisations commerciales. Comment, selon votre expérience, est-ce que vous travaillez en tant que directeur technique dans une structure gouvernementale différente de celle occupant le même poste dans les affaires?- Du point de vue des processus de production, considérez qu'il n'y a pas de différence significative. Le système de définition des tâches n'est pas très différent de celui adopté dans les bureaux commerciaux. La différence d'échelle: généralement un projet gouvernemental est un énorme mécanisme. De nombreuses personnes sont impliquées dans son travail, qui ont le droit de prendre et de prendre des décisions. À titre de comparaison: si dans Banki.ru nous avons sculpté quelque cinq projets internes, alors dans Mos.ru, une vingtaine de personnes peuvent être impliquées dans un projet comparable. Dans une organisation gouvernementale, le service informatique est un peu plus difficile en termes de construction de communications externes: il arrive que vous essayiez d'attraper la bonne personne pendant une demi-journée - tout simplement parce que le personnel est important. Mais avec ceux avec qui vous avez besoin d'interagir régulièrement, y compris par l'intégration de services, nous sommes sur une courte distance: nous avons fait connaissance.
Dans tous les coins du Département des technologies de l'information de Moscou (DIT) et d'autres structures avec lesquelles nous devons interagir, nos propres règles du jeu et nos problèmes, comme dans toute grande organisation, au moins dans le même Sbertekh. Notre Mos.ru n'est pas très différent des services b2c du marché - sauf que nous ne faisons pas d'argent.
Bien sûr, nous dépendons toujours de la loi. Et si nous traduisons un certain service sous forme électronique ou publions un nouveau service, alors seulement s'il existe un cadre réglementaire approprié. Disons pour égaliser les droits de ceux qui enregistrent chez le dentiste sur Internet et via le registre. Au sein du département, ce n'est pas notre domaine de responsabilité. Parfois, nous avons reporté la libération en raison de circonstances similaires, que nous n'avons pas pu influencer. Bien que l'entreprise soit maintenant dans le même pétrin.
- Qu'est-ce qui se cache derrière la façade de Mos.ru?- Mos.ru est la porte. Un portail qui regroupe tout un tas de services. Sous lui, il y a une salle de rédaction qui écrit sur les événements dans la ville et tient une affiche. Il y a des sections que nous sommes tenus d'avoir conformément à la loi, par exemple, contenant des informations sur les actes juridiques réglementaires et la structure du gouvernement. Ces parties de la ressource sont également remplies par des personnes spécialement formées. Nous les préparons à la mécanique de la gestion de contenu, ils l'utilisent.
Toujours dans notre domaine de responsabilité sont les projets spéciaux numériques. De frais - fait cela pour le parc Zaryadye.
Nous avons, relativement parlant, une équipe de cycle complet. Nous prenons quelque chose de côté, bien que rarement. D'autres services qui vivent dans le domaine
www.mos.ru , mais qui n'ont pas été développés par nous, mais par d'autres divisions de DIT, sont disponibles sur le site en raison des intégrations internes. Nous les cachons à l'utilisateur pour que toute transition au sein du portail soit transparente pour lui. Assis sur Mos.ru, vous pouvez facilement être dans un autre système, cependant, si vous n'entrez pas dans le code de la page, vous ne remarquerez rien.
Les mêmes
services du gouvernement de la ville (accessibles sur notre site Web) font partie d'une équipe distincte. Leurs services, à leur tour, sont limités aux systèmes informatiques spécifiques à l'industrie: soins de santé, social, etc.
- Dans quelle mesure une grande équipe est-elle impliquée dans le support technique du portail sous votre supervision?- Vingt personnes en développement. Avec une dizaine de tests, dont ceux impliqués dans l'automatisation. Ajoutez ici l'équipe d'exploitation et DevOps. Au total, jusqu'à cinquante, le nombre et la composition exacts dépendent des circonstances et de la charge actuelles.
- Comment se construit votre hiérarchie de gestion technique? Comment sont répartis les domaines de responsabilité?- Nous avons trois domaines principaux: développement, test, opération. Le fonctionnement, à son tour, est divisé en fonctionnement propre et DevOps. De plus, ceux qui interagissent avec les centres de données et ceux qui sont engagés dans l'automatisation sont distingués, mais ils ont de nombreuses tâches communes, donc je ne les élève pas dans différents camps.
Les tests sont mis en œuvre selon le schéma «testing as a service». Il y a un groupe de testeurs et son patron. Ils sont nominalement attachés aux équipes, mais en fait ne sont pas leurs membres. Si nécessaire, nous transférons les testeurs de tâche en tâche: ces gars sont interfonctionnels. L'exception est mobile. Nous avons envoyé des personnes spéciales pour tester les applications mobiles et essayer de ne pas les tirer pour rien: leur travail a une spécificité prononcée.
Nous avons également DevOps en tant que service: les tâches sont définies, hiérarchisées, puis exécutées à travers les devops, qui ne sont pas non plus étroitement fixées pour certaines équipes. De même, l'opération fonctionne.
Mais le développement est divisé en équipes dans des domaines fonctionnels. Nous avons deux types d'équipes. Le premier est hautement spécialisé. En particulier, celui qui fait la recherche. Il ne touche pas le frontend et l'interface graphique: seulement le backend. Scier leurs propres algorithmes, explorer le machine learning, faire des sorciers, des astuces, des statistiques, des analyseurs, une correction de faute de frappe. Ils sont assis sur leur pile technologique et se connectent à Mos.ru via l'API. Le service de recherche est connecté à n'importe quelle partie du portail. Une équipe distincte a atterri dans le sens des applications mobiles. Elle a son propre backend.
Ces deux équipes interagissent avec le «développement principal» de DevOps, les tests et l'exploitation.
Le deuxième type de commandes sont celles qui créent et prennent en charge des modules Mos.ru distincts, y compris l'interface graphique. Il y en a généralement cinq dans chacun, avec un maximum de six employés, selon la direction. Dans ces mini-groupes, il y a une division claire entre front-end et back-end: dans notre cas, il s'est avéré efficace. La plupart des backenders sont des développeurs full stack, mais je ne les fais pas tourner sur deux pistes de danse à la fois. Chacune de ces équipes a un chef d'équipe.
- Donc, ce mot a retenti. Et que fait un tel Timlid?- Tout d'abord, il est stratège dans son secteur du front - il veille au respect des règles du jeu que nous avons établies. Sur elle - entre autres - la décomposition des tâches, la révision du code, l'organisation rétrospective, l'éducation des novices.
Traduit dans les rangs militaires, c'est quelqu'un comme un sergent - le chef d'escouade. Il est habilité et a le droit de prendre des décisions dans le cadre de ces solutions et normes technologiques que nous avons adoptées conjointement.
De plus, les membres de mon équipe font partie de l'équipe d'architecture. Ce n'est pas une structure formalisée et pas toujours opérationnelle: elle survient lorsque le besoin est mûr de proposer quelque chose de nouveau en termes de technologie. Ensuite, tous les chefs d'équipe, les chefs des services d'essais et d'exploitation et tous les autres qui sont extrêmement intéressés par les changements vont me rencontrer. Des spécialistes aux compétences différentes, aux points de vue différents sur le paysage technologique, aux postes différents, s'assoient en cercle. Ils discutent de questions controversées, fixent des accords, proposent une architecture ou une solution - et ne sont pas d'accord.
Jusqu'à récemment, à Banki.ru et à Mos.ru, exclusivement des «dos» étaient exclus de mes coéquipiers. En règle générale, un développeur principal principal a assumé ce rôle. Mais pour le moment, j'ai déjà deux chefs d'équipe du frontend.
Tout change. Nous avons dû nous adapter aux réalités technologiques actuelles et, par conséquent, nous avons obtenu ce que nous appelons des guildes.
Voici la chose: il est difficile pour le leader de garder une trace de ce qui se passe dans le monde du backend en 2018, et vice versa. Nous avons réalisé que les gens doivent coopérer à un niveau horizontal, s'impliquer dans des associations informelles sans subordination directe, mais avec des statuts - comme les rangs dans les sociétés secrètes, quelque chose comme un «maître de l'ordre back-end». Les porteurs de tels «titres» sont des personnes qui prennent de facto des décisions managériales de nature appliquée: allons-nous passer à PHP 7.2, Angular se développer, ou est-il préférable de parier sur React.
Les guildes se réunissent régulièrement - front-end séparé, back-end séparé. Ils se réunissent et découvrent qui est bon et qui est mauvais, ce qui est à la mode et cool maintenant. Ils se demandent si Webpack est vraiment un chapeau terne qui recueille un tas de tout ce qui n'est pas nécessaire, ou s'il suffit d'apprendre à le gérer. Ils ne débordent tout simplement pas de vide à vide, mais ils finissent par trouver une solution pratique.
Finalement, l'équipe d'architectes remplace mon architecte système. Oui, je n'ai pas d'architecte système.
- Quelle place le chef d'équipe occupe-t-il dans votre équipe? Relève-t-il directement du CTO ou existe-t-il des gestionnaires de niveau intermédiaire?- Nous n'avons pas de niveau intermédiaire - il en est ainsi. Par la logique des choses, entre les chefs d'équipe et moi, il devrait y avoir un responsable du développement. En fait, il y a des patrons dans les départements de test et d'exploitation, et je gère personnellement le développement. Par conséquent, les Timlids relèvent directement de moi.
Un peu plus compliqué est le schéma de soumission des devops. Au départ, j'allais également les séparer en un groupe séparé avec mon patron, mais les gars et moi avons réfléchi et décidé qu'il s'agissait d'un lien de gestion supplémentaire. Ils ont fait appel à DevOps au lieu du patron Kanban, c'est pourquoi ils sont extrêmement satisfaits.
- Quand avez-vous rencontré pour la première fois une telle entité en tant que chef d'équipe en développement? Quand mon expérience personnelle a-t-elle été convaincue que cette fonctionnalité est utile?- En 2008, mes collègues et moi avons écrit des logiciels astucieux dans une usine de défense. Une fois que nous avons enterré le nez sur le fait que c'était offensivement simple: une équipe de dix développeurs n'est pas capable de produire quoi que ce soit, mais est seulement capable d'arnaquer et de jurer. Puis, pour la première fois de ma vie, l'expression «chef de groupe» est apparue - une sorte de prototype de chef d'équipe.
L'équipe d'ingénieurs était divisée en deux, ayant affecté une personne responsable à chacun des deux groupes. J'étais l'un d'eux. Le chef d'un autre groupe et moi avons commencé à construire des processus de développement interne et à déboguer l'interaction entre les moitiés de notre mini-équipe. Ensemble, nous avons transformé le collectif «de type troupeau» en deux unités de combat efficaces. Ils ont commencé à répartir les tâches entre eux et à hiérarchiser ces mêmes tâches, à planifier sur des périodes plus longues et, au final, à synchroniser le travail des équipes afin d'éviter les temps d'arrêt.
À Banki.ru, la structure du service technique était également «cellulaire»: les équipes qui y étaient étaient contrôlées par des chefs d'équipe, et la plupart du temps avec cinq d'entre eux, j'ai contacté directement, en l'absence d'un responsable du développement. Comme maintenant sur Mos.ru.
Auparavant, chez Kaspersky Lab, où j'étais responsable du travail des sites d'entreprise, plusieurs équipes opéraient sous ma direction - multidisciplinaire, avec différentes empilements technologiques. Alors là, j'aurais été blessé par mon esprit sans les Timlids - les chefs des groupes qui m'ont sauvé des tourments associés à la construction d'un panorama technologique dans tous les détails. J'ai interagi avec eux au niveau de l'idéologie et de la coordination globale des processus. Et la construction des règles du jeu - comment procéder à une révision du code, que ce soit pour aider les plus jeunes, pour tromper les anciens, etc. - est restée dans leur conscience.
Et encore la même chose: avec qui d'autre les Timlids se comparaient-ils, sinon avec des sergents? Aux États-Unis, toute l'armée s'y accroche. Je ne peux pas non plus vivre sans mes «sergents». Au contraire, je peux, mais avec douleur et à travers une souche. Ce sont mes yeux, mes oreilles, mes mains. Ils sont les premiers à transmettre mes souhaits, suggestions et instructions "aux masses" et à veiller à ce que tout cela soit mis en œuvre.
- Selon vous, un chef d'équipe est-il plutôt un métier ou un rôle situationnel dans l'organisation, par analogie avec le Scrum Master?- J'ai maintenant les deux dans l'équipe. C’est une chose lorsque les tâches d’une équipe sont fondamentalement les mêmes et que les gens se déplacent à un rythme unique. Un autre est lorsque, dans une équipe, n problèmes sont résolus en parallèle, où n peut dépasser le nombre d'ingénieurs dans une équipe. Dans le second cas, le chef d'équipe a toutes les chances de se transformer, même temporairement, en un administrateur naturel, qui "acheminera" ces tâches. Pour moi, c'est à la fois un rôle et une profession.
De plus, le marché continue de se demander qui est l'oiseau timide en principe et quelles sont ses fonctions de base. Tout le monde trouve une configuration qui lui convient le mieux. Le plus souvent, ils proviennent même des tâches qu'il est nécessaire et approprié de résoudre dans une équipe particulière. Par exemple, chez Banki.ru, j'ai délégué la sélection du personnel à mes chefs d'équipe: ils étaient suffisamment «éclairés» pour poser les bonnes questions lors de l'entretien, non seulement pour déterminer les qualifications du candidat, mais aussi pour tester ses compétences générales. Peu à peu, les gars ont pompé et sont passés de chefs techniques ordinaires du rang initial à des unités des niveaux suivants. Chez Mos.ru, nous sommes progressivement arrivés au même système. Les gars étudient eux-mêmes le CV, regardent les candidats, conduisent des entretiens techniques. J'assiste souvent à cette étape en tant que spectateur.
Est-ce que timlid existe en tant que profession, la question est le remblayage. Le chef d'équipe est-il une profession? Absolument. Ce n'est qu'en science des fusées qu'il en existe un, et en programmant un autre, du point de vue des fonctions exercées par son représentant et de l'éventail des tâches qu'il accomplit. Dans l'entreprise, où cinq personnes sont en développement, une. Au bureau pour 250 employés - un autre.
Même chose avec le Scrum Master. Personne ne le dérange d'être un back-end, un front-end, un testeur ou même un rédacteur technique. L'essentiel est la capacité de rassembler les gens, de les mettre sur la bonne voie et de s'organiser, de réduire l'entropie autant que possible et d'encourager les collègues à se déplacer dans un seul rythme et dans une seule direction.
- Voyons votre monde parfait. Lorsqu'une équipe comprend un chef de produit, un chef de projet et tout-tout, où est la responsabilité du chef d'équipe? Timlid gravite-t-il vers la «conception» plutôt que la «productivité»?"Il est plus proche du design, oui." Mais les affaires sont les affaires et les processus d'ingénierie internes sont des processus d'ingénierie internes. Tout ce qui compte, c'est que son principal domaine de responsabilité est l'organisation du travail dans la «cellule de la société», qui produit le produit final.
Plus précisément, le chef d'équipe a deux points de focalisation. Le premier est l'organisation même du travail dans le micro-collectif, de la collecte des données d'entrée à la livraison du résultat. La seconde est la mise à disposition d'interactions sociales au sein de l'équipe et l'établissement de sa connexion avec la plus haute direction informatique. S'il y a un biais clair dans une direction ou une autre, ce sont des déchets.
- Qu'est-ce que le Timlid doit contrôler?- Tout d'abord, il cherche à s'assurer que les règles du jeu adoptées au niveau de l'entreprise, des unités, des groupes de salariés soient respectées dans sa clairière. Il existe des règles pour produire un code, maintenir la documentation, organiser des événements généraux - ce qui signifie que tout le monde doit les suivre.
Deuxièmement, il fournit des conseils techniques: il est responsable de la décomposition des tâches, de leur mise en œuvre dans le développement dans le but de rendre leur mise en œuvre aussi simple et compréhensible que possible, et de surveiller effectivement leur mise en œuvre. Il rejoint la fonction sous-estimée et extrêmement importante du chef d'équipe - pour assurer l'exhaustivité des données d'entrée pour l'équipe. J'ai ces gars qui se tiennent à l'entrée de leur mini-groupe comme filtre: si une équipe obtient une connerie explicite au lieu de savoirs traditionnels, son chef d'équipe insiste sur le projet ou le produit jusqu'à ce qu'il formule les bonnes exigences.
Si nécessaire, l'équipe dirige des ressources d'exploitation, telles que l'accès au réseau. Et bien sûr, il comprend comment cette partie du système dans laquelle ses coéquipiers sont impliqués est structurée, y compris pour lui, le fonctionnement de l'intégration est clair. Sinon, il ne pourra pas formuler correctement au nom de son équipe les tâches des services d'essais et d'exploitation.
Troisièmement, un tel chef de file en cas d’échecs de toute nature, auxquels il ne peut pas faire face lui-même, les signale immédiatement et les porte à l’attention des personnes capables de résoudre le problème. Si l'équipe n'a pas le temps, lui, l'ayant à peine découvert, fait un pas vers son patron, et sans désolation avoue: «Nous n'avons pas le temps, car nous sommes« sous-estimés »», et lui propose des solutions.
À Mos.ru, l'échantillon de 2018, le chef d'équipe est chargé de veiller à ce que les tâches reçues par l'équipe soient clôturées à temps, dans les limites du budget spécifié, avec la composition actuelle des spécialistes. C'est l'idéal. Quelque chose échoue - il met immédiatement en évidence un problème qu'il n'est pas en mesure de gérer avec ses ressources disponibles, et le «serre» jusqu'à ce qu'il soit résolu au sein de l'équipe ou un ou deux niveaux plus haut. Au moins, il ne laisse pas le processus problématique seul.
Ainsi, le chef d'équipe est un directeur technique à part entière, pas une sorte d'appendice de la catégorie «que ce soit».
- Quelles autres responsabilités peuvent - ou devraient - être confiées aux soins d'un Timlid?- Les Timlids remplissent une autre partie de leurs fonctions assez souvent, selon les circonstances, ils leur accordent plus ou moins d'attention de la part de l'organisation. Par exemple, un ajustement de la méthodologie de développement: vous, en tant que chef d'équipe, voyez mieux si la méthodologie choisie pour tout le monde convient spécifiquement à votre site. Il s'avère souvent que non. Imaginez que tout le monde scie une interface graphique et que vous êtes un composant de service. Évidemment, vos processus ne sont pas du tout les mêmes que ceux de vos voisins.
, «» : , , - «- ». HR-. , , , . . HR- .
, . , - . .
. - , , , . : , . , : «- , - ».
, — , , — . . , Mos.ru . , . - , . , «» , , , : , . , : , , .
— «», ?— , - . , . . — , , - . , code review, - , . , (, ). , Vue.js, PostgreSQL 10 «» . , , -, .
, . , , : , Sphinx Avito. .
, , — - , . . , , , .
- , . , , , .
— , ? , back-end front-end .— . , , , «», . «» , , , .
— — , — ? , ? «»?— , . . - , - — . . , , , . , IT — , . . : , .
CTO . — , ? , « — — » — , , , ? .
— , , , ?— , . , - . — . , . .
, , . . , : « PHP, Go, - -». , , .
, «», : , , .
. - , . - « ». , , .
— . . — . HR-. , . , ? , , . , , — - .
— . , . — .
, soft skills, , , , . , ? , . : .
— «» «-». , , . , ? ?— , . — — . , : « ». , . , — . .
Saint TeamLead Conf : , «», «».
, — — . , , , : « , — ». : , .
, , : : « , , — - ».
— ? ?— , , soft skills. , , , , , .
, , , , , . — , , .
— , , , ? ?— - . , . 7±2, , , , , ( ). -, — -.
— , ? ?— : , .
:
• . , , , , , .
• , , , , , , .
• , , .
— , IT , ?- Non! . , «» IT-. , , : , «» .
TeamLead Conf, , «», , , , — , , — .
, , . , Mos.ru , . : . Banki.ru , , , , ; - .
— . , , , , review. .
, Saint TeamLead Conf, — . , , , , , .
— , TeamLead Conf , , ? ?— , , , - . , .
— , .
— IT , «» ? ?— . . , - - . , . - .
— ? « », , - ?— . , - : , , , IT-, . , « », .
«» —
HighLoad++ , ++, «» — Whale Rider Aletheia Business. « »: , , , .
, Saint TeamLead Conf . , ?
Le matériel de la TeamLead Conf du printemps a été entièrement publié sur notre chaîne YouTube . Il y aura également une vidéo de la nouvelle conférence, mais dans quelques mois. Abonnez-vous si vous ne voulez pas manquer.
Toutes nos actualités autour de la gestion et de l'entrepreneuriat, nous les collectons dans la newsletter. Il comprend: la publication d'articles et de transcriptions, des vidéos ouvertes, des conférenciers sympas et d'autres utilités. Si vous êtes intéressé, inscrivez-vous .