Nouvel employé - mort ou vivant

Bonjour à tous! Je continue de parler d'expérience de gestion en informatique. Aujourd'hui, nous allons parler de l'introduction d'un nouvel employé dans l'équipe. Vous avez engagé un ingénieur. Quand deviendra-t-elle une unité de combat à part entière? Que faire pour accélérer son adaptation? Comment optimiser ce processus? Après tout, cela vaut-il la peine d'y prêter attention et de passer du temps?


Je vais commencer par la réponse à la dernière question: certainement oui. Quelle que soit l'expérience du spécialiste, il a besoin de temps pour se plonger dans les détails techniques d'un projet particulier, se familiariser avec le processus de développement et enfin rencontrer de nouveaux collègues. C'est vraiment important pour l'entreprise: plus vite elle commence à résoudre complètement les problèmes, plus vite elle commence à bénéficier à l'entreprise.

Je crois que l'entrée d'un nouvel employé dans l'équipe est un processus extrêmement important, et plus il est débogué, plus vite le nouveau venu devient un employé à part entière et moins vous y passez de temps.

Transformation du débutant au collègue

Lorsque j'ai travaillé dans un agrégateur de service de pièces détachées d'occasion, il a fallu 3 jours pour présenter de nouvelles personnes à l'équipe. Après cela, eux et les autres ont résolu les tâches actuelles sur un pied d'égalité, ont participé à des discussions et ont plaisanté avec des collègues de la machine à café. Mais je n'y suis pas venu, bien sûr, tout de suite, au début, j'ai dû combler les bosses et acquérir de l'expérience. Ce n'est qu'alors que j'ai formé les principes de base pour moi et construit le processus.

Voici les principales nuances que j'ai apprises par moi-même de la pratique de la gestion d'équipe.

