Recruter un développeur PHP quand on est éditeur sur un framework maison

vendredi 11 juillet 2014 :: perrick :: Développement :: aucun commentaire :: aucun trackback

J'ai reçu aujourd'hui une questions originale : on cherche un profil de dev php pour notre logiciel en SAAS à base d'aucun framework (maison). Toi qui prônes l'anti framework :) comment réussis tu à trouver des profils intéressants et es-tu obligé d'avoir des gars sans expérience que tu formes pour ne pas les voir s'enfuir à grandes enjambées lorsque tu leur dis qu'ils n'utiliseront ni Symfony 2, ni ZF, ni même un autre framework à la mode ?

Ce n'est effectivement pas le plus simple, surtout que je suis plutôt bien placé pour le savoir : sur nos trois derniers recrutements techniques, le premier a été licencié dans les 15 jours, le second a posé sa démission dans les 2 mois et le troisième est en fait un ancien salarié qui est revenu ;-)

Bref ma petite expérience en la matière, c'est qu'il faut un travail de longue haleine.

Chez No Parking, il y a un tropisme plutôt prendre un "jeune" et le faire monter en compétence. L'inconvénient, c'est qu'il faut parfois les voir partir à la fin du stage : un éditeur a souvent moins de turnover que les prestataires en forfait (qui en a moins encore que les prestataires en régie). Nous avons eu 2 stagiaires relativement récents comme ça qui sont allés à la "concurrence" parce qu'on ne pouvait pas les embaucher sur le moment (même si on s'en est mordu les doigts 3 ou 6 mois plus tard).

Avec les personnes plus expérimentés, il faut les choyer et passer pas mal de temps en one-to-one pour les faire monter en compétence rapidement sur le framework maison, les outils internes, les conventions traditionnelles, etc. En effet la transition et la courbe d'apprentissage sur une nouvelle techno ne sont pas toujours faciles à accepter : la tendance peut vite à reprendre ses vieilles habitudes, celles qui marchaient dans le contexte précédent.

Le pair-programming est un bon outil pour se familiariser avec du code : à consommer sans modération. L'autre truc qu'on fait de temps en temps avec des nouveaux, ce sont des journées de remaniement.

Le principe est simple :

  1. on identifie des "trucs moches" dans le code (le nouveau est souvent bon pour ça)
  2. tout le monde se met en binôme derrière un écran
  3. on lance un chrono de 30 minutes
  4. chaque binôme se lance dans un remaniement
  5. au bout de 30 minutes, on fait tourner les binômes
  6. on recommence jusqu'à la pause de midi, puis du soir

Ce petit exercice permet de mettre un peu de "fun" dans des tâches souvent bas niveau et répétitives, de la gamification.

Bien sûr ces petits trucs valent quand le nouveau collaborateur est arrivé. Avant il faut le convaincre, au délà des salaires, des conditions de travail (et de déplacements), parmi les éléments techniques à mettre en avant il y a la différence fondamentale éditeur v. SSII. D'un côté des projets sur le long terme dans lesquels on peut se projeter, de l'autre des projets qui s'enchaînent et pas toujours très qualitatifs ! Même si les SSII parleront eux de logiciels vieillissants et sclérosés sur des technos rétrogrades, en comparaison de leurs projets toujours innovants pour des clients à la pointe des technologies dans un univers où on peut devenir "chef de projet" (il paraît que ce serait le graal).