Nicolas Le Borgne

Développeur

Acceuillir un nouveau développeur

Le 28 janvier 2022

La somme des intégrations de développeur que j'ai pu observer et les miennes m'ont permis de constater que parfois le sujet manquait de sérieux, non préparé, certains leads accueillent leur nouveau collègue sans matériel, sans trop savoir par où commencer, presque comme s'ils avaient oublié leur arrivée ...

J'ai eu l'opportunité de m'impliquer dans l'accueil de développeur et nous (moi et les autres personnes responsables) avons fait en sorte de prendre le sujet sérieusement, je tente de vous retransmettre les éléments qui ont fonctionné pour nous 💪.

La todo liste d'intégration

Nous avons fait le choix d'anticiper et formaliser tout ce qui pouvait l'être en considérant que l'intégration ne commence pas au premier jour de travail effectif, mais lors de la signature de la promesse. L'idée était que le jour J nous considérerions potentiellement ne pas avoir le temps de régler tous les détails en direct. Selon nous, ne pas avoir le temps de s'occuper d'un nouveau collègue le mettrait dans une posture peu agréable et ne le placerait dans une mauvaise dynamique pour suivre son processus d'intégration à l'équipe. Ce choix est motivé par des expériences où l'arrivant n'avait par exemple pas d'ordinateur. C'est assez peu entendable quand nous sommes au courant depuis 3 mois de son arrivée.

Dans cet état d'esprit, nous avons formalisé une liste de chaque élément nécessaire, en voici un exemple :

**Pré intégration**
- Fournir les outils
  - ☐ un bureau
  - ☐ une chaise
  - ☐ un ordinateur
  - ☐ licence IDE
  - ...
- Fournir les accès
  - ☐ un badge d'accès
  - ☐ un compte dans l'AD
  - ...
**Intégration (jour J+)**
- ☐ accueil dans l'équipe
- ☐ visite des locaux / présentation
- ☐ un compte Jira
- ☐ installation du poste (lien vers une documentation ?)
- acclimatation sur un projet en pair
  - ☐ clone d'un projet, tour du proprietaire
  - ☐ lancement des tests
  - ☐ déploiement (sans incrément et en test donc, mais au moins la procédure, méthode est vue !)
  - ☐ traiter un ticket selon vos méthodes de travail, peut être en pair pour le premier ?
  - ...
**Post intégration (J+ + X)**
- ☐ rapport d'étonnement
- ...

Voilà grossièrement l'idée, même si certain élément pourrait parraitre "bateau", cette liste nous permet de ne rien oublier, elle nous a également permis de mesurer le travail demandé, et ce que l'on peut anticiper ou pas.

Des projets au propre

Nous avons fait le ménage dans les README.md, en s'assurant que l'environnement de développement décrit était fonctionnel. Notre nouveau collègue n'arrive pas pour essuyer des plâtres, il doit être opérationnel rapidement et il a plus intéressant à faire que débugger un environnement de développement mal documenté ou cassé.

Nos repos ont tous la même interface, par exemple si vous utilisez les Makefile tous vos projets auraient un jeu de cibles identiques, exemple :

  • make install
  • make test
  • make lint

Peu importe la technologie ou la typologie du projet, l'idée générale étant que si le développeur sait globalement utiliser un projet, il le saura pour tous.

Le domaine métier

Ce qui part en prod c'est la compréhension des développeurs du domaine métier dans lequel on évolue. Il faut leur donner les moyens et l'envie de s'y intéresser !

Outre le spectre service de développement logiciel, notre entreprise (une entreprise de logistique industrielle) organise une semaine d'intégration pour les nouveaux collaborateurs leur donnant ainsi l'opportunité d'aller visiter et échanger sur des sites logistiques. En tant que développeur c'est un moyen formidable de nous rapprocher du métier. Il me semble que chez Sunday, une immersion en tant que serveur est utilisé !

Nous organisons également une présentation détaillée du ou des produits et roadmaps par les POs, toujours dans l'optique d'une immersion dans le métier.

La première tâche

On rentre dans le dur. En veillant le sujet, j'ai vu que certaines entreprises visaient un déploiement le plus tôt possible (pas en prod hein). Je trouve que c'est un super indicateur ! Le développeur ne peut pas maitriser un projet en 24h, en revanche il peut maitriser la procédure en place dans l'entreprise pour traiter un ticket. Si le développeur est capable de manipuler et déployer un projet, il aura déjà acquis une bonne portion d'autonomie. Nous avons fait le choix de traiter en pair la procédure, puis d'enchaîner sur un petit sujet à traiter, toujours en pair avec un senior pour accorder les violons en matière de méthode. Nous distinguons les deux pour éviter un flottement le temps que quelqu'un soit dispo pour le sujet de pair (même si ces disponibilités peuvent être anticipées), le développeur pourra commencer à étudier le sujet seul.

Documenter documenter documenter

J'ai toujours été très sceptique sur la documentation, pour moi le code faisait foi. Avant de me rendre compte que je cherchais peut-être à documenter les mauvaises choses. Pour avoir une documentation pertinente et à jour, il ne faut pas trop descendre trop bas dans les couches.

Nos projets ont donc une documentation principalement fonctionnelle, débordant un peu sur la technique avec des choses comme des contrats d'api ou des diagrammes de séquence pour les éléments un peu complexes.

On a également rédigé un "guide développeur" dans lequel on range des informations concernant notre organisation, nos outils et leurs installations, nos procédures, des patterns récurrents dans les projets etc... Ce guide contient également un annuaire des différentes adresses utiles en tant que salarié de l'entreprise mais aussi en tant que développeur : gestion des congés, mutuelle, intranet, jira, confluence, gitlab etc...

Si tout est écrit, nous sommes des êtres humains et privilégions toujours la communication directe et orale, l'écrit est là en secours quand le quotidien rend les gens moins disponible, ou pour créer une forme d'autonomie.

Cohésion

N'oubliez pas de créer des liens avec vos nouveaux collègues, le travail ne suffit pas forcément, et le tempérament de chacun ne rend pas toujours les choses très naturelles, une activité de cohésion régulière peut vous permettre de tisser des liens plus forts et la relation de travail n'en sera que meilleure.

À titre personnel je pense qu'un manager doit accepter de voir des instants de cohésion déborder sur du temps de travail. Ça peut faire grincer les dents, mais le soir bon nombre de gens ont envie de retrouver leur famille, aller au sport etc ... tout le monde n'est pas disponible pour aller boire un verre !

Chez nous le vendredi, on se trouve un créneau pétanque ! Ça peut très bien remplacer la pose café pendant laquelle on parle toujours trop boulot 😀.

Conclusion

Nos nouveaux collègues ont de la valeur, il faut le leur montrer ! D'autant que nous sommes dans un marché assez tendu en ce moment et qu'un cadre de travail anxiogène, désorganisé ou désagréable peut vite faire fuir les gens, et ils ont bien raison. J'espère que se partage pourra aider des développeurs à faire leur premier pas dans un nouvel environnement 🙃.

© 2021 Nicolas Le Borgne