Devoir définir des objectifs pour les développeurs, même si les objectifs ne fonctionnent pas [fermé]

Il est généralement admis que l' établissement d'objectifs mesurables pour les développeurs de logiciels ne fonctionne pas , car une trop grande concentration sur les objectifs peut conduire à un comportement contraire aux objectifs de l'organisation (ce que l'on appelle un « dysfonctionnement de la mesure »).

Cependant, dans mon entreprise, nous sommes tenus de fixer des objectifs pour tout le personnel, et nous sommes encouragés par les ressources humaines à les rendre SMART . Dans le passé, mes collègues managers de premier niveau (chefs d'équipe) et moi avons essayé plusieurs approches:

1. Fixez des objectifs mesurables qui s'ajoutent au travail normal, comme «Faire une formation sur la technologie X», «Créer une documentation pour un morceau de code Y que personne ne comprend», etc. En ce qui concerne l'évaluation annuelle des performances, évaluez les développeurs non pas sur les objectifs écrits, mais plutôt sur mon opinion sur la valeur incommensurable de leur travail normal, car c'est en fait ce qui intéresse l'entreprise.
2. Fixez-vous des objectifs très spécifiques tels que «les jours de travail effectués tels qu'ils sont enregistrés par le système de gestion des tâches», «le nombre de bogues introduits», «le nombre de production émise causée». Cela a conduit à des estimations gonflées et à une classification incorrecte des bogues, afin d'obtenir de meilleurs «scores». Fait intéressant, même les développeurs qui obtiennent de bons scores sur ce système ne l'aiment pas, car la confiance intrinsèque au sein de l'équipe a été endommagée et ils n'ont pas toujours estimé qu'ils méritaient leur position élevée.
3. Fixez-vous des objectifs vagues qui sont des variantes sur «Faites bien votre travail normal». Lorsqu'il s'agit de l'évaluation annuelle, leur note reflète la performance par rapport aux objectifs, mais les objectifs eux-mêmes ne sont ni mesurables ni réalisables, ce qui est mal vu.

Aucun de ceux-ci n'est idéal. Si vous avez été dans une situation similaire de devoir créer des objectifs significatifs et mesurables pour les développeurs de logiciels malgré les preuves contre leur efficacité, quelle approche a fonctionné le mieux pour vous?

Questions connexes que j'ai trouvées qui ne traitent pas tout à fait du même point:

• Quels sont les bons objectifs de performance pour un ingénieur logiciel?
• Définition d'objectifs de performance pour les développeurs
• Quels sont les indicateurs de performance appropriés pour les programmeurs?
• Qu'est-ce qu'une technique de mesure de la productivité équitable pour les programmeurs?
• J'ai besoin de quelques «objectifs» de carrière pour l'année prochaine

Mise à jour (18 novembre 2009): Il y a 10 votes positifs pour ma question, et les réponses les mieux notées n'ont que 4 votes positifs (dont un chacun de moi). Je pense que cela nous dit quelque chose: peut - être que Joel et les autres ont raison, et que la sagesse combinée de stackoverflow ne peuvent pas venir avec des objectifs impérieux et mesurables pour les développeurs qui ne pouvaient être Gamed sans affecter négativement la valeur réelle (non mesurable) de leur travail. Merci d'avoir essayé!

quelle approche a fonctionné le mieux pour vous?

Un seul objectif: réussir une inspection de code / revue par les pairs, avec moi en tant que réviseur, sans que je trouve de bugs ou que j'aie d'autres critiques, cela me demande de refaire quelque chose.

Remarques:

• Je ne mesurais pas la capacité des nouveaux employés à terminer rapidement et je ne les ai pas encouragés à le faire: je voulais que les gens apprennent à bien finir (parce que si ce n'est pas bien fini, ce n'est pas fini)
• Les gens ont appris ce que je recherchais dans une revue de code: c'est donc une opportunité d'apprentissage et une mesure de contrôle qualité, et pas seulement un objectif de gestion
• Mes commentaires auraient deux catégories:
  1. Ceci est un bug: vous devez le corriger avant de vous enregistrer
  2. A titre de suggestion, j'aurais fait telle ou telle chose
• Après un certain temps, mes critiques du code d'une personne cessaient de trouver des éléments "à corriger" (à quel point je n'aurais plus besoin de revoir leur travail).

