Qu'est-ce qu'un chef d'équipe

Bonjour à tous! Mon nom est Arthur Dementyev, je voudrais partager mon expérience personnelle et écrire plusieurs articles sur la gestion des TI. Et aussi pour dire sur quel râteau est intervenu et quelles erreurs pourraient être évitées. J'écrirai tous les articles sur la base de mon expérience de travail dans diverses sociétés informatiques, dans lesquelles j'ai commencé en tant qu'équipe Team Leader (TL) de plusieurs personnes. Dans l'un d'entre eux, j'ai entièrement développé un petit département pour en faire une grande structure informatique et devenir CTO.

Il y a des problèmes dans de nombreuses entreprises, souvent les gens font des erreurs. C'est la communication avec eux qui m'a poussé à écrire un article. Dans un avenir proche, je vais essayer de continuer à publier. J'espère qu'ils seront utiles aux TL, CTO, chefs de département ou à ceux qui vont juste les devenir. Et je vais commencer par une histoire sur ce que cela signifie d'être chef d'équipe, ce sera un regard intérieur.

Ici, vous devez immédiatement faire une digression. Il existe différentes sociétés:

• grande, où généralement l'informatique est le principal profil d'activité. La hiérarchie a CTO, Tech Leader, Team Leader, Architects, Project Manager, Analyst. Dans de telles conditions, TL peut ne pas exécuter certaines fonctions, que je décrirai ci-dessous;
• les entreprises où seule une partie de l'entreprise est liée à l'informatique. Là, la structure est la moitié de la première option;
• petites entreprises avec un petit service informatique de plusieurs personnes (dans mon cas nous étions trois). Il n'y a tout simplement personne pour qui transférer toutes les responsabilités. Parfois, la tâche consiste à développer un tel bureau dans une entreprise à partir du premier élément de la liste.

Ainsi, l'étendue et l'étendue des responsabilités de TL dépendent largement de la taille de l'entreprise ou du service informatique. Plus l'entreprise est grande et plus la structure informatique est complexe, moins les responsabilités TL sont importantes.

Comment devenir chef d'équipe

Il existe deux chemins standard vers une position TL:

1. Développement de carrière d'un programmeur sur le lieu de travail actuel. Par exemple, lorsque vous prenez beaucoup d'initiative, travaillez dur, vous êtes responsable, montrez que vous avez des qualités de leader, etc. Ou vous êtes transféré dans un lieu vacant lorsque, pour une raison quelconque, ils ne veulent pas inviter une personne de l'extérieur. Dans ce cas, ils examinent les mérites et choisissent souvent le spécialiste technique le plus puissant. C'est-à-dire que le courant, et non l'aspiration, vous y mène.
2. Vous changez d'emploi et venez dans la nouvelle entreprise à la place de TL. Cela se produit lorsqu'un spécialiste a de nombreuses années d'expérience et souhaite se développer davantage, mais la croissance dans une entreprise existante est impossible et compliquée pour une raison quelconque. En conséquence, vous trouvez une entreprise dans laquelle ils croient que vous pouvez la gérer.

Quel que soit le chemin que vous prenez vers votre nouveau poste, vous allez maintenant coder et gérer moins de personnes.

Changement d'activité

Alors, quoi de neuf dans votre vie à partir du moment où vous êtes passé d'un développeur à un TL? Sans aucun doute, vous serez plus impliqué dans les discussions et assisterez aux réunions. Mais vous ne pouvez pas perdre de temps sur des tâches de routine, mais les déléguer à des collègues. Vous devrez également faire plus de révision de code. Peut-être que vous tomberez contrats et facturation en comptabilité. Il semble que la vie a été réussie et vous avez atteint l'objectif.



