Créer un département de juniors pour aider les équipes principales en utilisant uniquement Slack, Jira et blue tape

Créer un département de juniors pour aider les équipes principales en utilisant uniquement Slack, Jira et blue tape

La quasi-totalité de l'équipe de développement de Skyeng, composée de plus de 100 personnes, travaille à distance et les exigences en spécialistes ont toujours été élevées : nous recherchions des seniors, des développeurs full-stack et des middle managers. Mais début 2019, nous avons embauché pour la première fois trois juniors. Cela a été fait pour plusieurs raisons : l'embauche uniquement de super-spécialistes ne résout pas tous les problèmes, et pour créer une atmosphère saine dans le développement, il faut des personnes de différents niveaux de professionnalisme.

Lorsque vous travaillez à distance, il est extrêmement important qu'une personne vienne au projet et commence immédiatement à apporter de la valeur, sans longs processus d'apprentissage ni de développement. Cela ne fonctionne pas avec les juniors et, en plus de la formation, cela nécessite également une intégration compétente du nouveau venu dans l'équipe, car tout est nouveau pour lui. Et c'est une tâche distincte pour le chef d'équipe. Par conséquent, nous nous sommes concentrés sur la recherche et l’embauche de développeurs plus expérimentés et établis. Mais au fil du temps, il est devenu évident que les équipes composées uniquement de développeurs seniors et full-stack ont ​​leurs propres problèmes. Par exemple, qui effectuera des tâches routinières mais obligatoires qui ne nécessitent pas de super qualifications ni de connaissances particulières ?

Auparavant, au lieu d'embaucher des juniors, on bricolait des freelances

Alors qu'il y avait peu de tâches, nos messieurs ont serré les dents et se sont chargés de ces tâches sans intérêt, car le développement doit avancer. Mais cela ne pouvait pas durer longtemps : les projets se multipliaient, le nombre de tâches simples et routinières augmentait. La situation ressemble de plus en plus à une plaisanterie lorsque les clous sont enfoncés avec un microscope au lieu d'un marteau. Pour plus de clarté, vous pouvez vous tourner vers l'arithmétique : si vous attirez une personne dont le taux est de 50 $/heure conditionnelle pour effectuer un travail qu'un employé avec un taux de 10 $/heure peut effectuer, alors vous avez des problèmes.

La chose la plus importante que nous avons apprise de cette situation est que le paradigme actuel consistant à recruter uniquement des spécialistes de haut niveau ne résout pas nos problèmes liés aux tâches de routine. Nous avons besoin de quelqu'un qui soit prêt à accomplir un travail que des messieurs chevronnés perçoivent comme une punition et qu'il est tout simplement inefficace de leur confier. Par exemple, écrire des robots pour les chats Slack de nos professeurs et créateurs de cours, ou entreprendre de petits projets d'amélioration pour des besoins internes, pour lesquels les développeurs n'ont constamment pas assez de temps, mais avec lesquels la vie deviendrait beaucoup plus agréable.

À ce stade, une solution provisoire a été élaborée. Nous avons commencé à impliquer des indépendants dans nos projets. Des tâches simples et non urgentes ont commencé à faire l'objet d'une telle externalisation : corriger quelque chose quelque part, vérifier quelque chose, réécrire quelque chose. Notre aile indépendante connaît une croissance assez active. L'un de nos chefs de projet a collecté les tâches de différents projets et les a réparties entre les pigistes, guidés par la base d'interprètes existante. Ensuite, cela nous a semblé une bonne solution : nous avons soulagé les seniors et ils ont pu à nouveau créer à leur plein potentiel, au lieu de bricoler quelque chose de basique. Bien sûr, il y avait des tâches qui, en raison de secrets commerciaux, ne pouvaient pas être déléguées à des artistes externes, mais ces problèmes étaient plusieurs fois moindres par rapport à la masse de tâches confiées au travail indépendant.

