Dans l'article, je vais parler de mon expérience en tant que chef d'équipe dans une entreprise de développement de sites. Afin qu'il soit plus utile et plus facile à lire pour tout le monde, l'article est divisé en chapitres, chacun décrivant un problème distinct et sa solution. Bien que, si possible, la chronologie des événements sera préservée.
J'espère que l'expérience décrite ci-dessous deviendra le râteau de quelqu'un d'autre et, dans les commentaires, je tirerai moi-même quelque chose de collègues plus expérimentés.
Mais pas de noms, d'entreprises, de clients, de noms de collègues. Accord de non-divulgation, tout.
Contexte. Comment et oĂą suis-je devenu chef d'Ă©quipe
C'est la première entreprise où je suis immédiatement venu avec un chef d'équipe. Pour moi, c'était un bond en avant en termes de croissance de carrière. Je suis arrivé au dernier emploi (1,5 ans) en tant qu'intermédiaire et j'ai grandi là -bas pour le senior. Mais les gradations des développeurs sont trop subjectives et ne dépendent souvent que de l'entreprise où ils travaillent. Pendant un certain temps, j'ai beaucoup étudié la question de l'évaluation des programmeurs et, fondamentalement, tout se résumait au fait que «s'ils prenaient le milieu / senior / senior, je devenais middle / senior / senior». Quand j'ai commencé à chercher du travail, j'aurais eu assez d'un poste senior (et je le cherchais), mais l'offre de timlidisme m'a surenchéri et a été un peu flattée.
En fait, lorsque je cherchais des postes vacants, le deuxième jour, j'ai été attiré par une entreprise métropolitaine qui développe des sites sur Bitrix (alors tout se passe dans le contexte du développement de sites sur Bitrix). Au contraire, j'ai longtemps rêvé de quitter Bitrix, mais l'opportunité de réaliser mon potentiel avec une nouvelle qualité et un bon salaire ne m'a laissé aucune chance de refuser.
Fait amusant: la seule condition pour m'engager Ă©tait que je puisse choisir moi-mĂŞme la pile technologique, mais en aucun cas je ne devrais refuser Bitrix si le client le souhaite.
Dans un nouveau lieu
Dans le nouvel endroit, il y avait un très bon patron technique, un mauvais gestionnaire, June, Middle, et plusieurs très gros projets sur Bitrix. C'est une situation assez étrange et je ne comprends toujours pas comment elle s'est développée et ne s'est pas effondrée tout de suite. Mais j'ai peut-être été invité juste pour faire avancer les choses.
Dès les premiers jours, de nombreux problèmes «d'enfants» étaient frappants:
- l'information sur le projet était stockée dans la tête d'une ou deux personnes et nulle part ailleurs. Il n'y avait pas non plus d'instructions et de documentation, et pour savoir comment fonctionnait telle ou telle fonction, il fallait torturer celui qui l'avait fait, si jamais on l'avait créé
- il n’y avait pas de systèmes et de processus établis, tout a été fait "en quelque sorte", "par habitude". Par conséquent, vanité, confusion, non-respect des délais, stress
- les tâches étaient considérées par des mots. Les trackers n'avaient que le nom des tâches, juste pour pouvoir réserver du temps quelque part (il fallait taper 40 heures par semaine)
- le développement lui-même n'était pas aussi chaud:
- quelque part, quelque chose se développait même en dehors de la gita
- quelque part, les programmeurs ont édité à tour de rôle les fichiers sur un serveur
- quelque part il y avait des sites de test, mais quelque part ils ne l'étaient pas (mais en tout cas ils n'ont pas beaucoup aidé)
- en outre, partout il y avait un très, très grand govnokod. Anticipant les commentaires, Bitrix lui-même n'a malheureusement rien à voir avec cela.
- Toutes les communications ont eu lieu sur Skype. Mais j'ai juste une aversion personnelle pour lui
En général, tout est évidemment mauvais, les améliorations peuvent commencer immédiatement, sans effectuer d'études préalables. Cela m'a même fait plaisir dans une certaine mesure, car vous pouvez influencer les indicateurs dès les premiers mois. Ils n'ont vraiment pas encore été pris en compte, mais à cause de Pareto, ce n'est pas encore important.
À ma grande déception, les processus ont évolué assez lentement au cours des premiers mois. Premièrement, je devais moi-même travailler sur des tâches client pendant 8 heures par jour, en tant que programmeur, car je n'avais tout simplement pas assez de mains. Deuxièmement, dans les conditions d'une telle pression temporelle, il était assez dangereux de faire de grands changements qui pourraient entraîner une confusion et une perte de code ou de temps.
Maintenant, nous allons directement à l'article et à la résolution de problèmes. La première chose dans la nouvelle entreprise a été de s'orienter.
Tirer des informations des objectifs des employés
À mon arrivée, je ne savais absolument rien des projets ni des clients et ces informations n'étaient pas stockées.
nulle part sous forme de texte. Par conséquent, la première chose que j'ai commencé à tirer des informations des objectifs des collègues dans les textes.
Essentiellement, une entreprise de développement dispose de 2 grands sous-ensembles de textes importants et / ou utiles:
- instructions, réglementations, articles, descriptions fonctionnelles, user stories, ...
- Tâches avec leur nom, description, commentaires, journaux de temps, signatures de commits, commentaires dans le code, autotests, ...
Au début, je demandais juste à mes nouveaux collègues d'écrire pour moi des choses spécifiques du premier paragraphe, mais bien sûr tout le monde était paresseux, d'autant plus que la rédaction d'instructions n'est pas une fonctionnalité à couper. Mais comme au début j'avais toujours un look complètement non-fumeur et que je devais étudier les projets, en les voyant pour la première fois, j'ai juste commencé à traduire mes recherches en texte, créant ainsi des instructions et des descriptions de la fonctionnalité.
Elle a également eu la chance qu'en même temps, la société commence à passer activement à la mêlée (juste une coïncidence), les logiciels de travail changeaient (également une coïncidence), respectivement, les processus commerciaux étaient créés à partir de zéro. Et pour une raison quelconque, j'avais initialement une grande autorité aux yeux de mes collègues. Par conséquent, je viens de commencer à écrire les règles moi-même (dans les limites de la compétence) et à reconstruire les gars dessus, c'est-à -dire, en fait, à dicter les règles et à être un exemple de leur mise en œuvre.
La solution au problème de formulation et de gestion des tâches a été retardée de plus d'un mois. Cela s'est avéré être un goulot d'étranglement et dans les chapitres suivants, j'aborderai ce sujet plus d'une fois.
Au début de mon travail, le manager fixait terriblement les tâches. Exemple: le nom de la tâche est "Corriger le bug sur le site" et c'est tout: pas de description, pas de captures d'écran, seulement le nom et la référence au projet. Bien sûr, il y a eu des tentatives de transmettre les principes de SMART et l’importance de décrire les tâches au gestionnaire, mais tous les engagements ont été divisés sur «Je n’ai pas le temps de peindre les tâches».
À un moment donné, j'ai essayé d'assumer une partie de la responsabilité de la définition des tâches, mais il est ironique de constater que je n'ai pas eu assez de temps pour cela, car j'ai écrit du code presque tout le temps.
Mais le problème connexe d'obtention de l'état actuel des tâches à tout moment, nous avons décidé de contourner, à travers des phonings de coordination et des plans pour la journée.
Reconstitution du personnel, intégration des équipes
Presque au début, il était clair que les gens manquaient cruellement (j'ai moi-même écrit le code à temps plein, mais nous n'avions toujours pas le temps).
Les premiers ont décidé de prendre les devants, parce que les deux progéniteurs de l'entreprise étaient de retour (et je m'identifiais aussi plus avec le backend), et il y avait suffisamment de tâches, en particulier dans la mise en page, et les tâches sur la réaction et la vue commençaient à se profiler à l'horizon.
J'ai eu beaucoup de chance d'avoir (et d'avoir) un ami avant, qui en même temps a commencé à penser à quitter le freelance, nous avons donc pu combler rapidement le poste vacant, et j'ai reçu une prime pour amener un employé (un autre avantage pour les autorités, avant cela). vu h-récompenses).
Presque immédiatement après le front, 2 becks ont été trouvés. Et quelque part en même temps, le joon est parti (dont le code m'a piqué quelques mois après son départ).
Au total, la situation suivante s'est développée:
- un «vieil homme»
- je
- trois débutants absolus
- le travail n'a pas encore été établi
- certaines connaissances sont déjà perdues
Il est naturel que des dizaines de questions de nouveaux arrivants m'ont immédiatement plu, en tant que chef d'équipe. Il s'agissait principalement de questions sur le cycle de vie du code (où écrire le code, comment montrer où l'envoyer plus tard, comment collecter la version), la gestion des tâches (comment mettre les tâches au travail, comment afficher le statut, comment déterminer les priorités) et comment travailler avec git . De plus, les gars essayaient toujours de poser les questions "Comment fonctionne A?", "Avons-nous un B sur notre site?", Mais presque tout à ce moment était réduit seulement à la nécessité d'étudier le code.
Tout d'abord, il était important de donner aux programmeurs la possibilité, en principe, de travailler et d'écrire du code par eux-mêmes. J'ai mené des conversations d'introduction avec eux, répondant à leurs questions, puis j'ai bien sûr décidé de réduire toutes les questions et les schémas en un article, qui s'est ensuite transformé en conférence, puis en un tout nouveau schéma de travail dans l'entreprise, dont je parlerai dans le chapitre suivant.
Ici, il vaut la peine de dire quelques mots sur le processus d'embauche dans notre entreprise, qui fonctionne toujours.
Processus d'embauche
Premièrement, nous avons une prime pour attirer un employé, ce qui est une bonne pratique.
Deuxièmement, nous avons décidé de ne pas organiser un examen lors de l'entretien, mais de confier une tâche très volumineuse, proche de nos tâches quotidiennes. Cela est pratique dans la mesure où le temps consacré à l'embauche n'est réduit que jusqu'à la recherche de CV appropriés et un entretien facile avec les candidats pour vérifier l'adéquation et une histoire sur la tâche de test, et, bien sûr, vérifier directement la tâche.
Juin peut réellement résoudre le problème en quelques soirées, volumineux lui donne beaucoup de liberté dans la mise en œuvre, les améliorations et les puces évidentes. C'est cette flexibilité de mise en œuvre qui nous aide à évaluer le niveau du candidat. Nous disons immédiatement que la chose la plus importante pour nous est de respecter les délais de résolution du problème (l'exécuteur s'appelle lui-même) et à la fin afficher le code de travail dans le référentiel. Nous ne stipulons pas l'utilisation d'approches et de technologies, elles sont choisies par l'interprète, mais afin de se rencontrer et de donner des conseils, nous avons énuméré les améliorations possibles dans la liste, comme les tâches avec un astérisque, par exemple, en passant par Ajax, ext. validation arrière, protection anti-spam, conception de module, utilisation de D7, ...
Total:
- Selon le résumé et l'entretien, on peut juger de la nature de la personne
- par la date limite pour l'achèvement de la tâche, le fait de la capacité de travail du code et l'utilisation de la gita, nous prenons la décision même de l'embauche
- par la qualité de la performance, nous déterminons le niveau et, en conséquence, le salaire que nous pouvons offrir
- en plus déjà sur la tâche de test, nous montrons quelles tâches devront être résolues dans un nouvel endroit
Mise en place d'un système de développement et de livraison de code
À cette époque, nous avions plusieurs projets qui ont été développés de manière assez aléatoire:
- quelque part dans la bataille, il y avait un maître, ailleurs une branche
- quelque part il y avait des sites de test, quelque part pas
- et s'il y en avait, alors les adresses de chacun sont différentes
- git, en principe, a été utilisé faiblement et avec un grincement
- modifications manuelles de la base de données
- ...
Au début, j'ai essayé de corriger la situation par petites portions, de sorte que les programmeurs avaient besoin de moins pour réapprendre et, en conséquence, je me suis trompé. Par exemple, j'ai sorti le dossier bitrix sous la gita, renommé la branche principale en master.
Mais quand une reconstitution importante est venue à nous, la situation est devenue critique. J'ai dû expliquer beaucoup, rappeler et écrire des instructions illogiques, car la structure de développement actuelle n'était pas du tout très intuitive.
Je ne suis pas fan des instructions en tant que telles, je pense que leur présence est un indicateur du problème en soi, il a donc été décidé de créer un système commun pour tous les projets qui doit être compris une fois et qui, par sa structure même, supprime beaucoup de problèmes et de questions.
Le système est le suivant:
- chaque développeur dispose d'une plate-forme de travail personnelle à distance où il travaille
- il y a une plate-forme où la fonctionnalité est accumulée pour la prochaine version
- si nécessaire, il existe une plateforme de démonstration pour démontrer tous les débuts de la fonctionnalité
- tout le code d'une tâche est conservé dans une branche distincte, où le nom de la branche est égal au nom de la tâche dans le tracker
- pour remplir le code sur une plate-forme commune, il vous suffit de tenir la branche quelque part et de pousser
- les modifications apportées aux bases de données sont stockées sous forme de fichiers de migration dans la branche des tâches
J'ai donné une grande conférence sur le sujet de ce système, et nous avons commencé une transition pilote vers celui-ci sur un projet, où nous venons de jeter la personne âgée nouvellement acquise.
Le processus de transfert de tous les projets vers ce système, bien sûr, a été retardé (par exemple, sur un projet, nous ne pouvions pas mystiquement passer au maître la première fois), et il continue toujours, mais en conséquence, nous avons au moins:
- la possibilité de libérer uniquement les tâches nécessaires, et de ne pas libérer les fonctionnalités inachevées avec du code utile
- faire une version de tâche sans impliquer un auteur de code
- travail parallèle sur un projet entre interprètes
- ne perdez pas de code
- tester la fonctionnalité isolée d'une autre et ne pas arrêter le travail du programme
Tout cela n'existait tout simplement pas auparavant. De plus, vous n'avez pas besoin d'expliquer les détails supplémentaires de l'utilisation de git ou de sites de test aux nouveaux programmeurs maintenant, car tout est universel et intuitif.
Scrum, communications, réglementation
Bien sûr, dans l'article, je voulais parler de la façon dont j'ai aidé au développement de l'entreprise en tant que chef d'équipe, mais vous ne pouvez pas parler du développement de notre entreprise sans mentionner notre patron et son initiative, sinon ce ne sera pas entièrement honnête.
Tout d'abord, il a introduit la mêlée, et au moment de mon arrivée, les processus dans l'entreprise ont commencé à être activement refaits. À ce moment-là , elle l'a également transférée de Bitrix24 à Jira.
Scrum a certainement apporté plus de rythme à l'entreprise et réduit le chaos. La reconversion des managers, leur exécution des appels de coordination, l'ouverture / fermeture / la planification des sprints ont été suivis par le chef lui-même, en tant que senior dans ce lien.
Il a également beaucoup travaillé sur les gestionnaires eux-mêmes, en particulier sur la façon dont ils communiquent avec les clients et les programmeurs, car la plupart de leur travail (mais, sans s'y limiter) consiste à communiquer: isoler les programmeurs des clients, transmettre les souhaits des clients à tâches dans le backlog et dans les sprints, rechercher et revisiter des user stories. Tout cela a entraîné de nombreuses réglementations: sur la communication avec les clients, sur la définition des tâches, sur le travail avec un backlog, sur l'acceptation de bogues au travail. Un fort accent a été mis sur la communication et le lien de gestion a vraiment montré des progrès.
La transition vers la mêlée elle-même, bien sûr, est très difficile et au moment de la rédaction de cet article, nous n'en sommes pas encore devenus les professionnels, bien que tout y soit. Et je suis très heureux d'avoir reçu beaucoup de nouvelles connaissances sur les méthodologies et produits flexibles d'Atlassian.
Nouveau manager. Textes, définition des tâches, backlog
À un moment donné, une autre personne est venue nous aider à faire un bond en avant - un nouveau manager (avant cela, nous en avions un).
Je ne m'attendais pas à ce moment, car nous n'avions pas autant de projets et de programmeurs et en théorie un seul manager aurait dû suffire. Ce lien était un point faible de l'entreprise, mais nous avons essayé de résoudre ce problème en développant le personnel existant. Il se trouve qu'un excellent gestionnaire, que je connais bien, a décidé de changer d'emploi, mon patron l'a découvert, alors qu'elle interviewait soudainement nos sous-traitants et j'ai mentionné cet incident drôle, et nous l'avons appelée pour nous. Un autre prix)
Au début, la nouvelle responsable a répété une partie de mon chemin, car elle a été confrontée aux mêmes problèmes (elle ne sait rien et nulle part où lire) et a recommencé à nouveau, mais avec la différence qu'elle n'a pas touché le code, l'infrastructure de développement et les compétences du programme, mais a travaillé avec fixer des objectifs, communiquer avec les clients, nettoyer l'arriéré et également extraire avec diligence des informations du chef de l'ancien gestionnaire. En particulier, la première chose que j'ai retirée est la liste de contacts des clients et des entrepreneurs.
L'équipe la connaissait déjà , car nous l'avons une fois invitée en tant que conférencière pour nous parler de la gestion du temps. De plus, les tâches d'acier ont commencé à être posées plus en détail, elle n'ajoutait pas la négativité et ne la transmettait pas du client, les statuts des tâches devenaient plus pertinents à tout moment. Par conséquent, nous lui avons immédiatement placé de grands espoirs.
Pendant les premières semaines, lui et son patron ont éliminé l'arriéré d'un projet, en particulier, ils ont trouvé une période de retard de 2 mois et une épopée qui n'avait pas encore commencé. En outre, en principe, de nombreuses tâches ont fait surface qui devaient être effectuées il y a un mois. C’est bien, bien sûr, que l’arriéré ait été nettoyé, mais cela a été fait trop tard.
Elle-même a vraiment «raccroché» au mess et a tenté à plusieurs reprises de partir, mais nous avons amélioré le lien de gestion d'une manière ou d'une autre. Les tâches sont moins susceptibles d'être perdues dans le backlog, les programmeurs sont moins susceptibles de demander à nouveau.
La morale de l'histoire sera Ă la fin.
La crise
Presque six mois après le début du travail, j'ai dû partir en vacances. Soit dit en passant, je me suis mis d'accord sur des vacances même lorsque je postulais pour un emploi, car il était prévu comme lune de miel, donc la période de mon absence était connue bien à l'avance. Mais de toute façon, bien sûr, j'étais nerveux jusqu'au bout, car nous n'avons cessé que récemment de travailler «pour l'usure».
La semaine avant les vacances, j'ai fini de déléguer des tâches, enseigné à des personnes sélectionnées à effectuer des tâches spécifiques en dehors du code, assigné à chaque programmeur la responsabilité d'un projet spécifique, terminé ou transféré toutes mes tâches actuelles (je programmais encore la majeure partie de la journée). Rien de mauvais augure à la mi-juillet.
Et dans les premiers jours de vacances aussi, rien n'annonçait de problème.
Et puis il y a eu une crise.
Sur un projet, le client a manqué de patience car ses attentes de tâches (délais, liste, priorités) ne correspondaient pas au cas. Nous l'avons nous-mêmes remarqué il n'y a pas si longtemps avec le traitement complet du backlog et la communication active avec le client (chapitre sur le nouveau manager), mais c'était trop tard.
Et sur le deuxième projet, ils ont finalement accepté une tâche très importante et attendue depuis longtemps, ont terminé les tests et l'ont publié. Mais la nouvelle fonctionnalité a soudainement renversé le site de combat sous une lourde charge, et le milieu et le milieu avant n'ont rien pu faire pendant une semaine. .
, . , . , , .
vue, ( , ).
— , , , - , “ / / / ”.
, , , , .
, , , , , .
, . , - . , - .
. ( ), - :
- , - , - , . .
, . , , , .
. , , , . , , .
, vue, .
, - 5. -, . , .
, : , , , .
, - , - . , , , , , .
.
. , , , - , , .
, , , 1 , - , , , , , . , .
,
. .
, , 3-4 “ 3 ”, 40.
, , .
/ — ( ). , . , . , , -, 8 .
. :
- :
( ), :
— . :
:
, . , .
, . .
—
, , , , , “ ” , .
, , “” - .
, , , , , 2 . , , .
, , / , . , , .
, . , , / - , , - .
(, )
- . , , , , , , , .
, , . , , .
: , , , , . , .
, - , . , .
:
, , , .
, , , ( ), , , .
, ( , 2 , ).
, , . “ ”, :
, .
2e partie
Cet article a couvert environ six mois de mon travail dans un nouveau poste. Dans la deuxième partie, je voudrais parler de la façon dont nous progressons vers les objectifs avec l'aide de:
- autotests que nous commençons tout juste à mettre en œuvre. Étrange, mais pour une raison quelconque, il n'y a aucun exemple valable sur Bitrix.
- se débarrasser de l'héritage dans le code
- accélérer et simplifier davantage le développement
- ce que j'apprendrai des commentaires
- beaucoup d'autres choses secrètes (soudain mes gars me lisent)
Merci à tous d'avoir lu. Je serais très heureux de commenter, surtout si vous connaissez des moyens plus optimaux pour résoudre les problèmes que nous avons rencontrés.
Bonne chance et joie Ă tous dans le travail et la vie!