Mais l'euphorie passe assez rapidement et vous commencez presque à brûler. Quelque chose comme cela se produit: le flux des tâches est sans fin, elles doivent être résolues ou déléguées, suivez ce que l'équipe écrit. Les gestionnaires agaçants veulent tout le temps quelque chose et appellent constamment à des réunions. "Il n'y a plus rien à faire?" - tu penses. Les patrons tremblent avec les délais, et une personne a soudainement quitté l'équipe, et cherche un remplaçant pour vous. La femme appelle également. En général, vous devenez irritable et proche de l'épuisement professionnel. Dans ce mode, vous pouvez vraiment vivre un maximum d'un an.

Comment survivre dans un enfer pareil? Comment font les autres? Le principal problème est de sortir de votre zone de confort. Vous êtes dans un nouveau monde, les anciennes règles ne s'appliquent pas. Bien sûr, il existe un moyen de sortir, mais vous devez le trouver vous-même, dans un sens, vous casser et prendre conscience de quelque chose de nouveau.

Ce que vous devez comprendre

Il y a quelques choses à réaliser. Et plus tôt vous le ferez, mieux il vous sera facile de vivre.

• Vous n'êtes pas payé pour écrire du code. La capacité à écrire du code et à le comprendre est toujours importante pour TL, il évalue et réfléchit à l'architecture, etc. Mais vous n'avez que deux mains, et l'équipe en a clairement plus. Votre tâche principale est de créer des conditions telles que l'équipe soit la plus efficace. Le programmeur doit écrire le code, et tout le reste est votre préoccupation.
• Maintenant, vos collègues écrivent mieux que vous. Six mois à un an s'écouleront et le manque de pratique affectera vos capacités. Après tout, ils font cela presque toutes les heures de travail, et vous de temps en temps ou à la maison le soir.
• Arrêtez de rendre les gens égaux à vous-même. Une personne est tellement disposée qu'elle pense que personne ne peut résoudre le problème mieux que lui. Premièrement, ce n'est pas toujours le cas, et deuxièmement, si vous passez du temps à résoudre tous les problèmes, parce que vous pensez que les gens ne peuvent pas le faire, ce n'est plus TL. Faites confiance aux gens.
• Vos principaux indicateurs de performance sont la qualité de l'ensemble du projet et le temps de développement. Ici, peut-être, le rôle principal est joué par vos compétences en communication. Quelque chose doit être fait efficacement et pendant longtemps, et parfois une solution rapide est plus opportune. La difficulté est que vous devez transmettre cela au programmeur et le convaincre de faire ce dont vous avez besoin en ce moment. Et pas après 2 jours pour constater qu'il n'est qu'au milieu, et qu'une solution toute faite est nécessaire maintenant.
• Motiver les gens. Trouvez un système de motivation pour que tout le monde veuille mieux travailler. Émettre des bonus s'il n'y a pas eu d'urgence? Non, c'est absurde. Mettre en œuvre des métriques, collecter des statistiques, évaluer le travail des gens. Surveillez également la croissance professionnelle des employés qui se développent. Gardez toujours votre doigt sur le pouls.
• Vous devez embaucher des gens. C'est bien si vous avez un service des ressources humaines qui peut embaucher des informaticiens. Sinon, vous avez des responsabilités supplémentaires. Apprenez à créer des postes vacants, à sélectionner des spécialistes, à mener des entretiens et à licencier. Et si vous n'avez pas de startup avec des investissements spatiaux, préparez-vous à trouver des gens dans le budget en dessous du marché. Vous devrez peut-être même appeler les candidats vous-même.
• Vous êtes responsable de l'ensemble du projet. Si votre service se bloque soudainement pendant une longue période ou qu'il ne peut pas être restauré car il n'y a pas de sauvegardes, vous serez toujours à blâmer pour la gestion. L'efficacité technique du projet est à votre charge.
• Vous ne pouvez pas choisir la technologie que vous souhaitez. Un développeur ordinaire peut proposer de nouvelles technologies et la tâche de TL est de maintenir l'équilibre de la pile technologique du projet. N'oubliez pas que la stabilité du projet et du processus de développement est de votre responsabilité. Et si le seul détenteur d'une technologie spéciale quitte l'équipe? De plus, l'utilisation de chaque technologie doit être justifiée. J'ai observé périodiquement comment un creuseur et demi dans un petit projet a tout vu sur les microservices. Ils ne savaient pas que l'entreprise n'était pas prête pour cela. Bien sûr, de telles expériences n'ont abouti à rien de bon.
• Vous êtes une bouée de sauvetage dans toute précipitation. Dans toutes les situations d'urgence, vous ne pouvez pas simplement aboyer à la commande: "Tout doit être fait!" et partez. Vous devez vous asseoir jusqu'au soir. Vous ne pouvez pas laisser les développeurs avec un problème individuel. C'est un mauvais exemple pour eux, la responsabilité dans de tels cas incombe au TL. Mais garder toute l'équipe dans le travail d'urgence n'a pas de sens. Je suis moi-même rentré plusieurs fois à 5 heures du matin, et le lendemain, je suis arrivé à 9 heures du matin pour une réunion. En général, votre travail n'est pas d'en parler.
• Vous devez pouvoir remplacer n'importe quel membre de l'équipe. Si quelqu'un tombe malade, part en vacances ou quitte et que le processus de développement s'arrête, toute responsabilité vous incombe. Soyez toujours prêt pour cela.
• L'aspect psychologique. Vous devez communiquer avec l'équipe et comprendre les gens, savoir quels problèmes ils peuvent rencontrer et même aider à les résoudre. La plupart des programmeurs sont des introvertis, vous devriez essayer de découvrir ce qui ne leur convient pas ou interfère avec le travail. Bien sûr, la majorité ne dira pas cela, vous devez apprendre à comprendre cela. Mais l'essentiel est de ne pas aller trop loin et de ne pas devenir psychologue au lieu de patron, sinon ça finit mal.

