Bonjour, Habr! Je m'appelle Andrey Gomenyuk, je suis le chef d'équipe d'une des équipes de développement de serveur Badoo .

Lors du Meetup May Badoo Techleads , consacré à la gestion du développement, j'ai partagé l'expérience d' intégration des nouveaux arrivants dans l'équipe. Et aujourd'hui, je partage une version complétée et améliorée de mon rapport.

Imaginez aujourd'hui est votre première journée de travail chez Badoo. Quels types de connaissances et de compétences le ministère attend-il de vous, et en particulier de moi, le chef? Au moins tels:



Notez qu'il n'y a rien de tel que «écrire en PHP» et «connaître MySQL». Nous posons des questions à ce sujet lors de l'entretien. Et sur cette liste sont tous nos outils, technologies et termes, ainsi que des choses générales que nous n'aimons probablement pas tout le monde. Et plus tôt vous en saurez plus, mieux ce sera.

Intégration à Badoo

Le terme d' intégration signifie entrer une personne dans une équipe, l'initier au projet et aux processus. Étant donné que notre service de développement de serveurs a doublé au cours des deux dernières années (nous sommes maintenant plus de quarante), nous sommes devenus les premiers à Badoo à nous soucier de l'adaptation intensive des nouveaux arrivants et de leur intégration au travail.

Je souligne deux objectifs principaux de l'intégration.

Le premier est à court terme. Comme la plupart des sociétés informatiques, nous voulons vraiment mettre la personne sur le code le premier jour, mettre ses tickets en production la première semaine, afin que la personne s'y habitue le plus rapidement possible. Cependant, ce n'est pas l'essentiel pour nous.

Le deuxième objectif est à long terme. Nous voulons qu'une personne atteigne un certain niveau d' indépendance dès que possible et commence à résoudre efficacement les tâches.

Pour ce faire, nous guidons le débutant à travers cinq étapes peu explicites. Mais avant d'en parler dans l'ordre, je note deux points tout aussi importants.

Qui rencontrera le nouveau venu

Le premier jour ouvrable, nous sommes sûrs de rencontrer un débutant. Cela devrait être fait par le responsable, et nous, au ministère, essayons de respecter cette règle. Lead rencontre un homme, lui montre le bureau et le présente à l'équipe. Ensuite, une réunion pré-programmée est organisée avec la direction du personnel, au cours de laquelle les documents sont établis.


Source

Il semblerait qu'après cela, il soit déjà possible de mettre une personne à table, mais il y a un autre détail important.

Qui "dirigera" le débutant

Dans certaines entreprises, l'ensemble du processus d'intégration est «lié» aux mentors. Ce sont ces gens qui expliquent tout, montrent quoi, où et comment, répondent aux questions du débutant et le réunissent avec les bonnes personnes.

Nous n'utilisons pas un tel terme, mais, comme le dit la célèbre chanson, il y a un mentor, mais pas de mots. C’est juste que ce rôle est attribué au responsable, qui peut le déléguer à l’un des employés. En règle générale, un lead (ou une personne désignée par lui) est un point de départ pour un débutant sur toutes les questions. Au cours d'une courte réunion, il présente le nouveau venu au projet, parle des processus adoptés par l'entreprise. C'est le début du transfert de notre culture à une personne qui travaillait auparavant dans d'autres entreprises et qui a l'habitude de faire les choses différemment. Et il est très important que le débutant comprenne quoi, comment et pourquoi nous le faisons.

Les étapes de l'intégration

Je vais me permettre de décomposer l'ensemble de notre processus en plusieurs étapes, chacune ayant une sorte de résultat:

• homme assis devant un ordinateur portable
  
• avec un environnement de travail personnalisé
  
• et fait des billets.
  
• Peut concevoir une nouvelle fonctionnalité
  
• et travailler de façon indépendante.
  

Ensuite, réfléchissez à ce qui se passe à chaque étape.

1. Ordinateur portable

Premièrement, nous voulons que le débutant se concentre sur le travail, plutôt que de penser à quelque chose de peu important, et nous essayons de faire beaucoup à l'avance. Par conséquent, nous le contactons à l'avance et découvrons les souhaits pour l'équipement: ce que veulent le moniteur, l'ordinateur portable, le clavier, la souris. Nous créons tous les comptes pour les débutants et émettons des privilèges, les ajoutons aux groupes et aux chats. Beaucoup de ces procédures sont automatisées, tandis que d'autres sont inscrites sur des listes de contrôle afin que la personne ne court pas dans le bureau le premier jour, déterminant pourquoi elle ne peut pas entrer dans Jira ou pourquoi elle ne voit pas le ticket qui lui a été attribué.

