Bonjour. Je m'appelle Aleksandr Guzenko, je suis le chef d'équipe de trois équipes de développement front-end dans une grande entreprise. Récemment, un des employés est venu vers moi et m'a dit : « Je veux devenir chef d'équipe. Par où commencer ? » C’est ainsi qu’est née l’idée de cet article, que je lui ai promis de lui envoyer ultérieurement à titre indicatif.
Dans cet article, je vais vous expliquer comment je suis devenu chef d'équipe, de quelles compétences vous ne pouvez pas vous passer à ce poste et comment améliorer vos compétences en gestion d'équipe si vous êtes un développeur « ordinaire ».
Commençons par la théorie, sans laquelle il sera difficile de comprendre pourquoi vous êtes allé gérer le développement, mais avez plutôt compté le budget du projet.
Au sens classique, un chef d'équipe est le chef d'une équipe de développement. C'est vrai mais avec quelques réserves.
Dans le paysage actuel, les chefs d'équipe s'étendent au-delà des programmeurs pour inclure des concepteurs, des analystes, des testeurs, des spécialistes du référencement et divers professionnels informatiques et non informatiques. Par conséquent, il est plus précis de définir un chef d’équipe comme le leader d’un groupe d’employés partageant le même rôle, même si je me concentrerai spécifiquement sur les développeurs.
Deuxièmement, le chef d'équipe n'est pas seulement un chef d'équipe, mais le principal lien entre les salariés et la direction. Il s’agit d’un ajout important, et j’essaierai d’expliquer pourquoi ci-dessous.
Troisièmement, pour comprendre de quoi le chef d’équipe est responsable, il est important de faire la distinction entre le rôle et le poste.
Le rôle du chef d’équipe implique principalement des tâches managériales :
Dans sa forme pure, le rôle est rarement trouvé, même si la liste des responsabilités sur le site de recrutement indique le contraire.
Le poste de chef d’équipe peut combiner plusieurs rôles à la fois : chef d’équipe, responsable technique et développeur principal. A ce poste, un spécialiste écrit souvent lui-même le code, gère le travail de l'équipe, et est responsable de la partie technique :
C'est beaucoup plus pratique pour les entreprises lorsque le chef d'équipe et le responsable technique sont une seule personne. En pratique, même dans les grandes entreprises, le poste de chef d’équipe implique une combinaison des trois rôles dans des proportions différentes. Par conséquent, les idées sur ce que fait un chef d’équipe diffèrent souvent.
Si vous demandez à des développeurs de différentes entreprises quelles sont les responsabilités d'un chef d'équipe, les réponses seront probablement différentes. Il y aura un éventail d’opinions similaire parmi les chefs d’équipe eux-mêmes. Pour le vérifier, il suffit d'aller sur n'importe quel site de recherche d'emploi et de consulter la liste des responsabilités dans les différents postes vacants.
Pour diriger une équipe de développement, vous avez besoin de compétences et d’expérience sérieuses. Par conséquent, la manière la plus courante et la plus correcte de devenir chef d’équipe est d’abord d’atteindre le niveau supérieur et ensuite seulement de viser un poste de direction. Mais cela n'arrive pas toujours.
Si l'équipe est composée uniquement de programmeurs intermédiaires et que parmi eux se trouve un employé d'initiative qui est au courant de toutes les questions et soutient le projet, il sera un excellent chef d'équipe. Oui, il a moins de compétences techniques que le senior, mais s'il n'y a personne de plus haut dans l'équipe, ses compétences seront tout à fait suffisantes.
Dans le même temps, tous les seniors ne trouveront pas le poste de chef d’équipe comme un cheminement de carrière approprié. Travailler à un poste de direction doit être vraiment intéressant, sinon vous risquez de perdre la charge de travail de gestion.
Réponse courte : essayez-le. Dites à votre responsable que vous souhaitez assumer des responsabilités supplémentaires gratuitement et voyez ce qui se passe. Il s’agit d’un système gagnant-gagnant, c’est pourquoi la direction est généralement disposée à coopérer.
Le chef d'équipe gagne : quelqu'un fait son travail à sa place.
L'entreprise gagne : le travail est fait, mais vous n'avez pas à payer pour cela.
Le stagiaire chef d'équipe a aussi un avantage : après avoir travaillé dans ce mode pendant plusieurs mois à un an, il peut comprendre par lui-même s'il réussit et s'il aime diriger. Et si la réponse à chaque point est « oui », vous pouvez sérieusement envisager de grandir dans cette direction.
Il n'y a que deux options. La première consiste à exclure tous les autres développeurs de l’entreprise et à devenir chef d’équipe en tant qu’employé « le plus âgé ». Il existe cependant un risque que le mot « ancien » ne doive pas être mis entre guillemets. La deuxième option consiste à prendre l’initiative vous-même.
Je vais vous dire comment ça s'est passé pour moi. D'après mon diplôme, mon métier est manager, et j'ai étudié seul la programmation en parallèle de mes études à l'université. J'ai donc décidé de devenir chef d'équipe de développement avant même d'obtenir mon premier emploi de programmeur.
Au début, j'ai travaillé dans des petites entreprises. Il m’a fallu deux ans pour comprendre et passer du statut de junior à celui de joueur intermédiaire fort. Sans expérience en programmation, vous ne pourrez pas devenir un bon chef d'équipe : vous devez comprendre comment fonctionne le processus de développement, quels sont les erreurs et les pièges.
Quelques années plus tard, je suis arrivé à travailler dans une grande entreprise et j'ai immédiatement indiqué que je souhaitais devenir chef d'équipe. Dans les grandes entreprises, une fois tous les six mois ou tous les ans, ils procèdent généralement à une évaluation des performances, lorsque le manager rencontre l'employé et construisent ensemble un plan de développement individuel pour un avenir proche. À chacune de ces réunions, j'ai dit que je voulais devenir chef d'équipe. La première fois, ils m’ont dit : « Tout va bien, mais acquiert d’abord de l’expérience. » Nous avons créé un plan de développement afin que je puisse acquérir une expérience de leadership.
Pendant environ six mois, avec mon chef d'équipe, j'ai évalué et décomposé les tâches et essayé de les répartir entre les collaborateurs. Lorsque la qualité de notre travail était plus ou moins égale, l'entreprise vient de former une nouvelle équipe de développement front-end, que je dirigeais. Dans les grandes entreprises, il ne faut pas attendre trop longtemps.
On dit qu'il y a deux étapes importantes dans le développement d'un chef d'équipe : la première est de deux à six employés et la seconde est de 7 ou plus. Au début, je n'avais qu'un seul employé, et maintenant je dirige trois équipes de développement front-end, soit 12 employés.
J'ai simplement fait preuve d'initiative, me suis présenté devant la direction, et dès que l'occasion s'est présentée, j'ai été nommé chef d'équipe.
Les chefs d’équipe sont souvent créés au sein de l’entreprise, et il est important d’en tenir compte. S'il existe des perspectives d'évolution dans votre emploi actuel, vous devez prendre l'initiative et vous essayer au rôle de manager. Mais si toute l’équipe est front-end et back-end et que chacun est son propre chef d’équipe, il ne faut pas s’attendre à un miracle. Il est préférable de déménager dans une entreprise plus grande et d'indiquer qu'à l'avenir vous souhaitez occuper une position de leader. Vous aurez besoin de temps pour étudier les processus et comprendre la logique métier du projet. Mais lorsqu’un poste approprié se libère dans l’entreprise, ils vous choisiront probablement plutôt qu’un étranger.
Dans le poste de chef d’équipe, les compétences techniques et générales sont tout aussi importantes. Les développeurs savent généralement ce qui manque aux compétences techniques. De plus, ces exigences sont fortement liées à la spécialisation et à la pile technologique, il n’existe donc pas de liste universelle. Je parlerai des soft skills que je considère comme essentielles pour le produit et l'entreprise.
La rapidité et la qualité du développement, et donc le coût, dépendent des processus en place dans l'entreprise, mais ils sont rarement idéaux.
Par exemple, vous avez corrigé un bug et êtes prêt à présenter la version sur le stand, les affaires attendent. Mais pour ce faire, vous devez parcourir cinq pipelines et recueillir les approbations de toutes les personnes impliquées. Vous écrivez aux responsables - silence. Vous commencez à les tirer dessus, mais des messages formels arrivent juste pour répondre – tout le monde n'a pas le temps. Cela peut prendre jusqu'à six heures avant que la version corrigée n'arrive au stand. Et pendant tout ce temps que vous passez à essayer de joindre vos collègues, l’entreprise perd de l’argent.
Un autre exemple est le nombre exorbitant d’accès aux différents systèmes, programmes, stands et référentiels. Les banques en souffrent généralement. Une personne vient travailler, elle a besoin de comprendre le projet, mais pendant le premier mois et demi, elle ne peut rien faire du tout, car - c'est vrai - il n'y a pas d'accès. Un autre problème avec les accès est qu'ils sont nombreux et que leurs noms sont impossibles à retenir. Par exemple, au lieu de « accès au référentiel » dans le répertoire, il y aura A32B18KZ - essayez de le trouver.
Je connais des cas réels où un développeur n'a pas pu commencer à travailler pendant un mois ou deux. Pendant tout ce temps, il a reçu un salaire, mais a perdu ses illusions et a démissionné. Autrement dit, l'entreprise a passé six mois à chercher un employé, lui a versé un salaire pendant deux mois, puis a dû recommencer le processus de recrutement.
De tels problèmes dans les processus compliquent et ralentissent le travail. La tâche du chef d'équipe est de les voir et de comprendre exactement ce qui ne fonctionne pas bien et où la panne se produit.
Il est important non seulement de déceler les problèmes dans les processus, mais aussi de proposer des solutions. Vous pouvez résoudre vous-même certaines difficultés sans impliquer la direction. Par exemple, une équipe est aux prises avec un gestionnaire d’état peu pratique. Si le projet est petit ou juste au tout début, vous pouvez organiser un appel, trouver la meilleure option et expliquer comment introduire progressivement un nouveau gestionnaire d'État sans pertes. Une solution a été trouvée et l’entreprise n’était même pas au courant de l’existence du problème.
Mais la plupart des problèmes ne peuvent être résolus qu’avec l’aide de la haute direction. Par exemple, pour accélérer la sortie des builds sur le stand, vous pouvez identifier une personne qui a de bonnes relations dans tous les départements et a accès aux décideurs, et l'impliquer dans le processus d'approbation. S'il n'y a pas de retour de collègues d'autres services, il sait à qui écrire et peut mettre en place le processus manuellement. Mais un tel travail nécessite un poste distinct, vous devez donc obtenir l'approbation de la direction de l'entreprise.
Le problème d'accès est résolu de la même manière. La plupart des développeurs ont besoin des mêmes systèmes et programmes. Par exemple, pour les développeurs front-end - un référentiel, un stand, Jira, etc. Alors pourquoi ne pas leur créer un package d'accès standard et embaucher une personne qui leur demandera un petit salaire ? Mais cela nécessite également la volonté de la direction de l’entreprise.
Par conséquent, l'une des principales compétences d'un chef d'équipe est d'être capable de transmettre correctement l'essence du problème à l'entreprise. Il y a quelques secrets ici.
Une fois ne suffit pas . Les problèmes sont rarement résolus après le premier contact, il faut donc s'adresser à la direction à certains intervalles et lui rappeler le problème : « cela démoralise l'équipe », « nous perdons en productivité ».
Si vous voyez comment les problèmes de l'équipe et les intérêts commerciaux sont liés, cliquez ici . Par exemple, il y a eu un bug critique qui a pris deux jours pour être corrigé, même si cela n'a nécessité que quelques heures de travail, et en conséquence l'entreprise a perdu de l'argent. Vous allez voir la direction et parlez du problème de coordination des builds. Dans de tels moments, les entreprises sont aussi ouvertes que possible aux suggestions. Mais la solution doit déjà être prête.
Le moyen le plus sûr est de calculer combien coûte le problème à l’entreprise avant de le soumettre à la direction.
En tant que chef d'équipe front-end, je recueille régulièrement les commentaires des employés. Par exemple, les développeurs se plaignent constamment du fait que les tâches sont mal décrites. Pour cette raison, il faut beaucoup de temps pour découvrir ce que l'auteur du problème attendait d'eux. Ensuite, les testeurs viennent voir les développeurs et essaient de comprendre ce qui a été fait et ce qu'ils doivent tester exactement, et plus loin dans la chaîne. Du coup, chacun en comprend toujours l'essence à sa manière, et des bugs apparaissent.
J'ai calculé qu'en moyenne l'équipe consacre 40 % de son temps de travail à corriger les bugs. En collaboration avec l'équipe, nous avons mené une analyse rétrospective et avons découvert que la moitié de ces bugs sont survenus uniquement parce qu'ils avaient mal compris l'essence du problème. Autrement dit, 20 % du temps de travail des développeurs est perdu parce que les tâches sont mal décrites. C'est le numéro avec lequel vous devez vous adresser à la direction. Il est facile de le convertir en argent – le même langage que celui que comprennent les entreprises.
Lorsque les gens aiment travailler les uns avec les autres, toute interaction se déroule plus facilement. Pourquoi Scrum est-il si populaire ? Il ne s’agit pas de documentation mais de personnes. Parfois, il est plus efficace d'appeler un collègue pendant deux minutes que d'attendre deux jours pour qu'il documente sa réponse et tout décrive en détail. Ainsi, lorsqu'il existe une atmosphère de compréhension mutuelle et d'entraide au sein de l'équipe, il est plus facile pour les gens de se contacter. Par exemple, vous avez trouvé un morceau de code et vous ne comprenez pas ce qu'il fait. Si la situation dans l'équipe n'est pas bonne, vous aurez simplement peur d'appeler et de demander : « il pensera que je suis stupide ».
Pour entretenir de bonnes relations au sein de l'équipe, j'organise des appels d'une heure une fois par semaine. Nous divisons ce temps en trois parties. Le premier est « détendu ». Nous partageons des mèmes et des blagues. La deuxième partie est une discussion des problèmes. Parfois, nous jetons des cartes ensemble à Miro, ce qui n'est pas du goût de tout le monde. C’est ainsi que j’ai une idée de ce qui ralentit exactement les gars. Ensuite, nous pourrons proposer des options de solutions, sur lesquelles je ferai ensuite pression auprès de la direction. Et on termine à nouveau « détendu » : on peut discuter de cinéma ou d'autre chose. De telles réunions créent une atmosphère positive et me font, en tant que leader, comprendre les difficultés qui existent dans l'équipe.
Une erreur courante des nouveaux chefs d’équipe est de concentrer les processus de travail sur eux-mêmes. Dans ce cas, si le chef d'équipe tombe soudainement malade ou part en vacances, le travail commencera à s'arrêter et il sera constamment mis à pied. Pour éviter que cela ne se produise, vous pouvez apprendre à quelqu'un de l'équipe à assumer une partie des responsabilités de chef d'équipe. Par exemple, faites confiance aux autres pour distribuer les tâches une fois par mois. De cette façon, quelqu'un d'autre dans l'équipe aura cette compétence, et le chef d'équipe pourra partir en vacances sereinement, sachant que rien ne se cassera sans lui.
C'est peut-être un bon critère pour évaluer le travail d'un chef d'équipe : si vous êtes exclu de l'équipe, la marge de sécurité devrait être suffisante pour un mois.
En développement, une métrique telle que le facteur bus est utilisée pour gérer les risques sur un projet. Il montre combien de membres de l’équipe doivent être heurtés par un bus fictif pour faire échouer l’ensemble du projet. Si le facteur de bus = 1, vous avez de sérieux problèmes.
Par exemple, nous développons un projet complexe. Il dispose d'un module sophistiqué, et un seul développeur sait comment il fonctionne et sait comment le gérer. Si cette personne tombe malade, démissionne ou part en vacances, changer ce module se transformera en une procédure très longue et coûteuse, qui affectera négativement l'ensemble du projet. Pour éviter que cela ne se produise, vous devez progressivement apprendre aux autres employés à travailler avec des modules ou des bibliothèques complexes.
Le chef d'équipe doit être capable de répartir correctement les responsabilités au sein de l'équipe, sans confiner les processus à une seule personne, sans la rendre critique pour le projet.
Le chef d’équipe doit comprendre où va le projet, quels problèmes il rencontre et comment les résoudre. Par exemple, la charge de travail totale de l'équipe est de 100 heures de travail par semaine. Et l'entreprise présente ses vœux pendant 100 heures. En ce moment, la dette technique s'accumule sur le projet, qu'il est également temps de régler. La tâche du chef d'équipe est de suivre le moment avant que la dette technique ne devienne critique et de faire pression sur la direction afin que l'équipe consacre un certain pourcentage de son temps à résoudre les problèmes actuels.
Il est préférable de savoir dès le départ pourquoi les chefs d'équipe s'épuisent pour reconnaître les sonnettes d'alarme.
C'est le problème le plus courant lorsque, mois après mois, vous essayez de joindre la direction, vous présentez vos problèmes et une solution toute faite, mais au sommet, ils mettent simplement le problème dans l'arriéré et rien ne se passe. Il peut y avoir plusieurs raisons. La première est que vous parlez le mauvais langage aux entreprises et que vous devriez changer votre approche. La seconde est que votre patron « sait tout le mieux » et continue de tout faire à sa manière. Dans ce cas, la meilleure solution serait de changer d’entreprise.
Un exemple simple : votre équipe est constamment submergée de tâches, et il n’y a plus assez de mains. Les petites et moyennes entreprises n’ont peut-être tout simplement pas l’argent nécessaire pour embaucher de nouveaux employés. Dans ce cas, vous pouvez assumer un rôle supplémentaire, tel que celui d'analyste système, et commencer à décrire les tâches afin que le travail avance plus rapidement. Dans les grandes entreprises, il y a très probablement de l'argent, mais la chaîne de prise de décision est trop longue et rien ne garantit qu'un chat ne sera pas passé entre les patrons du troisième et du quatrième niveau et que le processus ne s'arrêtera pas à cause de cela. Ici, vous ne pouvez qu'essayer de gagner à vos côtés un membre de la haute direction ou simplement attendre.
Il arrive que vous arriviez dans une entreprise, que vous élaboriez une stratégie, que vous fassiez des projets et que vous soyez passionné par le travail, mais le temps passe et rien ne change. Il ne faut pas longtemps pour se décourager : « Qui a besoin de tout cela ? Dans ce cas, vous pouvez réaliser une analyse rétrospective pour comprendre pourquoi le projet n’avance pas. Demandez-vous : « Peut-être que je touche la mauvaise cible et que je résous les mauvais problèmes ?
Cela se produit lorsque vous êtes placé dans une position de leadership, doté de responsabilités, mais sans aucun levier de contrôle. Par exemple, il n'existe aucun moyen de mener des entretiens de manière indépendante et de recruter des développeurs pour rejoindre votre équipe. Il n'y a ici que deux options : soit essayer de contacter l'entreprise et lui indiquer votre position, soit changer d'entreprise.
Pour développer le produit et résoudre les problèmes actuels de l'équipe, le chef d'équipe doit être en contact constant avec les décideurs. Si l’accès au « sommet » est fermé, les problèmes resteront non résolus, les stratégies de développement prometteuses resteront tacites et la motivation pour travailler sera perdue. Pour ne pas s'épuiser, mieux vaut changer d'entreprise si l'on ne parvient pas à établir des relations avec la direction.
Parfois, les tâches sont trop nombreuses et l’équipe n’arrive plus à gérer le flux entrant. Dans une situation d'urgence constante, les appels réguliers passent au second plan - qui a besoin de mèmes et de bavardages vides quand cette heure peut être consacrée à éliminer les bugs ? En conséquence, toute l'équipe se transforme en un cheval de trait qui, tôt ou tard, s'essoufflera et les gens commenceront à partir. Tout ce que le chef d’équipe peut faire, c’est essayer de forcer l’expansion du personnel ou de mettre des tâches en file d’attente.
Cela peut arriver si vous rejoignez une équipe déjà constituée où tout le monde se déteste. Un style de communication toxique s'est déjà enraciné dans l'équipe, et il n'est pas question d'entraide. La seule chose à faire est alors de dissoudre toute l’équipe et de recruter à nouveau.
Quel que soit le problème, il y a toujours une chance d’obtenir une issue favorable. N'abandonnez pas après le premier échec. Cela vaut peut-être la peine d’attendre un peu ou de changer d’approche. Mais si vous avez tout essayé et que vous avez l’impression de vous heurter à un mur blanc, alors la décision de partir sera la seule bonne.
La capacité à résoudre des problèmes est une qualité importante d’un chef d’équipe. Mais hélas, cela ne marche pas toujours. Mais si vous sentez que vous marquez le pas depuis un an ou deux et que vous ne pouvez en aucun cas l'influencer, mais que vous souhaitez grandir, changer d'entreprise n'est pas une mauvaise idée. N'ayez pas peur du changement. Changer d'emploi est normal.