Quelques inconvénients. Y a-t-il des avantages?

Oui! Et il y a bien d'autres inconvénients. Vous disposez désormais des ressources que vous gérez. Vous avez donc plus de moyens pour atteindre le résultat, c'est-à-dire résoudre les problèmes commerciaux. Voilà ce qu'il attend de vous.

Je ferais une comparaison avec une équipe de football. En tant que jeune entraîneur d'équipe, chaque joueur a ses propres forces et faiblesses. Si vous les gérez sans tenir compte des caractéristiques de chacun, il est peu probable que vous puissiez gagner quoi que ce soit. Mais en devenant un vrai chef d'équipe, vous devriez être capable de transformer les faiblesses de vos collègues en forces pour la victoire.

Vous pouvez embaucher des gens pas très expérimentés, mais en six mois, faites-en des spécialistes sympas qui feront avancer le projet. N'oubliez pas que vous avez des approches intéressantes dans votre arsenal, par exemple Scrum ou Kanban, qui peuvent transformer un développement douloureux en un processus bien établi pour tous ses participants.

Vous disposez également d'un immense champ d'expérimentation. Vous disposez de ressources pour rechercher et essayer de nouvelles solutions. Cela doit être fait, quelque chose fonctionnera et apportera le succès. Recherchez des moyens qui profiteront à la fois à l'équipe et à l'entreprise. Il n'y a pas de solution miracle, vous devez trouver votre propre solution qui fonctionnera dans des conditions spécifiques.

Utilisez votre expérience et créez des systèmes efficaces de sélection des employés. Motivez et développez également votre équipe. Et n'oubliez pas le développement de vous-même: lire des livres, écouter des conférences, aller à des conférences. En fin de compte, il suffit de discuter avec les gens et de partager leurs expériences. En conséquence, vous construirez l'équipe de rêve la plus forte.

Si vous ne comprenez toujours pas, au fil du temps, vous vous rendrez compte que la ressource la plus importante est les personnes. Restez avec vos collègues, pas le patron et les subordonnés. Soyez un mécanisme, aidez-les et ils vous aideront.

