Bonjour à tous! Je m'appelle Alexander Afenov. Je suis le chef d'équipe de l'équipe de traitement des commandes Lamoda. L'année dernière, j'ai parlé à TeamLead Conf 2018. L'enregistrement de la performance est disponible ici .

Dans mon rapport, je raconterai comment je suis devenu chef d'équipe, quels problèmes j'ai rencontrés et je partagerai différentes stratégies qui peuvent vous sembler familières individuellement. Cependant, je me concentre sur le type de profit qu'ils procurent dans le complexe.



Le rapport sera divisé en 3 parties:

1. Dans la première partie, nous parlerons un peu de l'entreprise et des fonctionnalités de notre informatique. Cela est nécessaire pour comprendre le contexte dans lequel tout se passe.
2. Dans la seconde, je parlerai de mon parcours dans l'entreprise.
3. Dans le troisième - sur les méthodes utilisées, leurs avantages et leurs inconvénients.

Lamoda en tant que société informatique

Lamoda est principalement connu comme un important détaillant de vêtements, chaussures et accessoires à la mode en Russie et dans la CEI. Cependant, peu de gens savent que pour un pourcentage ou un montant fixe, nous fournissons des services à différentes entreprises / entités juridiques.

Permettez-moi de vous donner un bon exemple. Disons que vous avez un sous-sol pour coudre des sacs à main. Vous avez créé un site Web pour vos produits et l'avez promu avec succès. Maintenant, beaucoup de gens vous connaissent, mais malgré cela, vous avez des problèmes de livraison, de stockage et de communication avec les clients.

Lamoda peut résoudre ces problèmes des manières suivantes:

1. Fournissez les services de votre service de livraison.
   
   LM Express est notre propre service de livraison, que nous développons et automatisons nous-mêmes depuis longtemps.
2. Assurer la communication avec le client. Pour ce faire, nous avons notre propre centre d'appels.
3. Gardez les marchandises à la maison ou même vendez-les pour vous (commission).
4. Marché. Les produits des partenaires peuvent être affichés dans notre application mobile, sur le site ou sa version mobile, et les partenaires font le reste eux-mêmes.

La question se pose: «Comment parvenez-vous à résoudre vos problèmes et à satisfaire les besoins des partenaires?» Nous avons une entreprise en évolution et en développement avec nos propres besoins. Nous nous améliorons, nous développons et allons de l'avant. Dans le même temps, vous devez toujours faire correspondre les listes de souhaits qui viennent de l'extérieur. Il semble que cela nécessite sa propre informatique, et non une petite.

Nous parlons de développement interne à toutes les conférences depuis 2016. Nous automatisons nous-mêmes tous les processus. Il s'agit d'une centaine de services différents: du traitement des commandes et des paiements à l'utilisation des objets d'adresse et des chèques-cadeaux. Le soutien à tout cela est une équipe d'environ 300 personnes.

Pourquoi je parle de notre informatique et de sa portée? Parce que 300 personnes, c'est beaucoup d'équipes. Lorsque certaines équipes travaillent sur une seule pile technologique, nous essayons de réutiliser tous ces développements. Il peut s'agir de bundles, de bibliothèques, de pratiques dans le domaine technique. Mais nous essayons également de tâtonner les pratiques de processus réussies entre les chefs d'équipe, et j'en parlerai plus tard.

Problèmes clés

J'ai rejoint l'entreprise en 2015. Trois jours après mon emploi, une fête d'entreprise du Nouvel An était prévue, à laquelle j'ai décidé de ne pas aller. Ma priorité était de rester et de réfléchir à mes tâches pendant une période d'essai.

L'événement d'entreprise à Lamoda est une fête à thème pour laquelle tout le monde aime se préparer. Par conséquent, le jour X, l'architecte de mon département est venu travailler au défilé, en habit. À cette époque, notre équipe était engagée dans les services de traitement des commandes. C'était un monolithe sur l'ancien framework Zend1 . Qu'est-ce que j'ai observé? Les gars ont préparé une libération forcée et voulaient réparer quelque chose. Après nous être assurés que tout allait bien, nous avons fait nos valises et sommes partis pour les vacances.