Mais cela ne pouvait pas durer éternellement. L’entreprise était confrontée au fait que la division freelance était devenue un monstre maladroit. Le nombre de tâches simples et routinières a augmenté avec les projets et, à un moment donné, elles étaient devenues trop nombreuses pour pouvoir les répartir efficacement entre les acteurs externes. De plus, un freelance n'est pas immergé dans les spécificités des projets, et c'est une perte de temps constante lors de l'onboarding. Évidemment, lorsque votre équipe compte plus de 100 développeurs professionnels, vous ne pouvez pas embaucher ne serait-ce qu'une cinquantaine de freelances pour les aider et gérer efficacement leurs activités. De plus, l'interaction avec des indépendants implique toujours certains risques de non-respect des délais et d'autres problèmes d'organisation.

Il est important de noter ici qu’un salarié à distance et un freelance sont deux entités différentes. Un travailleur à distance est entièrement inscrit auprès de l'entreprise, a des horaires de travail désignés, une équipe, des supérieurs, etc. Le freelance est un travail basé sur des projets qui n'est principalement réglementé que par des délais. Un freelance, contrairement à un employé à distance, est majoritairement livré à lui-même et a peu d’interactions avec l’équipe. D’où les risques potentiels liés à l’interaction avec de tels artistes.

Comment nous en sommes arrivés à créer le « département des tâches simples » et ce que nous avons accompli

Après avoir analysé la situation actuelle, nous sommes arrivés à la conclusion que nous avons besoin d'employés moins qualifiés. Nous ne nous sommes pas fait l'illusion que parmi tous les juniors, nous élèverions de futures superstars, ni que l'embauche d'une douzaine de juniors nous coûterait trois kopecks. De manière générale, en ce qui concerne la situation des juniors, la réalité est la suivante :

  1. À court terme, il n’est pas économiquement rentable de les embaucher. Au lieu de cinq à dix juin « maintenant », il est préférable de prendre un senior et de lui payer des millions d'argent pour un travail de qualité plutôt que de gaspiller des budgets pour les nouveaux arrivants.
  2. Les juniors ont une longue période d'entrée dans le projet et de formation.
  3. Au moment où un junior a appris quelque chose et semble devoir commencer à « travailler » sur lui-même au cours des six premiers mois de travail, il doit être promu au niveau intermédiaire, ou il part pour ce poste dans une autre entreprise. L'embauche de juniors ne convient donc qu'aux organisations matures qui sont prêtes à y investir de l'argent sans garantie de réaliser un profit à court terme.

Mais nous avons grandi au point où nous ne pouvons plus avoir de juniors dans l'équipe : le nombre de tâches ordinaires augmente, et y consacrer les heures de travail de professionnels chevronnés est tout simplement un crime. C'est pourquoi nous avons créé un département spécifiquement destiné aux développeurs juniors.

La période de travail dans le service des tâches simples est limitée à trois mois, c'est-à-dire qu'il s'agit d'une période d'essai standard. Après trois mois de travail rémunéré à temps plein, le nouveau venu soit rejoint une équipe qui souhaitait le voir dans ses rangs en tant que développeur junior, soit on se sépare de lui.

Le département que nous avons créé est dirigé par un PM expérimenté, chargé de répartir les tâches de travail entre les juniors et de leur interaction avec les autres équipes. June reçoit une tâche, la termine et reçoit des commentaires de l'équipe et de son responsable. Au stade du travail dans le département des tâches simples, nous n'attribuons pas les nouveaux arrivants à des équipes et des projets spécifiques - ils ont accès à l'ensemble du pool de tâches en fonction de leurs compétences (nous recrutons actuellement des front-ends AngularJS, des backers PHP, ou recherchons pour les candidats au poste de développeur web dans les deux langues) et peut travailler sur plusieurs projets à la fois.

Mais tout ne se limite pas à l'embauche de juniors : ils doivent également créer des conditions de travail acceptables, et c'est une tâche complètement différente.

La première chose que nous avons décidée était un mentorat volontaire d'un montant raisonnable. Autrement dit, outre le fait que nous n'avons forcé aucun des spécialistes existants à encadrer, il a été clairement indiqué que la formation d'un nouveau venu ne devrait pas remplacer le travail principal. Non « 50 % du temps nous travaillons, 50 % nous enseignons aux juniors ». Pour avoir une idée précise du temps que prendrait le mentorat, un petit « curriculum » a été élaboré : une liste de tâches que chaque mentor devait accomplir avec son mentoré. La même chose a été faite pour le chef de projet junior, et nous avons ainsi obtenu un scénario très fluide et compréhensible pour préparer les nouveaux arrivants et les mettre au travail.

