Et si on devenait des artisans du recrutement ?

Beaucoup de recruteurs s’efforcent à rechercher des artisans du code en informatique, appelés software crafter, avant même de s’intéresser à cette philosophie, avant même d’endosser eux-mêmes la casquette d’artisan du recrutement.

Or, dans le recrutement, comme ailleurs, les passionnés attirent les passionnés, les personnes férues de la qualité attirent les personnes sensibles à la qualité.

Pour recruter de bons(nnes) développeurs(ses), bons(nnes) dans le sens attachés(ées) à la qualité du code, à la qualité du livrable, il me semble indispensable, tout d’abord, de les connaître, de comprendre leurs méthodes et surtout à s’en inspirer dans l’amélioration de nos pratiques au quotidien.

Posons tout d’abord le décor du projet en recrutement:

Les acteurs :

Toutes les personnes parties prenantes dans la décision de recrutement (le recruteur, le patron et/ou le manager, éventuellement le commercial,…)

Le/les produit(s) et ses fonctionnalités :

Le/les poste(s) à pourvoir et ses multiples fonctionnalités (projet, équipe, organisation, responsabilités, outils,…)

Le cycle « d’achat » :

Le processus de recrutement avec sa durée, son expérience candidat, son degré de compréhension, son efficacité (temps de réponse, disponibilité, capacité à tenir la charge lorsqu’il y a volumétrie)

Les user :

Les candidats

Le cycle d’acquisition/fidélisation :

Intégration, formation,..

Devenir un artisan du recrutement serait donc de mettre en application les concepts craftsmanship au monde du recrutement, des concepts reposant sur un seul et unique fil conducteur : la communication !

Behavior Driven Development

Définition Wikipedia :

Le behavior-driven development (ou BDD) est une méthode agile qui encourage la collaboration entre les développeurs, les responsables qualités, les intervenants non-techniques et les entreprises participant à un projet de logiciel.

Le code est donc perçu comme un travail collectif permettant de remettre en question la fonctionnalité et de clarifier les responsabilités de chacun.

Comme il est écrit également sur le blog d’Arolla « le BDD consiste à étendre le TDD en écrivant non plus du code compréhensible uniquement par des développeurs, mais sous forme de scénario compréhensible par toutes les personnes impliquées dans le projet.
Autrement dit, il s’agit d’écrire des tests qui décrivent le comportement attendu du système et que tout le monde peut comprendre. »


Faisons donc un parallèle avec le recrutement. Il ne s’agit pas uniquement de réfléchir au comportement des user (candidats) face aux feature produit (poste), uniquement par le prisme des recruteurs mais d’imaginer des scénarios pensés par toutes les parties prenantes du recrutement.

Ainsi, le poste peut prendre de multiples contours, selon les scénarios des users identifiés : personne qui habite loin, personne senior, junior, personne en situation d’handicap, homme, femme, personne possédant telle compétence technique, telle rémunération, en gros s’intéresser davantage au comportement « d’achat » avec de multiples points de vue : celui de l’équipe de recrutement, celui de la technique, du business, et celui du user lui-même.

Il n’y a donc plus la notion d’un poste précis et figé mais de multiples scénarios de poste en fonction du comportement des user, à l’instant T et dans le temps.

Cette méthode permettrait d’avoir une vue d’ensemble, de bien vérifier la qualité du/des « produit » proposés aux multiples fonctionnalités ajustables, modifiables. Par exemple, un recruteur peut faire un super entretien, le RH peut faire une super proposition salariale mais le candidat ne s’est pas projeté dans le poste car trop senior par rapport aux responsabilités.

Quelques éléments peuvent être techniquement valides mais, une fois ensemble, ils ne répondent pas toujours au besoin exprimé par le candidat.

Ainsi, le BDD appliqué au monde du recrutement permettrait, non plus, de valider des feature isolées mais de vérifier le comportement global des user par rapport au poste et ce, illustré par des exemples concrets, compris par tout le monde : « the new Pragmatic Recruiter »

Test Driven Development

Définition Wikipedia :

Le test-driven development (TDD) ou en français développement piloté par les tests est une technique de développement de logiciel qui préconise d’écrire les tests unitaires avant d’écrire le code source d’un logiciel.


Tout développeur soucieux de son environnement et de son héritage doit se poser sérieusement la question du TDD.