Et me voilà assis. La sortie est entrée en production avec un correctif, et devant moi se trouve un beau téléviseur de 50 pouces avec une sorte de tableau de bord. Sur le tableau de bord, un graphique indiquait «Rabbit MQ problems». Il semble que s'il y a des données dessus, alors quelque chose s'est cassé. Mais je ne sais pas où chercher pour tester cette hypothèse.

Vous pouvez probablement consulter une sorte de journaux. Cependant, je ne suis que le troisième jour au travail et je ne sais pas où ils se trouvent. Je suppose que je peux trouver un lien vers le tableau Grafana. Peut-être qu'il vaut la peine de regarder à travers elle la source des métriques et d'y creuser? Oui, mais c'est trop cahoteux. J'aimerais que cela soit documenté d'une manière ou d'une autre. Et encore une fois, il y a la question: qui sont tous ces gens qui sont assis? Deux ou trois étages sur lesquels l'informatique est distribuée. Tout le monde fait quelque chose et je ne sais pas avec qui communiquer avec moi en cas de problème. Il n'y a pas de tableau croisé dynamique qui soit clair qui je pourrais contacter si je me suis rendu compte que la version est cassée. Ou peut-être qu'il y a une personne de service, mais je ne suis tout simplement pas au courant?
* (bien sûr qu'il l'était) *

Il y avait d'autres questions. La première et la plus ridicule à laquelle nous reviendrons à plusieurs reprises: «Où est la documentation?». La réponse est simple: simultanément partout, n'importe où et dans l'esprit des employés expérimentés. Depuis que tout le monde est parti pour la fête d'entreprise, mais je ne sais pas où sont les quais, la réponse ne me semblait "nulle part". J'avais un fichier Lisez-moi sur lequel j'ai déployé le projet sur mon ordinateur portable. Mais cela ne suffisait pas. Je voulais obtenir des réponses à de nombreuses autres questions. Par exemple, quelles sont les règles de «comportement» de base pour un développeur?

Je m'explique: j'ai décidé de demander l'accès au système de combat pour entrer dans l'interface utilisateur. Ce serait très utile pour moi, car ma tâche pendant la période d'essai était de retravailler le système d'autorisation, et je voulais pousser des boutons, me connecter au stand de production. J'ai adressé une demande au service de sécurité, à laquelle j'ai rapidement reçu une réponse succincte: "Non, nous ne donnerons pas accès." Il s'est avéré que seuls les vrais utilisateurs ont accès au système de combat: les employés d'entrepôt, un centre d'appels, etc. Comme j'avais auparavant travaillé dans les télécommunications, je me suis habitué au fait que j'avais accès en lecture et en écriture aux bases de production de différents opérateurs mobiles. Et ici, il s'avère que c'est impossible. Il y a un protocole.

De plus, j'ai rencontré de nombreuses autres conditions et restrictions dont le chef d'équipe m'a parlé. Au début, il m'a consacré à de nombreux moments fascinants différents. Il y avait tellement de ces informations que tout ne pouvait pas être mémorisé et écrit.

Les questions suivantes qui m'intéressent concernent une perspective à long terme. Par exemple, comment et où grandir?

Pourquoi est-ce important? Parce que depuis le début, je dois me comporter d'une manière ou d'une autre. Je suis arrivé au poste de développeur PHP moyen. Que dois-je faire ensuite pour dépasser les attentes, et à l'avenir pour obtenir un grade plus élevé, par exemple Senior? Et encore une question: "Qu'attend-on de moi dans mon grade actuel?" C'est-à-dire, combien dois-je être impliqué dans des processus tels que la révision du code, les versions, le devoir?

Toutes les questions que j'ai énumérées maintenant ont été répondues par notre chef d'équipe. Les deux derniers, plus stratégiques, ont reçu une réponse par le biais du système d'évaluation des performances. Je vais vous en dire plus.

