Vous êtes entrepreneur et constatez que le turn-over est très élevé dans votre entreprise. Ce dernier est peut-être voulu, mais est à terme extrêmement néfaste. C’est en fait une des principales raisons d’échecs de projets informatiques, du fait de l’absence de suivi de l’évolution dans le temps quand beaucoup de personnes différentes interviennent dessus.
Débloque les + belles offres tech en 10 mins
Le salaire
Commençons directement par les choses qui fâchent : vos développeurs ne pourront pas se sentir bien dans votre entreprise s’ils sont tout le temps en train de penser à la manière de joindre les deux bouts. Ça paraît stupide mais c’est pourtant une évidence. Par conséquent il est capital de payer vos développeurs décemment de façon à ce qu’ils ne soient pas tentés d’aller voir ailleurs. Si vous n’êtes toujours pas convaincu je vous invite à lire cet article.
Par ailleurs n’oubliez pas que le salaire est la seule vraie gratification que vous fournissez à vos développeurs, le reste n’étant au final que du bonus qui peut régulièrement être mal perçu. Combien d’entreprises organisent en effet des week-ends dans lesquels la joie est forcée et où finalement tout le monde espère partir au plus vite ? Bref ne comptez pas de telles sorties ou quoi que ce soit d’autres comme rémunération. Les seules exceptions sont de vrais avantages en nature, comme une voiture de fonction qui peut être également utilisée à usage personnel les week-ends. Et n’oubliez pas : les équipes qui fonctionnent vraiment bien n’ont pas besoin de team building. En d’autres termes si vous sentez le besoin d’organiser de tels événements, revoyez plutôt votre politique de management.
Écoutez (ou pas…) vos développeurs
Une des plaintes qui revient régulièrement dans les services R&D vient du manque d’écoute de la hiérarchie. Exemple : vous souhaitez que les équipes développent telle fonctionnalité, et avez de votre côté évalué un temps. De leur côté les équipes fournissent une évaluation nettement supérieure à la vôtre, par exemple 100 jours homme, au lieu de 70 que vous aviez prévu. Vous refusez leur chiffrage et les renvoyez à leurs études, jusqu’à ce qu’ils vous présentent le chiffrage que vous attendez.
Cette situation se répète extrêmement souvent en entreprise, et envoie clairement un message à vos équipes : on vous demande votre avis, mais seulement pour la forme. Bref dites ce que vous voulez, on s’en moque. On vous donne un temps pour réaliser telle tâche, et même s’il est largement sous évalué (c’est généralement le cas) c’est à ça que vous devez vous tenir. Vous créez alors les conditions idéales pour avoir un niveau de qualité exécrable qui se répercutera sur le long terme par un logiciel bogué, impossible à maintenir et/ou trop lent, et par ailleurs une grande frustration de vos équipes. En d’autres termes, quand ils vous remontent un problème, c’est comme s’ils se soulageaient dans un violon pour dire ça poliment…
Celle-ci va se traduire en particulier par un désengagement croissant, sur le mode réfléchir, c’est commencer à désobéir. Alors vous tenterez de mettre la pression à vos équipes avec des outils de flicage mesure de productivité, les fameuses KPI. Ça marchera quelques jours, avant de rendre les gens encore plus démotivés. Dans de telles conditions, ne vous étonnez pas si le jour où vous rencontrez un grave problème il n’y a plus personne…
Bref, écouter vos développeurs et prendre en compte leurs remarques, c’est aussi leur permettre de faire du travail de qualité. Vous voulez un logiciel bien conçu, et avec une bonne couverture de tests ? Ça a un coût, mais vos développeurs s’éclateront dessus et donneront le meilleur d’eux-mêmes pour faire en sorte que cet état continue. Et à terme vous en serez le principal bénéficiaire, car vous aurez construit une relation de type gagnant-gagnant.
Respectez vos développeurs
Un corollaire du point évoqué ci-dessus est le respect que vous accordez à vos développeurs. En les traitant comme des ressources interchangeables, ils finiront par considérer votre entreprise comme étant également interchangeable. Dans de telles conditions ils resteront tant qu’ils verront qu’ils pourront en tirer quelque chose d’intéressant, et partiront juste après. Dans certains cas la durée de vie d’un développeur dans vos équipes peut être de moins d’un an. J’ai même connu des entreprises où d’une année sur l’autre 80% des gens de l’équipe avaient changé !
Bref si les développeurs de votre entreprise se sentent respectés, ils vous le rendront. Parmi les manifestations de non-respect, on pourra citer pèle-mêle une soirée d’entreprise à laquelle tout le monde est convié sauf les dévs (si si, ça existe), un séminaire où la direction déclare que l’entreprise fonctionne grâce aux commerciaux, et malgré les développeurs, et j’en passe. C’est ainsi que certains services se sentent dans les faits exclus de votre entreprise…
Si quelqu’un ne vous respectez pas, respecterez-vous en retour cette personne ? Eh bien c’est pareil avec vos développeurs…
Proposez des projets intéressants, éthiquement et techniquement
Chaque entreprise qui cherche à recruter promet d’avoir des projets de haute technicité, offrant des challenges passionnants. Dans les faits, la plupart du temps, vos projets ressemblent à ceci :
Et ça, manque de chance pour vous, les développeurs un minimum expérimenté le savent. L’état déplorable de nombreux projets est généralement conséquence des problématiques soulevées ci-dessus. Alors certes vous pouvez tomber également sur de mauvais développeurs, mais si vous recrutez correctement vos développeurs, vous minimisez les risques que ça arrive. Bref un projet ne peut être techniquement intéressant que si vous laissez vos développeurs bien faire les choses. N’oubliez pas qu’il n’est pas nécessaire d’avoir la dernière version de Spring ou de Java pour qu’un projet soit intéressant, par contre il est capital que celui-ci soit bien construit. Si tel est le cas, faire évoluer les frameworks ne posera pas le moindre souci.
En bref…
Vous voulez garder vos développeurs ? Respectez-les. Tout simplement. Aussi bien sur le plan du salaire que de la manière dont vous les managez. Sinon ils s’enfuiront, et à terme vous serez le perdant, en particulier si vous êtes un éditeur de logiciels. De nombreuses sociétés on dû mettre la clef sous la porte en raison de code devenu impossible à maintenir, et ça pourrait très bien vous arriver si vous n’y faites pas attention…
Débloque les + belles offres tech en 10 mins
Cet article vous a plu ? Vous aimerez sûrement aussi :
- Entrepreneurs, pourquoi c’est important de bien payer vos développeurs
- Recruteurs, comment identifier le bon développeur
- Comment un manager peut-il (bien) challenger un développeur ?
Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.
Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.