J’ai envie de dire que c’est pareil pour le recruteur et son équipe. Ils doivent sans cesse tester leurs scénarios d’approche, leurs produits (postes), leur processus de recrutement, leur schéma d’intégration candidat et ce avec une notion d’héritage, de transmission pour leur équipe actuelle, les futures recrues, voire même pour la communauté des recruteurs de façon plus globale.

On évite ainsi de reproduire les mêmes erreurs et surtout de cumuler une dette humaine (déception candidat, collaborateur, et déception des futurs recruteurs qui vont intervenir sur le projet en recrutement).

On dit en informatique : cela évite souvent des erreurs de conception dues à une précipitation dans l’implémentation avant d’avoir défini les objectifs. Pour le monde du recrutement, c’est la même chose : on peut éviter des erreurs de définition du poste dues à une précipitation dans le sourcing avant d’avoir défini les objectifs.

Cette façon de travailler, permettrait non seulement d’augmenter la confiance en soi des recruteurs mais aussi d’avoir une base documentée de ce qui fonctionne et ce qui ne fonctionne pas avec une définition claire de la notion de succès : est-ce que l’on se base uniquement sur un nombre de candidats positionnés en entretien RH ? Ou alors on se base sur la finalité c’est-à-dire le taux de transformation ? Et ainsi de suite. Cette démarche de tests continue dans le monde RH ferait du bien car elle alimenterait des cercles de réflexion en interne sur les best practices à partager, à améliorer, à innover.

Extreme Programming

Définition Wikipedia :

En informatique et plus particulièrement en génie logiciel, extreme programming (XP) est une méthode agile plus particulièrement orientée sur l’aspect réalisation d’une application, sans pour autant négliger l’aspect gestion de projet. XP est adapté aux équipes réduites avec des besoins changeants. XP pousse à l’extrême des principes simples.

Les voici :

  • puisque la revue de code est une bonne pratique, elle sera faite en permanence (par un binôme) ;
  • puisque les tests sont utiles, ils seront faits systématiquement avant chaque mise en œuvre ;
  • puisque la conception est importante, elle sera faite tout au long du projet (refactoring) ;
  • puisque la simplicité permet d’avancer plus vite, nous choisirons toujours la solution la plus simple ;
  • puisque la compréhension est importante, nous définirons et ferons évoluer ensemble des métaphores ;
  • puisque l’intégration des modifications est cruciale, nous l’effectuerons plusieurs fois par jour ;
  • puisque les besoins évoluent vite, nous ferons des cycles de développement très rapides pour nous adapter au changement.

Faisons donc le parallèle avec le recrutement :

  • Puisque la revue de l’annonce en recrutement est importante elle sera faite en permanence (par un binôme)
  • Puisque tester les outils/approches en recrutement est utile, cela sera fait systématiquement
  • Puisque la conception du poste est importante, elle sera faite tout au long du projet en recrutement (refactoring du profil)
  • Puisque l’intégration des modifications est cruciale, cela sera effectué plusieurs fois par jour
  • Puisque les besoins évoluent vite, nous ferons des cycles de décision rapides (itérations courtes et gérées collectivement avec une implication constante du candidat) pour nous adapter au changement.

Par ailleurs, voici les valeurs de l’extreme Programming qui peuvent s’appliquer au monde du recrutement, sans modération :

Respect : cette valeur inclut le respect pour les autres, ainsi que le respect de soi. Les programmeurs ne devraient jamais valider les modifications qui cassent la compilation, qui font échouer les tests unitaires existants ou qui retardent le travail de leurs pairs. Les membres respectent leur propre travail en cherchant toujours la qualité et la meilleure conception pour la solution et cela grâce au refactoring. Et donc en recrutement on pourrait dire les mêmes choses, mot pour mot : respect des pairs, penser candidat avant l’intérêt personnel, penser à la qualité, à la transmission, aux échanges, à la critique pour une amélioration continue du métier et des pratiques.

Communication : c’est le moyen fondamental pour éviter les problèmes. Les pratiques que préconise l’XP imposent une communication intense. Les tests, la programmation en binôme et le jeu du planning obligent les développeurs, les décideurs et les clients à communiquer. On pourrait imaginer une obligation de communication dans les équipes de recrutement avec un rappel des enjeux business. Ainsi, au-delà de se raconter les choses, vite fait, à la pause café et/ou à la pause déjeuner, on pourrait imaginer des exercices de ritualisation de communication quotidien pour soulever les problèmes et cadrer un feedback avec des solutions concrètes, selon un ordre de priorité. Cela serait comme une maïeutique constante pour éviter les erreurs d’interprétation, les baisses de motivation et les multiples frustrations non partagées.