Examen des performances

Tous les 6 mois, une personne procède à une soi-disant auto-évaluation. Il parle des choses cool qu'il a réussi à faire dans le temps imparti. Cependant, il y a un piège. Cela est lié au fait que les gens indiquent généralement ces réalisations sur l'auto-évaluation, qu'ils sont subjectivement enclins à considérer comme tels. Penser en termes d'affaires est inhabituel, et même si le projet de routine permettait à l'entreprise de gagner une tonne d'argent, alors pour le développeur, il pourrait ne pas être un défi ou un intérêt. Il y a un risque que, dans un tel examen, ce projet ne soit pas indiqué.

La prochaine étape est un examen par les pairs. Elle est suivie d'une série de commissions sur lesquelles il y a une communication entre les chefs d'équipe, les chefs de service, les stations-service et, si nécessaire, le directeur RH. Puis un message sur les résultats.

Quels sont les résultats possibles?

Première option: une personne a réussi à empirer en six mois qu'avant le début du travail. Il semble temps de dire au revoir. Cela se produit extrêmement rarement, mais nous serons réalistes - cela arrive.

Une autre option est un diable. Quelque chose semble manquer. Il peut y avoir vitesse, prévisibilité, persévérance. Quelque chose doit être amélioré.

Trois - ce à quoi ils s'attendaient, ils l'ont compris. Une personne travaille à un rythme adéquat et correspond à tous égards à son grade.

Quatre - a fait plus que convenu. Candidat à la promotion / au salaire.

Loup à cinq laine. Il semble qu'il est temps d'augmenter, de donner des bonus, etc.

J'ai parcouru plusieurs itérations d'une telle revue moi-même. Auparavant, elle se tenait tous les trimestres, ce qui n'était pas très pratique, car depuis 3 mois la possibilité de faire ses preuves ne se fait pas toujours. Maintenant, l'examen a lieu tous les six mois.

Donc, au début, j'ai grandi de développeur senior à senior. Ensuite, mon chef d'équipe a décidé que maintenant il voulait travailler davantage avec la technologie et est passé au poste d'équipe technique (architecte), et je suis devenu chef d'équipe.

Et maintenant? Je dois faire quelque chose, en quelque sorte maîtriser.

La première chose que vous rencontrez est les mêmes questions dont nous avons parlé auparavant, mais maintenant à un niveau légèrement différent. Autrement dit, ce n'est toujours pas clair: où est cette documentation? Maintenant, je dois en quelque sorte communiquer avec d'autres départements, communiquer avec d'autres prospects, architectes et quelqu'un d'autre, penser à un niveau supérieur. Mais à ce niveau même de documentation, probablement pas non plus.

Un autre point concerne les mêmes «règles de base». Que puis-je faire

Je suppose que je peux suivre les tâches, faire une revue de code. Peut-être que j'ai maintenant le pouvoir de changer les processus, de communiquer d'une manière ou d'une autre avec les gens.

Comment et où grandir? Cette question ne disparaît pas, car alors vous voudrez peut-être devenir le chef du département (chef de groupe).

Eh bien, la question - ce qu'on attend de moi, me semble également tout à fait compréhensible.

Et maintenant, vous devez être en mesure de répondre à toutes ces questions non seulement à vous-même, mais à toute l'équipe. Dans mon cas, l'équipe a été recrutée presque à partir de zéro. Il s'avère que pour cinq ou sept personnes, je dois tout dire, expliquer, fixer des objectifs. Cela prend du temps et des efforts. De telles choses doivent être planifiées et réfléchies. Quelle est donc la responsabilité du chef d'équipe?

Que doit diriger une équipe?

Tout d'abord, c'est le travail avec les tâches : leur formulation, ajustement, description de la personne qui reçoit la tâche sous le grade. Par exemple, pour un junior, je préférerais faire une description très détaillée et m'attendre à ce qu'il écrive le code et les tests corrects. En tant que senior, je communiquerai un objectif technique ou commercial, et il sera libre de décider lui-même comment l'atteindre. En tout cas, tout cela prend du temps.