2. Environnement de travail

Ensuite, la personne s'assoit devant l'ordinateur portable pour mettre en place un environnement de travail. Mais toute la configuration est qu'il va dans une interface spéciale, sélectionne un nom d'utilisateur et charge une clé SSH. C'est fait.

Le fait est que nous avons une plateforme de développement, un analogue de notre infrastructure de production, élevée au bureau. De plus, afin d'émuler plusieurs DC, nous avons une plateforme de développement dans les deux bureaux: à Londres et à Moscou. Cette approche présente de nombreux avantages. Le développeur a toujours la version actuelle du code et le dernier logiciel - absolument le même que dans la production. Même si quelque chose ne fonctionne pas, vous pouvez être sûr que quelqu'un résout déjà le problème. Le débutant, en fait, clone simplement le référentiel, ouvre l'IDE - et est prêt à travailler. Il suffit à Lida de s'assurer qu'il a pu entrer dans tous les chats et a commencé à recevoir du courrier.

A ce stade, je suis prêt à donner au débutant le premier ticket.

3. Billets

Disons que le premier ticket est venu comme ceci:



Ou comme ça:



Probablement, pour vous, ces billets n'ont qu'une chose en commun - rien n'est clair. J'ai surligné en orange les mots susceptibles de vous poser le plus de questions, et même si ce n'est pas le cas, je vous en parlerai quand même.

Comme avant

Quand je suis arrivé à Badoo il y a sept ans, c'était quelque chose comme ça. Lead s'assoit auprès du nouveau venu et commence à dire: «Écoutez, nous avons des files d'attente, un framework de script. Ils fonctionnent comme ça. Faites attention à cela. Dans ce ticket, vous devrez le faire . "

Le problème est que le responsable passe son temps de travail sur ces histoires. Chaque fois qu'il explique la même chose aux débutants, il oublie toujours quelque chose. Chaque piste raconte sa propre voie.

Naturellement, le responsable ne donnera que des notes d'introduction spécifiques sur le ticket qui se rapportent à ce ticket, manquant les points dont le débutant peut ne pas avoir besoin pour le moment. Si vous avez de la chance, ce dernier pourra trouver un lien vers une description d'un outil. Mais généralement, toute cette documentation est écrite pour un usage interne, c'est-à-dire qu'il est entendu que l'utilisateur connaît déjà les détails. La documentation contient beaucoup de détails dont le débutant n'a définitivement pas besoin dans les premières étapes. En conséquence, une situation paradoxale s'est développée: une personne a travaillé pendant un an ou deux dans l'entreprise, mais rien ne garantit qu'il s'est familiarisé avec tout et sait comment fonctionne l'ensemble de l'infrastructure.


Image du film Groundhog Day

En plus des collègues qui ont répondu à diverses questions, Aleksey Rybak, qui dirigeait alors la plateforme, a donné une conférence sur les principes de base, l'infrastructure et les services de base à tous les nouveaux employés. À un moment donné, il en avait assez et il l'a enregistré sur vidéo. Mais dans une histoire de deux heures, vous ne comprendrez pas tout, il y a beaucoup de détails. Et puis cette conférence est très difficile à mettre à jour. Bien sûr, c'est cool qu'en sept ans, il soit un peu dépassé, mais certaines parties ne sont plus pertinentes.

À un moment donné, quelqu'un a créé une nouvelle page de développeur Bienvenue sur le Wiki. Ils y ont jeté un tas de liens qu'il serait agréable de lire au développeur.

Je ne me trompe probablement pas beaucoup si je dis que dans toute entreprise, il existe deux principales sources d'obtention de nouvelles informations: il s'agit d'une sorte d'analogue Wiki (ou Google Docs) et d'un fumoir. Malheureusement, ce n'est que dans l'un d'entre eux que les informations seront à jour, et ce n'est pas un wiki.