Simplicité : La façon la plus simple d’arriver au résultat est la meilleure. L’over-engineering en recrutement a tendance à paralyser les prises d’initiative, la créativité, l’authenticité dans l’approche et surtout nous éloigner de l’essentiel : recruter.

Feedback : le retour d’information est primordial pour le programmeur et le client, tout comme il est pour le recruteur et le candidat.

Courage : certains changements demandent beaucoup de courage. Il faut parfois changer l’architecture d’un projet, jeter du code pour en produire un meilleur ou essayer une nouvelle technique. Le courage permet de sortir d’une situation inadaptée. C’est difficile, mais la simplicité, le feedback et la communication rendent ces tâches accessibles. Il en faut aussi beaucoup du courage en recrutement pour sortir d’une situation inadaptée : revoir totalement la politique salariale, revoir le positionnement de l’entreprise, revoir aussi si il y a ou non les bonnes personnes dans l’équipe avant d’en intégrer une nouvelle, revoir le niveau de compétences (formation, montée en compétences) avant de recruter une énième personne sur un projet.

Pair Programming

Définition Wikipedia :

La programmation en binôme (de l’anglais pair programming), parfois appelée programmation par paires ou binômage, est une méthode de travail dans laquelle deux développeurs travaillent ensemble sur un même poste de travail. La personne qui rédige le code est appelée conducteur (driver). La seconde personne, appelée observateur (observer), assiste le conducteur en décelant les imperfections, en vérifiant que le code implémente correctement le design et en suggérant des alternatives de développement. Les rôles s’échangent régulièrement pendant la séance de programmation. La programmation en binôme fait partie des bonnes pratiques de l’extreme Programming.


Ne peut-on pas imaginer le même principe lorsqu’il s’agit de rédiger le poste ou encore au moment de faire l’évaluation candidat en entretien RH ? Beaucoup d’entreprises, tout comme pour les tâches de développement, pourraient estimer cela comme un gaspillage de ressources avec deux personnes mobilisées pour un même candidat. Cependant, cela pourrait être un super exercice. Lorsqu’on est seul il est difficile à la fois de prendre des notes, d’écouter et d’évaluer. Si une personne joue uniquement le rôle d’observateur, ça apporterait un regard croisé et ce, à chaque étape du processus de recrutement.

Au-delà du principe d’être à deux pour l’évaluation, il faudrait imaginer la bonne combinaison : un recruteur junior avec un senior, un recruteur avec une personne du métier, un recruteur avec une personne de la technique, un recruteur et un commercial. Aujourd’hui, il existe ce type de configuration mais les rôles sont mal alloués : les deux exécutent l’entretien dans un rôle de driver par exemple sans que l’un des deux n’ait un rôle d’observateur, ou l’un des deux ne va pas au bout de la rencontre car arrive le moment où le sujet de discussion en entretien ne le concerne plus; Ou l’objectif de la rencontre en amont a été mal défini ce qui provoque le sentiment pour l’un des deux d’être là pour rien sans savoir sur quoi il doit porter une attention/évaluation. D’ailleurs, assez souvent, le recruteur, plus senior, attache plus d’importance à juger l’autre recruteur sur sa prestation en entretien qu’à revoir à deux, d’égal à égal, l’évaluation du candidat.

Mettre en place un entretien de recrutement en binôme serait une activité sociale qui impliquerait d’apprendre à travailler avec les autres, plus en profondeur et plus régulièrement.

Cela pourrait améliorer

  • le plaisir des recruteurs dans leurs tâches, souvent chronoghages,
  • leurs qualités de communication et on sait combien ils en ont besoin en étant la plupart du temps la tête sous l’eau en immersion totale casque/sourcing,
  • la confiance dans leur travail : le partage doit se faire autant à l’extérieur (communautés, Meetup) qu’à l’intérieur, entre les équipes, au sein même de l’équipe en recrutement
  • le transfert de connaissances.

Il existe certainement beaucoup d’autres méthodes d’artisanat du code à mettre en parallèle avec les méthodes de recrutement. Ce que je veux mettre en avant c’est que le software craftsmanship n’est, en aucun cas, un sujet purement technique, mais bien un sujet d’entreprise, une philosophie, qui doit s’appliquer à tous les métiers, à toutes les strates de décision, et encore plus en ce qui concerne les décisions de recrutement car “les bonnes recrues d’aujourd’hui sont les bons logiciels de demain et la croissance d’après-demain”

Shirley Almosni Chiche

Répondre

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l'aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s