Lorsque vous travaillez en tant que développeur, vous voyez tout le temps comment les chefs d'équipe sont assis sur un tas d'appels, sont responsables de tout, écrivent autant de code que vous et en même temps, ils n'ont plus d'argent. Soit idéologique, soit idiots ira pour cela.
Je ne suis pas un idiot, mes idées ne tournent pas autour des valeurs commerciales, donc vous ne vous abonnerez pas à moi. Mais on ne nous interroge pas toujours à ce sujet. D'abord, j'ai été embauché en tant que premier et unique développeur dans une startup renaissante, puis ils m'ont dit d'embaucher plus de personnes, puis je me suis retrouvé en charge de trois développeurs, deux testeurs et un analyste.
Bref, tout est encore pire qu'il n'y paraissait de l'extérieur.
Chaque jour, six personnes attendent que vous leur disiez quoi faire, puis vous leur direz comment le faire, et vous évaluerez également si vous avez bien fait. La septième personne à la fin de la journée vous demandera également ce que vous avez fait vous-même. Dans le sens où vous vous êtes codé, et qu'a fait chacune des personnes dont vous êtes responsable.
Je me suis plaint ici une fois que la sonnerie est une béquille qui permet de contrôler sans fouiller, et maintenant je suis convaincu une fois de plus que j'avais raison. Ils viennent me poser une question - et je ne sais pas quoi répondre. Nous nous appelons, et la personne obtient une réponse de mes malheureux cerveaux sans ma participation. Je ne suis pas non plus prêt à formuler mes questions - je ne sais pas quoi leur poser. Alors je viens d'appeler et de regarder comment tout s'arrange. Et encore mieux - je fais en sorte qu'ils se téléphonent, sans moi du tout. Depuis un mois maintenant, je n'ai pas pu clôturer une tâche assez simple, car mon cerveau est épuisé par les tâches managériales, et surtout par le fait que je ne sais pas comment les exécuter.
J'ai pensé, d'accord, c'est comme ça que ça devrait être. Je n'ai pas étudié pour devenir manager. Puis j'ai regardé mon passé, je me suis souvenu de toutes mes pistes et j'ai soudain réalisé que personne n'avait étudié! Aucun d'eux ne savait comment gérer. Ils l'ont également masqué avec des appels sans fin et des procrastinations. Ils ne savaient pas quoi me répondre, ils ne savaient pas où nous allions, ils ne savaient pas du tout ce qui se passait et qui faisait quoi.
Quand j'ai fait une tâche simple pendant deux mois, et chaque jour j'ai menti que j'avais de grandes difficultés, et il y avait un problème sérieux - puis j'ai fait une pull request pour quatre fichiers qui ont été esquissés du jour au lendemain - personne ne m'a grondé, pas parce qu'ils étaient désolés. Ils n'avaient simplement aucune idée de ce que je faisais là-bas. Et ils ont regardé mon code ligne par ligne - pour aller au fond de la dénomination et trouver des anti-modèles juteux - mais sans s'y plonger. Parce qu'il n'y a pas de temps pour fouiller, je ne veux pas, et on ne sait pas pourquoi.
Tous mes anciens patrons ont adopté et idolâtré l'agilité - c'est un gros jeu de béquilles, un jeu qui aide un groupe de personnes qui n'ont aucune idée de ce qui se passe, à faire semblant que tout va bien et que nous avançons.
J'ai travaillé avec des chefs d'équipes provinciales locales, qui dans des équipes sérieuses ne seraient même pas admises à la mise en page, j'ai travaillé avec des directeurs de développement sympas de grandes entreprises étrangères, j'ai travaillé avec des gens que quelqu'un considérait comme de vrais génies de la programmation.
Et tous, en ce qui concerne la gestion, se sont assis sur le cul. J'ai appris les règles de ce jeu lors de mon premier travail avec Agile. Nous nous sommes appelés tous les matins et chacun a dit ce qu'il avait fait, ce qu'il faisait et ce qu'il ferait. Au premier tel appel, je suis venu avec l'idée que je devrais signaler et prouver que je ne mange pas mon pain en vain. J'ai entamé un long, très long discours sur ma tâche, expliqué en détail pourquoi elle n'était pas encore prête et ce avec quoi je me bats maintenant. J'ai été coupé au milieu: «Phil, tu veux quelque chose de nous? Non? D'accord, nous avons tous compris qui est le prochain? "
La personne qui nous contrôlait n'avait besoin de savoir qu'une chose - si je lui poserais des problèmes pour aujourd'hui ou non. Doit-il passer du temps avec moi aujourd'hui. Avant que je ne commence à parler, il avait déjà le discours parfait dans sa tête pour moi: "everithin gous akordin that plan." Tout autre développement d'événements pour lui est un pur mal.
Il y a une autre option. Lorsque le problème lui a été porté non pas par moi, mais par d'autres parties du système, le calendrier agile est pourri, et maintenant il ne peut pas dire lors de sa réunion pour les prospects que tout se passe comme prévu - et devient également le problème de quelqu'un. Cela fait automatiquement de moi son problème, et il frappe le PM.
Nous commençons à discuter de quelque chose, et nous comprenons tous les deux - nous devons trouver un moyen d'arrêter d'être des problèmes. Cela n'a rien à voir avec le produit ou le projet. Nous avons un putain de ticket à déplacer. Et nous le déplaçons - de la manière la plus simple qui soit. On le corrige avec le code, on le met dans le norepro, on met l'étiquette «bloqué par» - peu importe. En ce moment, nous ne nous soucions absolument pas du produit, nous avons un ticket. Ou beaucoup de billets.
Il y avait deux réalités dans toute équipe où je travaillais. Une réalité est un vrai produit, et de vraies personnes qui l'améliorent parce qu'elles le veulent. Et puis il y a eu jira, qui existe absolument parallèlement à tout cela. Et la seule personne capable de synchroniser l'état réel du projet avec les cartes est le chef d'équipe.
Tous les chefs d'équipe avec lesquels j'ai travaillé ne savent pas comment faire - et ils ne le veulent pas. Ils travaillent pendant qu'ils travaillent et utilisent le jiru pour considérer que leurs responsabilités de gestion sont remplies. Après tout, les personnes qui évaluent les chefs d'équipe regardent jira, pas le produit. Et les personnes qui regardent le produit ne peuvent générer que de nouveaux tickets pour le jira. Ils ne peuvent pas évaluer les programmeurs. Mais jira n'affecte rien! J'ai vu des produits terribles dont le tableau kanban était en parfait état, et de très bons produits qui avaient des billets dans la colonne «au travail» pendant trois mois avec le titre «faire un projet».
L'argument «j'ai vu» n'est pas très bon, mais il fera l'affaire, car je suis à peu près sûr que vous avez tout vu aussi.
Au sens large, un chef d'équipe doit s'assurer que les personnes qui veulent vraiment travailler n'ont aucun problème. Et les personnes qui ne veulent ni expulser ni transférer dans la première catégorie. Toute la douleur de la gestion réside dans la seconde - il y en a beaucoup plus. Et personne ne fait rien avec eux. Seul un développeur peut déterminer de manière adéquate si un développeur fonctionne bien. C'est une histoire très compréhensible - vous devez examiner en profondeur ses pull requests et vous plonger dans ses tâches, et il y a un problème - cela prend autant de temps qu'il en coûterait pour tout faire vous-même. En bref, pas une option.
Par conséquent, ce sont de purs gestionnaires, et non des développeurs, qui ont décidé d'identifier les mauvais développeurs. Ils ont mis au point un tas de systèmes avec des billets, des graphiques, toutes sortes d'examens de performances et un tel chapeau. Et cela fonctionnerait même, sur certains stupides. Mais même les pires développeurs sont assez intelligents pour tromper ce système. Eh bien, vous savez comment c'est fait. Ils mesurent tout dans les billets, non? Cool. Je vais décomposer la "refonte de l'interface de la forme X" en dix tâches dans le style de "fixer l'étiquette dans le bouton Y". Le même travail, plus de tickets. Le chef d'équipe me donnerait un coup de pied au visage pour de telles feintes.
Mais dans le système actuel, il ne le fera jamais. Après tout, premièrement, plus il y a de billets fermés, moins il y a de problèmes. Deuxièmement, il est lui-même suffisamment chargé pour fouiller dans mes tickets et mon code. Troisièmement, il le fait lui-même - parce qu'en raison de ses fonctions de leadership, il n'a pas non plus la force de bien performer. Et quatrièmement, et c'est la chose la plus importante, il pourrait bien faire partie de ces personnes qui ne veulent pas travailler.
C'est mon expérience, l'expérience de toutes mes connaissances - mais elle a des exceptions. Il y a des entreprises où le processus de développement fonctionne vraiment très bien. Je vais vous dire pourquoi - ils ont gagné à la loterie. Il s'est avéré qu'il y avait beaucoup plus de gens qui voulaient travailler - avec des gens comme vous ne réussissez pas, tout ira bien. Ils utilisent même des guirlandes de gestion avec des tableaux pour les entreprises, et leurs performances sont clairement visibles à la fois par jir et par des mesures intuitives. Et quand leurs managers non développés viennent se mettre en travers du chemin, ils ont derrière eux un produit fabuleux qui leur donne le droit d'envoyer ces têtes parlantes en enfer.
Ces équipes s'auto-répliquent - pendant le processus de recrutement, elles n'approuvent intuitivement que des personnes comme elles, et elles ont suffisamment de poids dans l'entreprise pour ne pas donner des mots décisifs aux RH qui jouent leurs «métriques» et leur psychologie.
Mais une telle équipe est une chance fantastique. C'est ce qui se passe habituellement. Pour dix personnes, vous en avez deux qui veulent travailler. L'un d'eux est un chef d'équipe et l'autre démissionne. Le développement fonctionne mal et les managers viennent y remédier. Et à partir de ce moment, il n'y aura plus aucune chance. Les managers vont construire un processus autour de jira, prendre le contrôle de choses qu'ils ne comprennent pas du tout. Ils embaucheront des personnes dont ils ne savent rien du travail, ils commenceront à y inviter des développeurs existants qui amuseront ChSV, se connecteront cette fois dans le rapport de temps et donneront des commentaires aléatoires. Et puis ils décident qui embaucher - également au hasard. Les gens qui veulent travailler entreront de temps en temps dans de telles équipes, où ils deviendront des oisifs ou ne prendront pas racine.
Je ne veux pas dire que les managers sont des idiots et qu'ils ne peuvent rien faire. Ils savent encore comment gérer. Mais pas par les développeurs. Les développeurs ne peuvent être contrôlés que par un développeur qui sait vraiment gérer. Une telle personne fixera l'équipe avec n'importe quel ratio de volonté et de refus de travailler.
Le seul dommage est qu'ils n'existent presque pas. Pour devenir un bon développeur, vous devez être intelligent et apprendre beaucoup. Pour devenir un bon manager, il faut avoir du talent et beaucoup d'apprentissage. Et quelle est alors la chance qu'une personne combine ces deux qualités? C'est la meme chose. En même temps, la plupart des chefs d'équipe de l'industrie sont devenus eux, parce que, eh bien, quelqu'un devrait le faire. Absolument aléatoire.
Je pense que vous devez apprendre à comprendre que le développement est une compétence, la gestion est la deuxième compétence et la gestion du développement est la troisième compétence qui comprend des parties de la première. Et cela devrait être étudié séparément. Et très méthodiquement et efficacement. Tant que nous ne le ferons pas, nous aurons des développeurs qui ne peuvent pas gérer les développeurs et des gestionnaires qui ne peuvent pas gérer les développeurs.
La publicité
De nombreux clients ont déjà apprécié les avantages des serveurs épiques de Vdsina .
Ce sont des VDS bon marché avec des processeurs AMD EPYC, une fréquence centrale du processeur jusqu'à 3,4 GHz. La configuration maximale vous permettra de réaliser presque toutes les idées - 128 cœurs de processeur, 512 Go de RAM, 4000 Go de NVMe. Vous pouvez également commander!