1. L'inscription d'une personne dans une équipe doit commencer par une introduction au projet. Et je l'ai déjà fait lors de l'entretien. J'avais toujours préparé une histoire de 10 minutes sur l'entreprise dans son ensemble, ce qu'elle gagne, le fonctionnement du service, la structure des départements et plus encore.
2. Préparation du lieu de travail et création de conditions de travail confortables. Le premier jour, une personne doit s'asseoir à son bureau avec une chaise ou un fauteuil confortable et allumer un ordinateur déjà configuré. Vous n'avez pas le temps de préparer tout cela? Votre cant, cela a vraiment besoin d'attention.
3. Approche individuelle. Par exemple, pour créer du confort (et c'est nécessaire, surtout dans des conditions de stress lors du passage à un nouvel emploi). Il est agréable de poser des questions sur les préférences en termes de système d'exploitation et de clavier / souris. Vous serez peut-être le premier employeur à offrir cela. Et cela fera monter votre entreprise aux yeux de l'employé.
4. Bonne connaissance de l'équipe. Il ne suffit pas d'imaginer les noms de tous les employés et d'aller sur les lieux de travail. Vous pouvez le faire: c'est Misha, il est responsable du backend, c'est Petya, il est DevOps, et Vasya et Kolya sont responsables de la partie client, on peut leur poser des questions sur tel ou tel aspect. Et tout cela devrait se refléter dans la documentation officielle pour les employés, mais plus à ce sujet ci-dessous.
5. Connaissance de l'entreprise. Je pense qu'il est préférable de le conduire dans les départements et de dire comment l'organisation est organisée à l'intérieur, comment l'interaction entre les employés est établie. Il sera utile à l'avenir.
6. Gen. Un nouvel ingénieur doit savoir ces choses insignifiantes, où sont les toilettes, comment utiliser une machine à café et où vous pouvez chauffer les aliments. Un grand pas vers des relations plus étroites avec ses collègues est de l'inviter à dîner avec l'équipe.
7. Les principes de l'équipe. Partout ses propres termes et conditions. Par exemple, il était habituel pour notre équipe de travailler selon un horaire flexible, n'importe qui pouvait venir à un moment opportun pour lui ou prendre une journée de travail ou de travail à domicile. Mais en cas de libération ou de situations d'urgence, nous avons persisté et résolu le problème ensemble. L'équipe avait également une atmosphère amicale, nous nous sommes traités avec respect et nous attendions cela des nouveaux arrivants.

En général, je n'ai pas découvert de secrets, mais ces aspects sont vraiment d'une grande importance. La première impression est très importante, c'est de lui que la personne se fera une opinion sur l'entreprise et sa place dans celle-ci.

Un autre facteur crucial est la réduction du stress. C'est inévitable, car la transition vers un nouvel emploi est un moyen de sortir de la zone de confort, tout le monde est différent, tout le monde ne sait pas bien y faire face. Votre tâche consiste à lisser le processus d'adhésion d'une personne à l'équipe. Et ici, l'attention aux détails est importante. Par exemple, une personne peut être timide pour demander de remplacer un clavier inconfortable. Ou si vous voyez qu'il est un introverti, soyez plus délicat et ne le mettez pas sous les projecteurs au centre de l'arène de l'espace ouvert lorsque vous rencontrez une équipe.

Comment charger rapidement un débutant dans un projet et ne pas le tuer

Un homme est venu travailler avec vous, vous l'avez présenté à des collègues et à l'entreprise dans son ensemble, créé des conditions confortables. Il est temps de se mettre au travail. Après tout, votre tâche consiste à l'impliquer dans le processus de développement et à commencer à bénéficier à l'entreprise le plus rapidement possible. Et dans cette situation, l'essentiel n'est pas de trier rapidement. Plongez en douceur le collègue nouvellement créé.

Voici donc les principales étapes qui me permettent de transformer rapidement et sans douleur un débutant en membre à part entière de l'équipe.

1. Histoire du projet. Je crois que vous devez d'abord parler du projet du point de vue des clients. Pourquoi est-il nécessaire, comment fonctionne-t-il, quels problèmes résout-il? Et c'est seulement alors que nous pouvons passer à ce qui est «sous le capot» et montrer comment il est disposé à l'intérieur. Pour gagner du temps, vous pouvez enregistrer une vidéo une seule fois. Il suffit de contrôler sa pertinence. Si vous ne pouvez pas le faire vous-même, confiez la tâche à vos collègues.
2. Structure du projet. Il est important de montrer en quoi consiste votre service, quels modules incluent, comment ils interagissent les uns avec les autres.
3. Base de connaissances. Assurez-vous d'écrire de la documentation technique. Elle sera un rayon de lumière et un guide de la nature sauvage de votre projet pour un débutant. Cela devrait être tout: des principes de nommage des branches et des règles de création de pull request dans Git à la description de l'infrastructure du serveur et un ensemble d'outils techniques.
4. Relever le projet. Aidez le nouveau venu à déployer le projet, ne le laissez pas tomber à ce stade. Même un programmeur expérimenté peut enregistrer avant une telle tâche lorsque tout y est confus. Pour accélérer ce processus, écrivez des instructions. Mais vous pouvez gagner encore plus de temps si vous le faites à l'avance et configurez le processus d'assemblage du projet lui-même.
5. Du simple au complexe. En deux jours, racontez tout, puis jetez le nouveau venu dans l'embrasure et forcez-le à couper de nouvelles fonctionnalités complexes? Super plan pour échouer. Les ressources du cerveau humain ne sont pas illimitées; introduisez-le progressivement. Passez un peu de temps et choisissez-lui des tâches de plus en plus complexes, amenez-le progressivement au niveau de difficulté souhaité.

Encore une fois, je n'ai rien dit de nouveau, mais pour une raison quelconque, de nombreuses entreprises continuent de commettre de telles erreurs. Et puis ils sont surpris qu'une personne avec une grande expérience fasse des erreurs ennuyeuses. Il est logique de tirer mon analogie préférée avec le sport: un joueur professionnel sait comment botter le ballon et passer habilement, mais sans connaissance des tactiques et de la stratégie de l'équipe, cela n'aura aucun sens et les résultats. C'est pourquoi un entraîneur est nécessaire pour aider le joueur à faire partie de l'équipe. Si vous êtes un chef d'équipe, l'introduction de nouvelles personnes dans l'équipe devrait vous incomber. Manque de temps et autres raisons, ce ne sont que des excuses. C'est un processus vraiment important que personne ne résoudra pour vous.

Histoires de vie

Ci-dessous, je partagerai des cas instructifs de ma propre pratique. Je n'ai pas non plus réussi à déboguer le processus immédiatement, je suis allé à travers des erreurs.

À propos de soulever un projet

Lorsque mon équipe était très petite, pour les nouveaux employés, nous avons levé tous les services à partir de zéro sur chaque machine. Bien sûr, j'y ai passé beaucoup de temps ou je l'ai pris à mes collègues quand je leur ai demandé de m'aider. Avec la croissance de l'entreprise et du service informatique, cela est devenu un casse-tête.

J'avoue, j'ai raté ce moment. De plus, cela a causé des problèmes non seulement aux débutants. Lorsque l'un des employés a dû augmenter le service qu'une autre équipe écrivait, il était prêt à se tirer dessus. Et si tout de suite il fallait en lever une dizaine? J'ai radicalement décidé de la situation: j'ai transféré toute l'infrastructure à Docker. Oui, ce n'était pas facile, nous avons dépensé beaucoup de temps et d'efforts, mais une grande partie a été économisée à l'avenir. Nous avons sélectionné les configurations de projet optimales et chacun a fourni des instructions détaillées sur la façon de déployer et d'augmenter.

En conséquence, l'ensemble de nos 15 services internes ont été déployés en 20 à 30 minutes. Autrement dit, les nouveaux arrivants ont sauté sans douleur l'une des étapes de l'adaptation dans un nouvel endroit. Beaucoup ont même été surpris de se souvenir de leur expérience passée. Ce fut le meilleur éloge pour moi. Soit dit en passant, je connais de nombreuses entreprises dans lesquelles les nouveaux arrivants ont été jetés seuls avec le projet, et ils ont dû passer une semaine entière à les élever!

À propos de la documentation

Probablement, comme tout le monde, au début du projet, nous n'avions aucune documentation. Et même si l'équipe était petite et le service modeste en fonctionnalités, il n'y a eu aucun problème. Mais après deux ans, lors du passage à d'autres parties du projet, les développeurs eux-mêmes ne comprenaient pas comment fonctionnaient ces éléments du service qu'ils n'avaient pas touchés depuis longtemps. Il était encore plus difficile de parler du projet aux nouveaux employés. Surtout quand il se compose de 15 services qui fonctionnent de différentes manières et sur différentes technologies.

Au premier stade de la résolution du problème, des vidéos de formation ont été enregistrées pour tous les employés de tous les services. Les programmeurs étaient autorisés à tout regarder afin de comprendre comment le travail des services était organisé du point de vue de l'utilisateur. Cela a permis de gagner beaucoup de temps, il n'a pas été nécessaire de parler longtemps, 10 minutes ont suffi pour répondre aux questions après la visualisation.

Ensuite, nous avons préparé la documentation en deux versions: pour les débutants et étendue pour tout le monde. Le premier était essentiellement une simple feuille de triche pour la première étape de l'introduction d'une personne dans l'équipe, où les nouveaux arrivants pouvaient trouver toutes les choses les plus importantes. Et la deuxième version étendue, tout le monde l'a déjà utilisée. Tout y était décrit: de l'architecture et des instructions de déploiement des projets aux subtiles nuances techniques de l'utilisation de certaines technologies. Plus tard, ils ont créé un autre grand document décrivant l'interaction de tous les composants de notre système commun.

Nous pouvons dire qu'au début, il n'y avait pas de recherche sur le grand quai, c'était extrêmement gênant à utiliser, donc tout a été transféré vers le moteur Wiki. Avec une bonne organisation, et cela n'a pas été possible du premier coup, tout s'est avéré très pratique et abordable. Plus tard, nous avons ajouté des documents supplémentaires pour différents départements. Et puis notre documentation est devenue une base de connaissances complète. Par exemple, vous devez configurer la réplication sur certains services, vous trouverez l'article nécessaire avec des instructions et des exemples.

Chaque employé pouvait ajouter et modifier des documents, il y avait des personnes responsables qui surveillaient la pertinence des informations, mais presque tout le monde était impliqué dans le processus d'une manière ou d'une autre. Il est important de noter un point clé ici - la connaissance ne doit pas être verrouillée sur une seule personne, c'est le chemin vers nulle part. Il peut tomber malade ou arrêter de fumer, puis en son absence un effondrement de l'information peut se produire.

J'ai déjà quitté cette entreprise il y a longtemps, mais la base est vivante, les employés l'utilisent constamment.

À propos du confort

Une fois que j'ai moi-même trouvé un nouveau travail en tant que programmeur ordinaire, j'ai été satisfait quand ils ont essayé de créer des conditions confortables et ont tout expliqué. Mais c'est quand ils les ont simplement plantés sur le lieu de travail et les ont laissés seuls avec le projet. C'était terriblement enragé. Mais la direction n'a pas vu cela comme un problème.

En me souvenant de mon expérience, j'essaie toujours d'écouter les gens et de créer des conditions confortables. Par exemple, il était tel qu'une personne n'avait pas de bons écouteurs antibruit ou une chaise avec support dorsal. Dans ma pratique, il y avait même une histoire quand un programmeur est venu en PHP, mais au fond, il voulait faire du JS. J'étais en train de réformer le département, et la personne avait une excellente motivation et des yeux brûlants. En conséquence, je l'ai transféré à un poste différent, tout le monde était satisfait.

Les gars qui sont venus dans mon département ont vraiment apprécié cette attitude. Ils ont dit que tout était très compliqué avec nous, mais grâce à une telle introduction au déroulement du travail et à l'aide d'autres employés, ils ont rapidement maîtrisé l'équipe.

Je crois que beaucoup de bonnes communications et une atmosphère amicale dans l'équipe aident beaucoup. Le chef d'équipe devrait vivre avec l'équipe, le CTO avec TL et les processus, probablement seulement alors il y aura une idylle.

Essai de projet

Il y a de tels cas malheureux lorsqu'une nouvelle personne est embauchée dans l'entreprise, mais déjà en cours de travail, il s'avère que soit il ne convient pas au projet, soit le projet ne lui convient pas pour une raison quelconque. Bien sûr, la situation n'est pas ordinaire, mais parfois cela arrive.

Pour minimiser les risques pour les deux parties, j'ai introduit une pratique telle qu'une journée de test. Nous avons utilisé cette approche en cas de doute. Autrement dit, un spécialiste pourrait travailler un jour pour essayer un nouveau projet pour lui, pour voir comment tout fonctionne. À son tour, même en si peu de temps, nous pourrions l'évaluer de manière exhaustive.

Un ingénieur peut avoir de nombreuses raisons pour lesquelles il n'aime pas le projet. Par exemple, il peut ne pas vouloir travailler avec Legacy, il peut ne pas aimer les approches de développement, et enfin, l'atmosphère dans l'équipe peut ne pas lui convenir. Et il arrive qu'une personne n'ait pas assez de ces raisons pour partir après une période d'essai. Il reste, mais ressent de l'inconfort ou du mécontentement.

Pour exclure de telles situations, nous avons passé des jours de test. Les gens ont juste pris un congé et sont venus chez nous pour essayer de travailler. Dans ce cas, il y avait encore moins de temps pour se familiariser avec le projet, nous les avons donc initiés au déroulement d'un programme accéléré. Cela a payé: en cas de doute après l'entretien, nous avons pris la bonne décision avec le candidat. Ainsi, il n'a pas risqué de perdre son emploi actuel et de se lancer dans un projet qu'il n'aimait pas, et nous avons économisé beaucoup de ressources si la personne ne devenait finalement pas membre de l'équipe. Soit dit en passant, une approche similaire est utilisée par certaines autres sociétés.

Conclusions

Dans différentes entreprises, les flux de travail sont très différents, mais partout aussi ont leur propre spécificité et architecture. Par conséquent, même les professionnels exigeants ont besoin de temps pour s'adapter. Votre tâche est de la rendre la plus efficace et de la réduire au maximum dans le temps. Par conséquent, il vaut la peine de consacrer du temps au débogage d'un tel processus comme l'entrée d'un nouvel employé dans une équipe. Si vous n'avez pas pris de mesures dans ce sens, essayez de le faire dès que possible. Cela vous fera gagner beaucoup de temps à l'avenir. Et peu importe le nombre de personnes qui travaillent dans l'entreprise, 10 ou 1 000. Il est également important de comprendre que s'il n'y a personne pour le faire, la responsabilité incombe toujours au chef d'équipe.

Mon équipe a réussi à réduire le temps de saisie à trois jours! Après un si court laps de temps, une personne a rejoint l'équipe et a entrepris les tâches en cours. Il n'y a pas de recette universelle, dans chaque situation votre plan fonctionnera. Mais à mon avis, les aspects clés sont une préparation minutieuse pour le recrutement de nouveaux employés (documentation, configuration de l'environnement, matériel), la création de conditions confortables, une connaissance compétente du projet et le soutien de collègues et, bien sûr, du chef d'équipe.

PS Et si vous avez des histoires intéressantes, drôles ou instructives sur la façon dont vous avez été présenté à l'équipe? Gravez dans les commentaires! :)

Mes autres articles sur la gestion informatique:

Qu'est-ce qu'un chef d'équipe
Une équipe de rêve à partir de rien: embauche de professionnels de l'informatique
Comment créer et gérer des équipes performantes
Grandir, chef d'équipe, petits et grands