Personnellement, j'essaye de me fixer deux sortes d'objectifs:

• Des objectifs axés sur les affaires (c'est pourquoi nous sommes payés après tout). Par exemple, «terminer le projet X avant le 1er juin 2009»). Ces objectifs sont souvent partagés entre plusieurs membres de l'équipe (et ils en sont conscients). L'équipe peut dépasser l'objectif en amenant le projet au début ou en dépassant les fonctionnalités requises. Les individus peuvent dépasser l'objectif en produisant plus de fonctionnalités, en ayant moins de bogues contre eux, ou en encadrant et en soutenant d'autres membres de l'équipe.

• Objectifs de croissance personnelle, par exemple terminer un projet impliquant une technologie que le développeur souhaite ajouter à ses compétences, mieux comprendre le domaine de l'utilisateur, acquérir une expérience de leadership, etc.

Je pense qu'il est important que:

• Les objectifs sont SMART
• Les objectifs sont alignés sur les besoins de l'entreprise
• Vous incluez le «travail normal» dans les objectifs, en fait ce sont les objectifs les plus importants!
• L'employé a la possibilité de dépasser les objectifs que vous vous êtes fixés

Enfin, je resterais loin des métriques logicielles en tant qu'objectifs - elles sont trop faciles à jouer et ne vous donneront probablement pas ce dont vous avez besoin. Je n'utiliserais qu'une métrique où je veux entraîner quelqu'un dans ou hors d'un comportement particulier.

Tout cela se résume au fait que la «direction de premier niveau», et la plupart des gestionnaires, ne connaissent pas leurs employés. Au lieu de faire partie de la planification et du développement quotidiens, des choses comme SMART apparaissent. Si les gestionnaires devaient passer plus de temps avec les gars qui font le travail réel, rien de tout cela ne serait nécessaire.

Personnellement, je préfère travailler dans un environnement agile où il est évident que les développeurs sont performants en termes de productivité et de sensibilisation à la qualité. Une véritable approche agile nécessite que non seulement les développeurs, mais aussi les concepteurs, les testeurs, les clients et les chefs de produit soient inclus dans le processus. Cela conduit naturellement à une meilleure compréhension du point de vue des gestionnaires.

Des objectifs mesurables que j'ai vus jusqu'à présent:

• Passer un examen de certificat
• Recherchez la technologie X et faites une présentation à ce sujet
• Nombre de modifications de rupture de build validées
• Nombre d'articles wiki écrits sur la gestion interne des connaissances

Que diriez-vous de demander directement à vos développeurs s'ils ont des idées de développement personnel qui pourraient ensuite être utilisées pour des objectifs?

Devoir fixer des objectifs aux développeurs, même s'ils ne fonctionnent pas

Si vos développeurs ne travaillent pas, peut-être que certains objectifs sont exactement ce dont ils ont besoin pour les inciter? ;-)

"Assurez-vous qu'au moins n% de votre code est testé par un test unitaire approprié" Utilisez un outil de couverture pour le prouver, et demandez à quelqu'un d'autre de vérifier la qualité du test.

Je pense qu'avoir des objectifs très spécifiques à l'avant, c'est-à-dire SMART (peut-être que nous travaillons au même endroit en fait), semble être une bonne idée en pratique mais ce n'est pas très pratique pour la plupart des équipes.

Le problème est vraiment le changement progressif de nos objectifs. L'entreprise change et en tant que développeurs, nous devons réagir et réagir correctement et dans un délai raisonnable.