Le chef d'équipe n'est pas un superprogrammeur, c'est un leader qui peut, à partir de toutes les ressources, quoi qu'il en soit, constituer une équipe sympa et faire des bénéfices pour l'entreprise. C’est ce qui rend ce travail vraiment cool.



Pour moi personnellement, c’est le plus grand éloge quand les gens viennent et disent: «Bon sang quel service vous avez arrosé! Aussi avec une si petite équipe! » Après cela, vous comprenez que tout n'a pas été vain. Et cela donne la force de rendre le projet encore meilleur. Pour ainsi dire, gagnez votre championnat avec les gars.

Pour ceux qui partent déjà pour un entretien demain

Il vaut la peine de parler des postes vacants pour le poste de TL. Comme je l'ai écrit ci-dessus, les entreprises sont différentes, elles ont des tâches différentes. Lors de l'entretien, essayez de comprendre de qui l'employeur a encore besoin, afin que vos attentes coïncident avec la réalité. C'est particulièrement drôle lorsque l'entreprise n'a pas de hiérarchie claire, et que tout doit reposer sur une seule personne. Habituellement, dans leurs postes vacants, il y a une phrase: «Vous devez programmer 70 à 80% du temps. Je conseillerais d'éviter de telles suggestions. Soit ils veulent économiser sur vous, soit la direction ne comprend pas pourquoi ils ont besoin de TL. Bien sûr, chaque cas est individuel, mais il existe toujours des facettes du rationnel. En fin de compte, une personne va s'épuiser et partir, car vous ne pouvez pas vivre dans le stress tout le temps.



Abordez le choix du lieu en comprenant ce que vous voulez obtenir. N'oubliez pas que l'entretien se déroule non seulement avec vous, mais aussi avec l'entreprise. N'hésitez pas à poser des questions, à tout savoir. Mieux vaut tout savoir à l'avance que de se retrouver dans l'abîme. Vous pouvez même demander à vous familiariser avec l'équipe, écouter ce que dit votre future équipe. Le prix de l'erreur est élevé: le mauvais endroit peut décourager tout développement ultérieur et ne vous permettra pas d'entrer dans ce monde merveilleux.

Conclusions

Choisir de devenir TL devrait être une décision consciente, et pas seulement parce que vous êtes fatigué d'écrire du code ou que vous souhaitez un salaire plus élevé. TL est la première étape de la gestion informatique. À ce stade, vous pouvez comprendre si vous l'aimez ou non. Sinon, vous pouvez toujours revenir aux développeurs. Mais gardez à l'esprit que si vous travaillez sur TL pendant une longue période, le retour peut être difficile. TL n'écrit pas beaucoup de code, le monde, avec la technologie, change beaucoup, l'expérience est perdue. Il se peut que vous reveniez et qu'il faudra beaucoup de temps pour rattraper le temps perdu.

C'est certainement un travail très intéressant. Vous devrez briser votre réflexion et commencer à penser d'une nouvelle manière. Et, bien sûr, quittez la zone de confort. Mais vous obtenez alors une expérience de gestion inestimable, vous pouvez créer des équipes et obtenir des résultats pour l'entreprise.

Tout ce qui est décrit ci-dessus vient avec l'expérience. Les manuels et les cours ne vous apprendront pas à être TL. Mais ils peuvent aider à contourner un nombre considérable de râteaux.

PS: Merci pour votre temps! Je vous demande de ne pas juger strictement, c'est mon premier article sur le hub J'espère qu'elle sera utile à quelqu'un. J'ai essayé de transmettre mon expérience personnelle. Je serais reconnaissant pour toute opinion. Mais ce n'est qu'un début, alors je veux me plonger dans les détails des processus de développement et de gestion de l'équipe et dire comment je les ai construits.

Mes autres articles sur la gestion informatique:
Une équipe de rêve à partir de rien: embauche de professionnels des TI
Comment créer et gérer des équipes performantes
Nouvel employé - mort ou vivant
Grandir, chef d'équipe, petits et grands