Que notre page n'avait pas de structure commune. Il s'est reconstitué comme ça. Le chef d'une autre équipe s'approche de moi et me dit: «Andryukha, vos développeurs se portent mal. Pour bien faire, j'ai écrit un article sur le Wiki. Ajouté à la "Bienvenue nouveau développeur" afin que tous vos développeurs doivent le lire . "



Naturellement, il considère que son article est le plus important, le place à l'endroit le plus visible et le surligne en gras, rouge. En conséquence, une grande page avec un tas de liens dont il peut avoir besoin sera envoyée au débutant. Avec une abondance de phrases en gras , DOIT LIRE et "Lire requis!".

À un moment donné, nous avons réalisé que les conférences, les vidéos et les wikis ne nous convenaient plus. Nous avons décidé de tirer le meilleur parti de ces outils et de faire quelque chose de nouveau. Et il nous a donné la bonne idée ... le cadre Laravel. Ne comptez pas pour la publicité. C'est juste qu'à ce moment-là, nous prenions le framework pour un projet, dans le moteur de recherche du "meilleur framework PHP" Laravel est apparu en premier lieu, et nous l'avons eu. Et nous y avons vraiment aimé la section de documentation de démarrage rapide, qui décrit les principes de base et les outils disponibles sur un exemple réel (et, après avoir compris les bases, vous pouvez commencer à lire la description détaillée).

Démarrage rapide

Nous avons vraiment aimé ce format, et nous avons décidé d'écrire un article similaire pour nos débutants. Mais comment faire? Il y a beaucoup d'informations - comment maintenir un équilibre entre concision et informativité, tout en conservant la possibilité d'une mise à jour en temps opportun afin que les nouveaux arrivants n'aient pas à tirer des connaissances dans le fumoir? Et comment encourager la lecture d'un document de ceux qui travaillent dans l'entreprise depuis un certain temps, mais qui ont certainement des lacunes dans leurs connaissances?


Source

Nous avons commencé par dresser une liste d'outils, de technologies et d'approches que, selon nous, chaque développeur du département devrait connaître. Ils ont ensuite structuré les informations sous la forme d'une table des matières, du plus simple au plus complexe: des bases de données et des services aux performances et aux tests. Ensuite, une personne a écrit les premiers chapitres afin que d'autres puissent comprendre comment présenter le matériel. Après cela, nous avons volontairement distribué les autres sujets aux autres employés, et chacun a écrit un chapitre. Le résultat a été un énorme document, des semaines pour deux lectures seulement.

Nous n'avons pas pu proposer une tâche commune pour l'ensemble de la section Démarrage rapide. Oui, ce serait inefficace. Imaginez que vous confiez une tâche à une personne - en fait, une énorme fonctionnalité qui couvre toutes les sections. Il y travaillera pendant un mois ou deux, et pendant tout ce temps, vous ne pourrez pas le distraire avec des billets, ce qui contredit le premier objectif de l'intégration.

Ensuite, dans chaque section, nous avons placé une ou deux tâches aussi similaires que possible aux vraies. Un débutant lit une section, travaille sur des tâches, se familiarise avec des outils spécifiques. Nous recommandons à nos dirigeants d'effectuer certaines des tâches selon le processus standard: un ticket est émis, une personne pousse un code, un code est révisé, une personne reçoit beaucoup de commentaires. Après cela, la branche est supprimée et avec elle un ticket.

La question s'est alors posée de savoir comment maintenir la pertinence de l'ensemble de ces informations. Et ici, les mêmes tâches nous ont aidés. Par exemple, nous avons des spots (fragments virtuels) et un service chargé de comparer les utilisateurs et les spots. Dans la vie normale, les développeurs n'ont pas besoin de le savoir, car ils utilisent une API de haut niveau. Mais nous leur demandons de comprendre comment cela fonctionne en interne.

Nous donnons la tâche: enregistrer l'utilisateur sur le développeur, obtenir l'identifiant du spot à son adresse e-mail, obtenir les informations de la base de données sur place, y aller, sélectionner et voir ce qui s'y trouve. Si quelque chose change dans cette procédure, les développeurs ordinaires ne le sauront pas. Ils ne sauront pas que vous devez entrer et corriger la description. Mais le développeur qui est actuellement engagé dans cela comprendra: quelque chose ne va pas. Il montera en tête et dira que quelque chose ne fonctionne pas. Le responsable va s'asseoir avec lui, régler le problème - et nous mettrons à jour le document. Nous essayons de ne pas encourager les développeurs à modifier le démarrage rapide par eux-mêmes, afin de ne pas violer la structure et le style de présentation. Au lieu de cela, nous avons créé un document Google dans lequel ils peuvent écrire leurs souhaits. Cette liste est ensuite examinée par la personne responsable qui apporte des modifications à notre article.

