Bonjour, je suis Pierre Peltier, Développeur informatique de l’équipe R&D chez Talentsoft. Et si nous choisissions nos projets plutôt que de les “subir” ? C’est la réflexion que je me suis faite, lors d’une discussion avec Alex, quand on en est venu au fameux : “un développeur motivé est bien plus performant qu’un développeur qui traîne les pieds pour aller bosser”.
Notre équipe de recherche et développement fait régulièrement face à un problème de staffing avec d’un côté une armée de développeurs, et de l’autre, des projets à honorer. Le choix est parfois impossible ou limité car un projet peut requérir la connaissance d’un développeur spécifique, ou une partie de l’équipe peut être immobilisée sur un autre projet. On peut trouver plein d’autres bonnes raisons contraignantes qui imposent l’affectation d’un projet à un développeur.
Mais à partir du moment où le choix du développeur ne dépend plus que de la place de la première lettre de son nom dans l’alphabet, pourquoi ne pas le donner au plus intéressé ? La pire des choses serait de se rendre compte, trop tard, que deux collaborateurs s’envient mutuellement leur projet… Tous les goûts sont dans la nature et il n’y a pas d’exception pour les projets ! Je suis convaincu que les développeurs apprécieront de pouvoir choisir, et les managers de proposer plutôt que d’imposer.
L’idée serait donc de présenter les projets aux développeurs qui feraient leur choix parmi l’ensemble des projets disponibles. Mieux, le développeur pourrait noter chaque projet selon ses préférences. En utilisant toutes ces informations pour attribuer les projets, on garantit une motivation optimum pour toute l’équipe.
Ce mode de fonctionnement peut paraître évident aujourd’hui, ou à minima envisageable, alors qu’il était impensable par le passé. A mon sens il y a plusieurs facteurs qui peuvent expliquer cela :
- Les entreprises ne disposaient pas de moyens de communication interne nécessaires et suffisants pour y parvenir (internet, intranet, …)
- La rigidité de la structure hiérarchique des anciennes entreprises ne permettait pas au collaborateur d’être force de proposition
- Ce n’est que récemment que les mentalités ont changé pour mettre le collaborateur au centre de l’entreprise
A noter également que certaines conditions doivent être obligatoirement remplies. Les projets doivent être prêts suffisamment à l’avance pour pouvoir être présentés efficacement. Il faut s’assurer que le projet n’évoluera pas après avoir été présenté.
Rappelons que le principal objectif ici est de motiver le collaborateur et qu’il peut facilement mal l’interpréter. Il faudra donc bien faire comprendre au collaborateur que tout sera fait pour qu’il travaille sur le projet qui le motive mais que rien ne le garantit. Inutile de préciser que cela doit être compatible avec la culture et les valeurs de l’entreprise.
Maintenant les SIRH permettent d’exposer des fiches de poste avec les compétences requises associées. Pourquoi ne pourrait-on pas faire de même avec les projets ? Pourquoi ne pas laisser le collaborateur exprimer sa motivation comme pour un entretien de recrutement ? Peut-être que la formation qu’il aura dans un mois lui permettra d’avoir l’ensemble des compétences requises pour le projet qu’il convoite. A l’inverse, il peut ne pas se sentir à l’aise sur une technologie et aimerait émettre une réserve sur un projet.
Ces informations cruciales, le décideur ne les a pas forcément, alors laissons la motivation de chacun le guider.
Super idée, on va essayer de faire ça pour les prochains projets.
Cependant, actuellement, c’est plutôt la première équipe qui se libère qui hérite du projet le plus attendu.
Excellent cet article, ça me fait réfléchir 🙂