Il était une fois, alors que je travaillais en tant que Directeur Technique, le PDG m'a demandé de faire un rapport sur certains indicateurs clés de performance (KPI) afin de mesurer et de contrôler les performances de l'équipe de développement.
Nous avions des KPI (Indicateurs Clés de Performance) tels que "Heures de développement par développeur et par jour" mesurées par les développeurs qui rapportaient le temps passé chaque jour. Jira par développeur, heures travaillées sur les tickets techniques, pourcentage de jours ouvrables passés en réunions, Temps moyen dans état X, etc., etc.
La liste est longue. J'ai même évalué l'équipe en fonction du nombre d'heures travaillées par semaine. J'ai attribué un budget pour les dîners d'équipe. Je me suis trompé. Si on me posait la même question aujourd'hui, je ne le ferais pas de cette façon.
Soyons clairs, le temps passé à développer quelque chose n'a rien à voir avec la performance ou la production ou quoi que ce soit. Ce qu'il fait, c'est qu'il essaie de mesurer quelque chose afin de pouvoir le contrôler. C'est une notion ancienne issue de l'usine qui dit: "Ce que vous ne mesurez pas, vous ne pouvez pas contrôler", qui était également populaire dans la gestion de projet en cascade à l'ancienne.
Ce qu'il fait, c'est détourner votre attention de ce qui est important, les gens. Essayer de convertir leurs efforts en chiffres. Ce n'est pas possible, et ce sera faux. De plus, en tant que KPI. Les raisons pour lesquelles les équipes de développement peuvent livrer un excellent code sont la culture, la motivation et le flux – laissez-les faire leur travail. Ne les interrompez pas avec beaucoup de bêtises.
Lisez-en plus dans "Le Playbook du CTO" disponible sur Amazon/Kindle.
Nous sommes une société suisse (LLC) basée en
Suisse.