Bien sûr, vous devez effectuer une révision du code lorsque des conflits surviennent. Surveillez ce qui se passe, déplacez les tâches par statut. J'exécute également les fonctions d'un ingénieur de libération sur une base régulière. Vous devez souvent réfléchir à la façon dont notre déploiement affecte tout le monde. Le service que je fais est le traitement des commandes. Il est associé à presque tous les systèmes Lamoda et, par conséquent, est capable d'affecter de nombreux processus métier lors de sa sortie.

Un autre point est la surveillance, les alertes et les décalages qui y sont associés. Si une fonctionnalité métier est apparue, il est nécessaire de la surveiller, d'introduire de nouvelles mesures, de raccrocher les notifications, d'informer le service d'assistance, etc. Ce sont tous des problèmes architecturaux. Je n'ai pas d'architecte dédié dans mon département en ce moment. J'exécute ses fonctions dans les cas où vous avez besoin d'une solution spécifique dans le cadre d'une tâche / d'un projet spécifique.

Encore faut-il prêter attention aux communications . Cela comprend des réunions personnelles qui ont lieu environ toutes les deux semaines avec chaque développeur; rétrospectives, planification, communications avec les gestionnaires et les autres services. Mais ce serait quand même bien de ne pas commettre de faute.

Beaucoup disent qu'il serait formidable, après 10 ans de développement, d'obtenir un ratio «gestion par développement» d'environ 80 à 20. Même cela n'est pas toujours réalisable. En conséquence, vous perdrez inévitablement de l'expertise et tomberez des tendances actuelles. Il faut continuer de croître davantage.

Il existe des stratégies possibles pour progresser en fonction de votre position. Dans la section suivante, nous parlerons de la façon dont la rotation des rôles dans une équipe contribue à augmenter le facteur bus.

Rotation des rôles

Je mettrai à jour ceux qui ne connaissent pas et je vous dirai quel est le facteur bus.

Le facteur de bus est un nombre qui indique que si un certain nombre de développeurs «heurte un bus», alors le travail sur le projet s'arrêtera. Il peut se manifester à différents niveaux. Par exemple, il peut s'agir d'un facteur de bus pour un élément de système complexe spécifique.

Supposons que nous ayons un cas dans lequel nous devons trier un certain système de rapport. Le développeur a mis 5 jours à le faire. Le bug était compliqué, mais il était corrigé, et tout allait bien. Puis un autre problème se pose dans le même module, et le même développeur se retrouve en arrêt maladie. Cela signifie que la personne suivante devrait passer le même temps à régler le problème. Vous devrez le comprendre à partir de zéro, car il n'y a pas de documentation (haha).

Ce qui sera discuté plus loin est précisément les stratégies pour augmenter le facteur de bus. Et ils se réuniront dans une image, plutôt agréable, avec toutes les fonctions précédentes du chef d'équipe, dont j'ai parlé.

En plus de la documentation, une véritable expérience est nécessaire. Autrement dit, vous avez besoin d'une équipe qui a déjà réussi à toucher différentes parties du système et est maintenant prête à faire face à toutes les tâches. Mais si l'équipe vient de se réunir, alors tout cela ne viendra pas de nulle part. Mon objectif principal est de dire comment il est possible de combiner plusieurs approches différentes qui permettront de résoudre des problèmes à la fois avec la documentation et l'expérience.

Ingénieur Support

Tout le monde a entendu parler des développeurs virtuels. Mais nous ne parlerons pas de kits VR et non de personnes sur un site distant, mais du rôle d'un ingénieur support.

Qu'est-ce qu'un ingénieur support?

Nous avons un gars qui analyse un arriéré de support. Il est venu travailler, il n'a pas une seule tâche. Il a ouvert un backlog pour le support dans le tracker de tâches (Jira), et là les tâches triées par criticité. Il a pris le plus important et commence à réparer. Une fois tous les problèmes résolus, il écrit pourquoi il s'est cassé et comment l'éviter à l'avenir. S'il n'a pas d'autre support (c'est drôle, car le support ne s'arrête jamais), alors il regarde l'arriéré technique, qui est déjà assez important.