De nouvelles informations sont ajoutées à Quick Start de la même manière: quelqu'un rencontre un nouvel outil qui n'est pas décrit dans le document et écrit à ce sujet dans Google Doc. Et les personnes responsables décident ensuite s'il s'agit d'un cas spécial qui n'est pas intéressant pour la plupart des développeurs, ou s'il vaut la peine d'écrire à ce sujet dans Quick Start.

Les développeurs eux-mêmes ajoutent parfois de «petites choses» sympas au document. Par exemple, un compteur pour la durée de lecture et le nombre de pages a été ajouté à chaque chapitre. Également dans certaines sections, des liens ajoutés qui ouvrent immédiatement la classe souhaitée dans PhpStorm.

Puis nous avons commencé à réfléchir, comment amener les personnes âgées à étudier le document? Après tout, Quick Start s'est avéré être énorme et personne ne voulait passer deux semaines à le lire. Ensuite, nous sommes arrivés à un test: sur la base du document, nous avons fait environ 100 questions sur différents sujets et tout le monde a été proposé de le passer de manière anonyme. Chaque développeur a eu le choix d'une quarantaine de questions. Le but n'était pas de tester les connaissances, mais d'aider les gens à comprendre ce qu'ils ne savaient pas. Autrement dit, le test était un outil d'apprentissage, pas un test, et si la question n'a pas été répondue correctement, des invites et des liens ont été immédiatement proposés où vous pouvez en savoir plus dans le démarrage rapide.


Un exemple d'une question d'un test

Nous ne contrôlons pas le passage du test par les débutants. On pense que ce sera pour eux la conclusion logique de l'apprentissage du démarrage rapide. Dans le même temps, nous conservons des statistiques sur toutes les réponses. Lorsque les «vieillards» ont réussi le test, nous avons sélectionné plusieurs questions auxquelles ils ne répondaient pas comme nous le souhaiterions et avons demandé à des gars expérimentés d'écrire des articles sur ces sujets.

Le démarrage et le test rapides sont la partie la plus impressionnante de notre processus d'intégration.

Plus de billets

Habituellement, avec Quick Start, une personne reçoit immédiatement un ou deux tickets simples. Progressivement, leur nombre augmente, et le responsable s'assure que les nouveaux tickets correspondent à ce que le développeur a réussi à se familiariser avec. Ainsi, le processus de lecture est dilué avec un vrai travail, et tout cela prend environ deux mois. Idéalement, à la fin de la période d'essai, la personne devrait bien connaître nos infrastructures, nos outils et nos approches.

Après avoir lu Démarrage rapide, la signification des billets ci-dessus deviendra beaucoup plus claire pour vous:



En tant que lead, je n'ai besoin que de me faire une petite introduction ici: il y a un champ dans le spot et un champ dans le service, ils ne sont pas synchronisés pour l'utilisateur; Vous devez corriger le bogue et synchroniser. Et le débutant sait déjà quel script exécuter et comment le faire.

Ou un deuxième exemple:



Voici la même chose: la photo s'est retrouvée dans le mauvais album; très probablement, le client a simplement envoyé le mauvais album; vous devez comprendre s'il existe encore de tels cas et y remédier.

Les billets, en effet, sont simples, pour une heure de travail.

4. Concevoir une nouvelle fonctionnalité

Par «concevoir», je ne veux pas dire l'organisation des classes et du code, mais comment le débutant va travailler avec les données, où il va créer des tableaux, quels événements il va ajouter, où ils seront transmis, à quels services une personne aura accès. À ce stade, le débutant est prêt à prendre des décisions techniques sur la façon dont les fonctionnalités sont créées. Ceci est généralement réalisé par la pratique. Plus il y a de tâches, plus il y a de connaissances et d'expérience.

Certes, ce n'est pas toujours possible, car il n'est pas possible de trouver un nombre suffisant de tâches intéressantes pour chaque débutant. Dans le test, ces sujets sont souvent difficiles à couvrir, car les situations sont différentes. Dans différents cas, vous devez accéder à différents services et partout à vos propres caractéristiques.

