Comment démontrer à la direction que les développeurs médiocres nuisent à l'équipe ?

Question

Je me trouve dans la position précaire de "gérer" une équipe de développeurs dans une petite entreprise. Je dis "gérer" parce que, bien que je répartisse le travail et que je fournisse un retour d'information sur leurs performances, je n'ai aucun recours pour discipliner une personne.

Je ne sais pas quoi faire de certains membres de mon équipe, ils sont incapables de travailler seuls, ont besoin d'un soutien massif et, lorsqu'on les laisse faire, ils font des ravages sur le projet, jusqu'à l'échec. Lorsque l'échec survient, je dois sauver le projet et le pousser (parfois en boitant) vers la ligne d'arrivée.

Ces développeurs manquent non seulement de compétences en matière de concepts de programmation, mais aussi généralement de capacité à formuler une solution à un problème en code. Des choses simples comme l'écriture de boucles sont difficiles pour eux, sans parler de la conception et de la mise en œuvre d'une solution à un problème.

Nous avons essayé la programmation par paire, proposé de payer des cours, acheté des livres, alloué du temps à la formation pendant la journée de travail et même pris des journées entières pour former l'équipe.

L'autre développeur principal et moi-même ne savons pas quoi faire, mais notre productivité est mise à mal par le fait de devoir traiter avec ces personnes au quotidien. La direction nous oblige à leur donner du travail et leur principale plainte est que les choses ne sont pas faites assez rapidement.

Aucun membre de notre équipe de gestion ne travaille directement avec les développeurs, à l'exception de moi-même et de l'autre développeur principal. La direction n'est pas technique et croit que tous les développeurs sont égaux, et que nous avons évidemment besoin de plus de personnes sur ces projets pour les réaliser plus rapidement.

Je suis déjà en train de préparer un document avec des sections de "The Mythical Man Month" et "Code Complete" que j'enverrai à la direction pour espérer illustrer par des statistiques que ce qui nous gêne vraiment, c'est de devoir traîner les gens médiocres dans le cycle de développement.

Quelles sont les autres ressources disponibles ? Livres, articles, conseils généraux, tout ce qui pourrait être utile.

Answer 1

On dirait que vous êtes sur la bonne voie.

Si vous leur montrez des chiffres difficiles, ils verront les choses plus clairement - créez une mission de codage et donnez-la à plusieurs programmeurs différents pour qu'ils y travaillent chacun de leur côté. Faites en sorte qu'il soit testable par vous-même.

Gardez des détails sur le temps que prend chacune d'elles, sur le nombre de défauts que le code produit.

Montrez les chiffres à la haute direction, elle devrait maintenant être convaincue.

Answer 2

Le livre

Code Complete : Un manuel pratique de construction de logiciels par Steve McConnell

est une bonne source qui peut aider à apprendre les meilleures pratiques.

Exiger de chaque développeur qu'il lise et apprenne ceci avec des discussions pourrait aider un peu mais le plus important est de quantifier les résultats. Prenez votre salaire et celui du reste de l'équipe, puis calculez le temps supplémentaire que vous devez passer à réparer les erreurs des autres, sans compter le coût supplémentaire des erreurs commises par les développeurs.

Montrez ensuite comment une équipe de meilleurs développeurs peut améliorer le retour sur investissement.

Answer 3

Faites en sorte que le rapport soit concis. Ne le rendez pas verbeux. Expliquez combien d'argent ils perdent sur ce coup-là.

Answer 4

Nous disposons désormais d'un outil qui mesure la complexité de nos modules de code. Il fonctionne sur nos modules PL/SQL, mais je crois qu'il existe des outils disponibles sur d'autres environnements.

Il y a plusieurs sections tout au long du processus, mais la direction a eu l'impression que plusieurs de nos modules clés étaient considérés comme "non testables".

Nous avons combiné cet outil avec un outil d'analyse d'imact qui aide à mettre en évidence les fonctionnalités en double, et nous avons présenté le tout sous la forme d'une évaluation de la "dette technique".

Comme nous pouvions présenter cela module par module, il aurait été facile d'identifier les auteurs (nous l'avons fait, mais nous ne l'avons pas signalé). En l'état actuel des choses, l'organisation était plus orientée vers l'amélioration future que vers la désignation de coupables.

(Soit dit en passant, tout le code est désormais soumis à un examen et une analyse de code doit être fournie. Les choses s'améliorent définitivement ici).

Answer 5

Ce n'est tout simplement pas possible à moins d'avoir une bonne traction avec la direction. D'après mon expérience, si vous essayez de forcer les choses, vous risquez d'avoir des problèmes.