Une petite distraction: nous parlons d'un système d'une centaine de milliers de lignes sur l'ancien framework Zend 1 . L'architecte de l'équipe précédente a dit un jour que selon notre système, nous avons une dette de cette taille - ce n'est pas une dette technique, mais plutôt une hypothèque technique. D'où le titre du rapport.

S'il n'y a rien à faire, l'ingénieur de support peut prendre une tâche non prioritaire à partir de là, ce qui n'est pas dommage de quitter et de revenir au support nouvellement apparu. Cela se produit généralement. Et il ne le fait pas plus d'une semaine, car ce serait un chemin direct vers la frustration. Si, pendant toute la période de deux semaines, vous ne faites que ratisser le support, cela vous démotivera grandement. Vous réparez, réparez, réparez et il n'y a pas de fin. Pour cette raison, nous transférons chaque semaine le rôle d'un ingénieur support à la personne suivante.

Ingénieur Release

Il existe un autre poste virtuel qui est très pratique pour décharger le chef d'équipe - il s'agit d'un ingénieur de publication. Il prépare les versions pour les versions de correctifs pré-planifiées, collecte les branches, prépare les builds, exécute tous les tests. Si les tests s'exécutent automatiquement, il contrôle simplement le résultat. Dans son domaine de responsabilité, choisissez à quel point il est beau de rouler sans temps d'arrêt et sans effets spéciaux pour les systèmes qui dépendent de nous.

Il arrive que nous ayons besoin de communiquer avec d'autres équipes avant le déploiement afin de les avertir des changements. En conséquence, l'ingénieur de publication déploie tout et cherche à voir si quelque chose s'est effondré. Nous utilisons pour cela, Sentry , Prométhée , Icinga , regardez Elastic, en utilisant Kibana . L'ingénieur de version décide quoi faire en cas de problème. Autrement dit, il est de sa responsabilité de décider si une sorte de correctif est nécessaire, ou si nous nous sommes tous cassés, perdons de l'argent et devons faire un retour en arrière. La décision de revenir en arrière n'est prise qu'en dernier recours, mais cela se produit également.

Il (ingénieur de publication) enregistre les problèmes qui surviennent. Si quelque chose se déchirait, ce serait formidable d'apprendre de vos erreurs. Pour ce faire, il indique la date de sortie et les erreurs qui ont provoqué le problème. Cela permet à l'ingénieur de la prochaine version d'examiner les problèmes courants et de les éviter. Eh bien, oui, il ne le fait pas pendant plus d'une semaine d'affilée, car la collecte d'une version coûte cher.

Si la version est importante, une demi-journée s'envole facilement et il est très difficile à temps de se casser à temps pour passer à vos tâches. Par exemple, vous avez démarré un assemblage qui prend 20 minutes. Pendant le montage, vous pouvez fumer ou penser à la vie. Mais si vous êtes revenu à la tâche et que l'assemblage a réussi, vous devez à nouveau basculer. En général, c'est un processus plutôt morne, se retirant du développement normal et ne permettant pas d'entrer dans le flux. Pour cette raison, la semaine prochaine, l'ingénieur de publication est une personne différente.

Tekhlid

Un autre poste virtuel plus intéressant est le leader technique.

Un architecte (parfois appelé ainsi) entre dans la mêlée lorsqu'il y a une grosse tâche importante ou qu'un nouveau projet est lancé. Cela signifie qu'il prend la responsabilité de la conception, du développement et du lancement. Il a le droit de communiquer avec le chef d'équipe et le chef d'équipe, de prendre des décisions techniques et l'obligation de les documenter est transférée. Si des ordures se produisent au début, il enregistre tous les problèmes qui se sont produits et leurs causes de la même manière qu'un ingénieur de version ou un ingénieur de support.

Conclusions