En conséquence, nous avons simplement collecté une douzaine de fonctionnalités vraiment importantes qui impliquaient divers services, files d'attente, spots, et les développeurs ont préparé de brèves descriptions pour eux (un analogue de la tâche technique). Lorsque le nouveau venu est prêt, le responsable lui donne le choix d'une tâche. Il y réfléchit pendant un certain temps et signale qu'il est prêt à discuter de la solution. Une réunion est prévue avec l'auteur de la fonctionnalité, au cours de laquelle le développeur explique son plan: il le ferait, ferait appel à un tel service, stockerait les données ici, souscrirait à de tels événements. En réponse, l'auteur raconte comment il a fait et ce sur quoi il a attiré l'attention. En conséquence, le développeur apprend beaucoup de nouvelles choses, il commence à prendre une vue d'ensemble. Il comprend comment fonctionne tel ou tel processus, comment nous prenons des décisions. Ce n'est pas grave s'il est entré dans le code à l'avance et a espionné la façon dont la fonctionnalité est implémentée, c'est encore plus probablement un avantage.

À la fin de la réunion, le responsable recueille des commentaires et peut proposer au développeur d'étudier attentivement une section et de réfléchir à ce qu'il a appris.

5. Travail indépendant

La cinquième étape, en fait, ne s'exprime en aucune façon. Ce sont les choses que nous faisons tout au long de notre travail dans l'entreprise. Nous apprécions vraiment la volonté du développeur de communiquer avec les autres équipes, de savoir comment ça marche. Si quelque chose ne fonctionne pas, vous devez savoir à qui vous adresser pour obtenir de l'aide. La tâche du responsable est de présenter le nouveau venu à tout le monde, de montrer qui est assis, de dire qui et dans quel cas vous pouvez contacter.


Source

Une personne doit être guidée dans nos processus. Bien que nous n'ayons pas Scrum et Agile, le flux de travail est assez flexible. Nous apprécions vraiment quand un développeur non seulement suit nos processus sans réfléchir, mais comprend pourquoi ils le sont et quelles tâches ils résolvent. Cela lui permet dans certaines situations de trouver des solutions de contournement. Par exemple, pour comprendre qu'un ticket particulier peut être envoyé sans effectuer de test complet, et que l'autre doit être fait plus rapidement. Nous disons à qui contacter et comment établir des priorités afin que le ticket fonctionne aujourd'hui.

Nous attendons du nouveau développeur qu'au cours de la période d'essai, il se familiarise avec l'ensemble maximal de nos fonctionnalités et composants. Idéalement, si au moment où la période d'essai se termine, il connaîtra une composante ou une caractéristique suffisamment profonde pour pouvoir l'accompagner.

Nous ajoutons également immédiatement une personne à l' évaluation des performances , juste pour qu'il puisse recevoir des commentaires non seulement de son responsable, mais aussi de toutes les personnes avec lesquelles il interagit: du produit, de l'assurance qualité et des équipes clientes.

Résumé

Voici peut-être les cinq principales composantes de notre processus de mise en service pour les débutants:

• Attention minimale à ce qui est sans importance. Nous faisons tout pour qu'une personne se concentre sur le travail et ne soit pas distraite par de petites choses (y compris) celles du ménage.
  
• Démarrage rapide.Nous n'avons pas osé y aller longtemps et avons pensé qu'il était impossible de le faire. Mais cela s'est avéré plus facile que nous ne le pensions, mais cela a déjà porté ses fruits à plusieurs reprises.
  
• Testez. En termes de rapport entre les avantages reçus et le temps passé, il perd quelque peu au démarrage rapide, mais est également un élément important du processus d'apprentissage.
  
• Tâches pratiques.
  
• Commentaires de l'équipe et du responsable. Plus c'est mieux.
  

Résultats

, . , , , «» .

. . - . , , — .


Source

Et ensuite

— Quick Start , , . Quick Start.

, . Quick Start , , , , , , . , - . , . , .

Enfin, rappelez-vous la première image avec un tas de termes? Vous avez probablement pensé: "Pourquoi tant de choses?" Il semble que tout soit trop compliqué pour nous et le développeur n'a probablement pas besoin de tout savoir. En lisant Quick Start, il est très facile de voir des choses qui peuvent être simplifiées, et nous travaillons dans ce sens.