Nous avons fourni les points suivants : tester les connaissances théoriques, préparé un ensemble de matériel si un junior a besoin d'apprendre quelque chose et approuvé un principe unifié de conduite de révisions de code pour les mentors. A chaque étape, les managers donnent un feedback au nouvel arrivant, ce qui est extrêmement important pour ce dernier. Un jeune salarié comprend dans quels aspects il est fort et dans lesquels il doit être plus prudent. Pour simplifier le processus d'apprentissage pour les développeurs juniors et expérimentés, un chat commun a été créé dans Slack, afin que d'autres membres de l'équipe puissent rejoindre le processus d'apprentissage et répondre à une question à la place d'un mentor. Tout cela fait du travail avec les juniors un processus totalement prévisible et, surtout, contrôlé.

A la fin de la période probatoire de trois mois, le mentor mène un dernier entretien technique avec le junior, à l'issue duquel il est décidé si le junior peut ou non accéder à un emploi permanent dans l'une des équipes.

En tout

À première vue, notre département junior ressemble à un incubateur ou à une sorte de bac à sable spécialement créé. Mais en fait, il s'agit d'un véritable département doté de tous les attributs d'une équipe de combat à part entière qui résout des problèmes réels et non de formation.

Mais le plus important est de donner aux gens un horizon concret. Le département des tâches simples n’est pas un vide infini dans lequel vous pouvez rester coincé pour toujours. Il y a un délai clair de trois mois pendant lequel un junior résout des problèmes simples sur des projets, mais peut en même temps faire ses preuves et rejoindre une équipe. Les nouveaux arrivants que nous embauchons savent qu'ils auront leur propre chef de projet, un mentor senior (ou peut-être plusieurs) et la possibilité de rejoindre pleinement l'équipe, où ils seront les bienvenus et les bienvenus.

Depuis le début de l'année, 12 juniors ont été embauchés dans le département des tâches simples ; seuls deux n'ont pas réussi la période probatoire. Un autre gars ne rentrait pas dans l'équipe, mais comme il est très compétent en termes de travail, il a été renvoyé au service des tâches simples pour un nouveau mandat, au cours duquel, nous l'espérons, il trouvera une nouvelle équipe. Travailler avec des juniors a également eu un impact positif sur nos développeurs expérimentés. Certains d'entre eux, après une période de mentorat, ont découvert la force et l'envie de s'essayer au rôle de chef d'équipe ; d'autres, en regardant les juniors, ont amélioré leurs propres connaissances et sont passés de la position de milieu à la position de senior.

Nous ne ferons qu'élargir notre pratique d'embauche de jeunes développeurs car elle apporte de nombreux avantages à l'équipe. Les Junes, quant à eux, ont la possibilité d'exercer un emploi à distance à part entière, quelle que soit leur région de résidence : les membres de nos équipes de développement vivent de Riga à Vladivostok et supportent bien le décalage horaire grâce à des processus rationalisés au sein de l'entreprise. Tout cela ouvre la voie à des personnes talentueuses qui vivent dans des villes et villages reculés. De plus, nous ne parlons pas seulement des écoliers et des étudiants d’hier, mais aussi de personnes qui, pour une raison quelconque, ont décidé de changer de métier. Notre junior pourrait tout aussi bien avoir 18 ou 35 ans, car junior est une question d'expérience et de compétences, mais pas d'âge.

Nous sommes convaincus que notre approche peut être facilement étendue à d'autres entreprises qui utilisent un modèle de développement à distance. Il vous permet simultanément d'embaucher spécifiquement des juniors talentueux de n'importe où en Russie ou dans la CEI, tout en améliorant les compétences de mentorat de développeurs expérimentés. Financièrement, cette histoire est extrêmement peu coûteuse, donc tout le monde y gagne : l'entreprise, nos développeurs et, bien sûr, les juniors qui n'ont pas besoin de déménager dans les grandes villes ou les capitales pour faire partie d'une équipe expérimentée et travailler sur des projets intéressants. .

Source: habr.com

Ajouter un commentaire