Qu'obtenons-nous en conséquence?

La rotation des rôles dans une équipe pendant une longue période (au moins six mois) permet même à un junior inexpérimenté d'acquérir les compétences nécessaires pour travailler avec une variété de parties du système et des types de tâches.

Au début, j'ai parlé du fait que la documentation et une expérience réelle peuvent aider à résoudre des problèmes typiques. Après avoir appliqué les pratiques décrites, ce n'est pas un fait que vous résolverez le problème de documentation, mais une expérience de haute qualité et variée sera acquise par tous les participants de l'équipe de développement. Au cours d'une longue rotation de rôles virtuels, une personne parvient à toucher une variété de parties du système en tant qu'ingénieur de support. En tant qu'ingénieur de publication, il apprend à déployer, communiquer, observer, prendre des décisions rapidement. S'il a obtenu le rôle d'expert technique, il se prépare à conduire indépendamment des projets plus importants et plus importants.

À partir de ce moment, le chef d'équipe peut et doit déléguer ses tâches à des subordonnés, car, si vous vous en souvenez, le chef d'équipe a la tâche de ne pas s'éteindre et de grandir quelque part.

Grâce à de telles pratiques, il devient possible de donner enfin à quelqu'un une partie de son travail. Par exemple, les versions. C'est de 4 à 8 heures par semaine, qui sont soudainement libérées de temps en temps. Vous pouvez maintenant les dépenser pour le développement, la lecture d'articles, la résolution d'autres problèmes. Une grosse erreur serait de ne pas le bourdonner sur le calendrier et de le dépenser pour des réunions pas si utiles. Bien que, en règle générale, cela se produise :) Maintenant, le chef d'équipe peut se réjouir, car il a la possibilité d'être moins nerveux et de confier une partie de son travail à ses employés. Si quelque chose lui arrive, les projets ne se concrétiseront pas.

En conséquence, nous augmentons le facteur de bus de chef d'équipe. À son tour, l'équipe peut être sûre que si quelque chose ne va pas avec le chef d'équipe, l'un d'eux sera prêt à assumer un travail et à y faire face.

Bien sûr, il y a des limites. Cette approche n'est pas possible si vous faites tout seul (personne-service).Si un couple est subordonné à une personne, il est déjà possible de faire pivoter la montre et les déclenchements. Trois partenaires et plus, c'est encore mieux.

Dans mon cas, il y a 5 développeurs, dont trois partagent des rôles virtuels entre eux. Les deux autres sont simplement engagés dans le développement de nouvelles fonctionnalités. Ils ne sont pas impliqués dans les versions, le support, etc.

Un autre facteur important est le temps. Vous devrez endurer jusqu'au moment où la rotation des rôles prendra le bon effet, et vous préparerez une équipe à effectuer des tâches qui incombent généralement au chef d'équipe. Le problème est que nous utilisons le temps comme une ressource très abordable et reconstituée. Mais ce n'est pas vrai du tout. Vous pouvez supposer qu'en six mois ou un an, le développeur se «balancera» d'une manière ou d'une autre, obtiendra l'expérience nécessaire et sera prêt pour les tâches et pour autre chose. Mais cela peut ne pas se produire et, en règle générale, ne se produit pas si la situation est laissée au hasard. Le flux des tâches peut être tel qu'il n'aura pas de motivation externe pour se développer correctement. Et c'est l'alternance de rôles virtuels qui donne la chance que vous puissiez aider les membres de votre équipe à se développer de manière globale et à progresser vers les grades suivants.

En fin de compte, tout se résume à une citation très précise: "La tâche du leader est d'avoir plus de leaders, pas ceux qui le suivent aveuglément . " Je crois que l'utilisation de ces outils vous aidera à développer une équipe de chefs d'équipe pendant une minute. Cela vous permettra d'avancer dans un plan professionnel et professionnel. Cela donnera à l'entreprise, à l'équipe et au projet la possibilité d'exister confortablement. Vous pouvez enfin enfin partir en vacances sereinement.