Envisagez de fixer des objectifs en lien avec le but de votre équipe ou de votre groupe dans l'organisation. Votre équipe ne serait pas financée si elle ne servait pas un objectif - un objectif macro. Ayez des objectifs collectifs qui existent dans toute votre équipe et qui correspondent à l'entreprise. Donnez aux gens la responsabilité et tenez les gens responsables. Célébrez leurs succès et leurs échecs (si nous n'échouons pas parfois, nous n'essayons probablement pas et c'est ce que vous attendez des gens). HTH

Nous avons un certain nombre de métriques qui sont collectées pendant le travail des programmeurs, telles que:

• Nombre de SLOC modifiés / ajoutés
• Nombre d'erreurs / bogues injectés à différentes étapes du processus (pendant l'examen par les pairs, après l'examen par les pairs, après la publication)
• Demandes de changement satisfaites / rejetées
• Documents formels (descriptions de versions de logiciels, documents de conception, etc.)

Tous ces éléments sont des éléments tangibles que je trouve utiles dans les présentations de gestion et d'assurance qualité des logiciels. Mais je ne les ai jamais trouvés très utiles dans les évaluations réelles de la performance des gens - ce qui est le point soulevé par plusieurs des liens que vous avez énumérés. J'ai trouvé que les points de Joel ici sont valides - les mesures ne favorisent jamais une bonne ambiance d'équipe.

Malheureusement, nous vivons tous dans un monde où les métriques sont requises par d'autres (direction, assurance qualité, sous-traitants externes, etc.). J'ai constaté qu'un exercice d'équilibrage est nécessaire - fournir ces mesures, mais aussi fournir des preuves d'actifs incorporels - l'intangible étant ce que chaque programmeur a accompli qui n'est pas nécessairement suivi. Par exemple, j'ai eu un programmeur qui a passé beaucoup de temps à étudier le code hérité que personne d'autre ne voulait toucher. Même si ses paramètres étaient faibles pour cette période, cet effort était inestimable.

Le seul moyen que j'ai trouvé pour inclure de telles choses a été de faire pression pour la création d'une catégorie immatérielle supplémentaire et de lui donner un poids égal aux autres mesures. Habituellement, cela suffit pour faire basculer la balance pour un programmeur particulier.

L'un des problèmes semble être qu'en tant que division / département, les organisations informatiques n'ont pas d'objectifs stratégiques mesurables. S'ils le faisaient, il serait plus facile de fixer des objectifs pour les individus.

Par exemple, s'il y avait une initiative ministérielle pour réduire le nombre de tickets problématiques soulevés, alors, vous pourriez fixer des objectifs individuels en fonction du nombre de tickets liés au logiciel dont ils s'occupent.

Étant donné que le développement de logiciels est en grande partie une collaboration, il serait plus judicieux de fixer des objectifs au niveau de l'équipe, puis d'évaluer les individus en fonction de leur contribution à l'équipe.

Un des objectifs que j'aime est:

Sollicitez N évaluations positives de votre implication dans un projet de la part du client du projet.

Cela aide car il est toujours bon d'avoir des commentaires positifs écrits de la part des clients (internes ou externes). Ce n'est pas difficile à obtenir, c'est pertinent et c'est une coche facile, mais pas dénuée de sens sur la liste.

Déterminer comment aligner le développement personnel avec les projets en cours est un point clé à mon avis. Demander aux développeurs de s'analyser pour trouver des faiblesses et donner des commentaires sur les autres peut être un moyen de trouver ce qui peut être amélioré, puis de trouver un moyen de le mesurer. Par exemple, je peux constater que je documente rarement les éléments terminés et ainsi de suite mes objectifs pour l'année, je peux déclarer que je veux améliorer cela et que la quantité de documentation que je produis peut en être une mesure. Cela peut fonctionner ou cela peut se retourner contre vous selon la façon dont je le suis vraiment. D'une part, il peut y avoir des préoccupations valables pour cela, c'est la façon dont j'améliore mon travail et fais ce qui peut être considéré comme la bonne manière alors qu'une vision passive agressive ou enfantine serait de produire une montagne de documentation si elle n'est pas.

La définition d'un développeur efficace en est un autre élément. Est-ce la personne qui corrige le mieux les bugs? Le nouveau travail est-il le plus rapide? Le nouveau travail est-il complet avec des tests et de la documentation même s'il n'est pas fait rapidement? Qu'est-ce que vous appelez efficace puisque la réponse standard «ça dépend» doit être clarifiée ici.