Toute équipe et a fortiori, toute équipe informatique, est déstabilisée par un départ ou une arrivée. Cela est d'autant plus vrai que les membres de l'équipe travaillent depuis longtemps ensemble et s'apprécient: ils connaissent les forces et les faiblesses de chacun, s'entraident les uns les autres, se voient parfois en dehors du travail, etc. L'arrivée d'un nouveau collègue peut parfois être mal perçue, surtout si l'équipe n'est pas consultée en amont. Lors du départ d'un des membres de l'équipe, il y a une perte de connaissances, de savoir-faire, de confiance et voire de moral ou de motivation qui se produit. Dans tous les cas, l'équipe est ébranlée, engendrant une baisse de productivité, de vélocité.
Dès lors, comment faire pour minimiser les conséquences d'un départ et optimiser un retour à la "normale" via l'arrivée d'un New Guy? La solution pourrait bien se trouver dans la mise en place d'un processus d'accueil (onboarding).
Il n'y pas de raccourci, l'intégration d'un nouveau collaborateur doit se préparer et chaque membre de l'équipe doit y mettre du sien. Cela commence avant-même son arrivée.
Au niveau de l'onboarding, le nouveau, ici Dizzy Gillespie HARRISON aka Gil HARRIS, possédera un regard nouveau sur ce process. Il pourra faire des retours sur le bon comme le moins bon dans cette étape d'intégration. Pour l'équipe, ce sera l'occasion de tester ce processus et de l'améliorer au fil du temps afin d'être plus simple, plus original, et plus complet. Dans les deux sens, il faut se challenger et encourager la critique.
Il est possible de distinguer trois grandes phases dans le processus d'onboarding: celle précédant l'arrivée du nouveau, l'arrivée en tant que telle et celle qui suit.
Dans cette première partie, nous allons nous intéresser au Legacy d'une équipe, aux deux premières phases citées plus haut, et terminer sur la relation qui existe entre l'onboarding et le turn-over.
La team : son besoin et son Legacy
Un bon moyen d'intégrer Gil est de commencer par lui faire ressentir qu'il est "désiré". Si on intègre quelqu'un de nouveau à l'équipe, c'est en principe pour une bonne raison:
- départ ou futur départ d'un membre de l'équipe,
- besoin de renfort en prévision d'une montée en charge,
- besoin spécifique sur une technologie.
Sans trop en faire, montrez-lui que sa venue apporte un plus à l'équipe. En tant que nouvel arrivant, il est possible de se sentir dépassé dans un nouveau contexte, le fait de se sentir désiré améliorera sa confiance et favorisera aussi son intégration.
Faites attention au legacy de l'équipe car il peut fortement nuire à l'intégration de Gil. Il devra s'approprier la base de code présente avec ses bons et ses mauvais côtés; et soyons honnêtes, il y a plus souvent du mauvais que du bon quand on parle de legacy. De facto, mettre en place une politique de lutte contre le legacy en réduisant la dette peut aider fortement dans cette tâche.
En revanche, le legacy ne se traduit pas forcément que par du code. Il peut prendre d'autres formes. Les relations internes comme externes à l'équipe en font partie. Le legacy peut s'avérer positif dans le cas où l'équipe est soudée et les relations externes sont bonnes tandis qu'il peut se montrer négatif dans le cas de conflits internes et/ou externes. Il faudra rester attentif à cela, afin d'exposer le moins possible Gil à ce côté négatif (qui a dit obscur?). De même, le caractère ou l'humeur de certains membres de l'équipe peuvent s'avérer nocifs pour une bonne intégration voire nocifs tout court. Avoir un collègue râleur, qui se plaint de tout, tout le temps, peut rapidement devenir fatiguant et ce même, si ce dernier est très compétent.
Il faudra donc faire attention à ces points et surtout ne pas sous-estimer le dernier.
Le recrutement
L'arrivée de Gil est bien évidemment précédée d'un recrutement. Il est important que l'équipe soit consultée et que ce recrutement soit issu d'un besoin qu'elle a exprimé . Il ne faut surtout pas imposer quelqu'un à l'équipe, car cela risquerait d'en mécontenter les membres. Cela est encore plus vrai si la personne n'a pas les compétences requises pour les rejoindre.
Comment éviter que ce recrutement soit mal perçu par l'équipe en place et qu'elle se retrouve avec la mauvaise personne ? Simplement en faisant participer l'équipe à ce processus. Bien entendu, cela n'a pas besoin d'être forcément à 100% pour chacun des membres. L'équipe définit le profil de la personne recherchée, prépare les entretiens et les fait passer. Pour les entretiens techniques, il est de plus en plus fréquent de pairer sur du code avec le candidat. Quoi de mieux que de voir son "peut-être" futur collègue en action pour juger de sa capacité à travailler en binôme et tester sa manière de penser et de coder. Il est aussi possible de lui donner un exercice à faire avant l'entretien. Celui-ci sera analysé avec lui par la suite si le niveau est jugé acceptable.
Il est important que l'équipe s'implique dans ce process car le candidat peut en devenir un membre à part entière. Si toute l'équipe le valide "immédiatement", il y a de fortes chances qu'il corresponde au collègue presque parfait ^^.
La logistique
Malheureusement, côté logistique, nous tombons dans les mêmes travers : le badge, les comptes d'accès et l'ordinateur ne sont pas prêts le jour de l'arrivée de Gil. Cela engendre une perte de temps parfois considérable pour le projet, une frustration pour Gil et une perte d'argent pour la société. C'est pour cela que l'on devrait pouvoir accueillir Gil avec toute la logistique prête (ordinateur, badges et accès).
Dans notre milieu, nous parlons beaucoup d'automatisation des tâches et encore plus avec tout ce qui touche au continous delivery/deploiement. Mettre en place un processus de ce type devrait être la norme. Une fois un accord donné, un processus informatique est lancé pour créer les comptes, éditer le badge et commander la machine. Dans certaines structures, les plus grosses en général, cela peut prendre du temps. Or ce sont ces structures-là qui ont le plus besoin d'un onboarding de qualité, au vu de la cadence des arrivées.
Parcours initiatique
Intégrer Gil revient forcément à s'occuper de lui, surtout au début. Il faut bien lui expliquer le métier, mettre en place la logistique si ce n'est pas déjà fait (cf paragraphe précédent), voir avec lui son environnement de travail.
Cette initialisation lors de son arrivée a forcément un coût, car quelqu'un doit l'accompagner dans cette étape. Nommer un parrain peut s'avérer salvateur : il sera en charge de Gil le temps qu'il prenne ses marques. Cela évitera aussi à Gil de se tourner vers tous les membres de l'équipe et d'en faire "baisser" la vélocité. Les membres peuvent avoir certains impératifs (réunions, mise en production, aqua-poney ^^).
Définir un processus d'initialisation dans celui d'onboarding (qui a dit inception ?!) serait bienvenu. A partir d'un premier mail, le nouveau collaborateur aurait les informations nécessaires pour mettre en place son environnement de travail, prendre connaissance des règles de la société et avoir accès à une présentation fonctionnelle succincte et claire.
Clairement, si le métier est complexe, la présentation fonctionnelle ne sera pas qu'une simple introduction. Le nouveau collaborateur aura besoin, de toute façon, d'une formation et d'échanges avec les divers membres de l'équipe.
Le tout étant de trouver le juste équilibre entre la partie sur laquelle il est autonome et en pair.
Dès lors, pourquoi ne pas mettre en place un quickstart (sous forme de wiki par exemple)? Comme dit précédemment, Gil reçoit un mail avec un lien le renvoyant au quickstart. Un chemin balisé lui est montré pour réaliser ce qui est nécessaire d'un point de vue logistique et de manière autonome.
Sur cette partie, il peut être intéressant de faire original, à l'instar de l'onboarding présenté dans cet article: mise en place de jeux pour apprendre à connaître ses collègues et l'histoire de son entreprise, montée en compétences graduelle, etc. Votre imagination sera votre seule limite.
OnBoarding VS Turn-Over
Il existe une relation bi-directionnelle entre l'onboarding et le turn-over, un lien de cause à effet.
Le besoin d'un process d'onbaording résulte parfois d'un fort taux de turn-over. Cela engendre un besoin rapide de nouveaux collaborateurs. Dans ce cas, peut être y a-t-il un souci à cerner et corriger dans le management. Un fort taux de turn-over est fortement préjudiciable à l'onboarding; les nouveaux verront un jour le problème, voire le subiront et n'hésiteront peut être pas à partir ailleurs. Ici, le conseil est avant tout de prévenir plutôt que de guérir.
Dans l'autre sens, le turn-over peut résulter d'un mauvais processus d'onbaording. Imaginez-vous dès lors dans le cas du petit nouveau. Celui qui ne peut rien faire pendant un mois, car ne possédant ni badge, ni compte, ni ordinateur. Imaginez aussi qu'une fois ces sésames obtenus, personne n'ait le temps pour l'intégrer et que la documentation fournie soit obsolète. Relativement rapidement, cette personne pourrait en avoir assez et souhaiter s'en aller vers de plus verts pâturages. Encore une fois mettez-vous à sa place et imaginez ce que vous feriez ... A l'inverse, un bon processus d'onboarding permettra à un nouveau collaborateur de mieux s'intégrer à l'équipe et de lui donner envie d'y rester, participant par la même à une baisse du turn-over.
Conclusion
Comme vu précédemment, l'arrivée de Gil se prépare. Il peut être fortement intéressant d'investir sur ce processus d'onboarding et cela pour deux raisons:
- être sûr que Gil soit la bonne personne
- tout faire pour que son intégration se déroule au plus vite et au mieux
Gil vient de passer deux étapes importantes : le recrutement et son accueil. Maintenant, il lui reste à être intégré convenablement à plus long terme dans l'équipe.
Dans la seconde partie, nous allons justement présenter différentes méthodes permettant cela. Certaines d'entre elles peuvent en même temps s'appliquer afin de diminuer le turn-over des membres de l'équipe.
