Avoir à fixer des objectifs pour les développeurs, même si les objectifs ne fonctionnent pas

Question

Il est généralement admis que le réglage des objectifs mesurables pour les développeurs de logiciels ne fonctionne pas , comme trop l'accent sur les objectifs peut conduire à des comportements à l'encontre des objectifs organisationnels (les soi-disant "mesure de la dysfonction").

Cependant, dans mon entreprise, nous sommes tenus de fixer des objectifs pour l'ensemble du personnel, et sont encouragés par les Ressources Humaines pour les rendre INTELLIGENTS. Dans le passé, mes collègues de premier niveau des cadres (chefs d'équipe) et j'ai essayé un certain nombre d'approches:

1. Fixer des objectifs mesurables qui sont complémentaires à la normale du travail, comme "Faire de la formation sur la technologie X", "Créer de la documentation pour le morceau de code Y, que personne ne comprend" et ainsi de suite. Quand il s'agit de l'évaluation annuelle du rendement, taux de développeurs de ne pas sur les objectifs, mais, plutôt, à mon avis, de l'incommensurable valeur de leur travail normal, puisque c'est effectivement ce que l'entreprise se soucie de.
2. Définir des objectifs très spécifiques comme les "journées de travail fait qu'enregistrée par le groupe de gestion du système", "nombre de bugs introduits", "numéro de production émis causé". Cela a conduit à gonflement des estimations et de la classification incorrecte des bugs, afin d'obtenir de meilleurs "scores". Il est intéressant de noter, même les développeurs de notation fortement sur ce système n'aiment pas, que la valeur intrinsèque de la confiance au sein de l'équipe a été endommagé et qu'ils n'ont pas toujours le sentiment qu'ils ont mérité leur haute position.
3. Jeu de vagues objectifs qui sont des variantes sur "Faites votre travail normal". Quand il s'agit de l'évaluation annuelle, leur classement ne reflète pas les performances par rapport aux objectifs, mais les objectifs eux-mêmes ne sont pas mesurables ou réalisables, ce qui est mal vu.

Aucune n'est idéale. Si vous avez été dans une situation similaire, d'avoir à créer des objectifs mesurables pour les développeurs de logiciels, en dépit de la preuve à l'encontre de leur efficacité, de l'approche qui a le mieux fonctionné pour vous?

---

Liés à des questions que j'ai trouvé qui ne sont pas tout à fait adresse le même point:

• Quels sont les bons objectifs de performance pour un ingénieur logiciel?
• Réglage des objectifs de Performance pour les Développeurs
• Quelles sont approprié des indicateurs de performance pour les programmeurs?
• Qu'est ce qu'une juste mesure de la productivité technique pour les programmeurs?
• J'ai besoin de quelques carrière "Objectifs" pour l'année prochaine

---

Mise à jour (18 novembre 2009): Il y a 10 upvotes pour ma question, et les plus appréciées des réponses ont seulement 4 upvotes (y compris une de moi). Je pense que cela nous dit quelque chose: peut-être que Joël et les autres sont de droite, et que la combinaison de la sagesse de stackoverflow ne peut pas venir avec tout convaincante, des objectifs mesurables pour les développeurs qui ne peut pas être gamed sans nuire à la vraie (non mesurable) de la valeur de leur travail. Merci pour essayer de bien!

Answer 1

quelle est l'approche qui a le mieux fonctionné pour vous?

Un seul objectif: l'adoption d'un code d'inspection/d'examen par les pairs, avec moi, comme le critique, sans me trouver tous les bogues ou d'avoir une autre critique, qui m'a permis de vous demander de refaire quelque chose.

Notes:

• Je n'étais pas en mesure de nouveaux employés " capacité à terminer rapidement, et ne pas les encourager à: je voulais que les gens à apprendre à finir (parce que si c'est pas fini bien, alors il n'est pas fini)
• Les gens ont appris ce que je recherchais chez une révision du code: c'est donc une occasion d'apprentissage et un contrôle de qualité, et pas seulement un objectif de gestion
• Mon commentaire aurait deux catégories:
  1. C'est un bug: vous devez corriger cela avant de vous enregistrer
  2. Comme une suggestion, je l'aurais fait telles et telles
• Après un certain temps, mes commentaires d'une personne de code d'arrêter de le trouver "doit fixer les éléments" (à laquelle je n'aurais pas besoin de réviser leur travail).

Answer 2

Personnellement, j'essaie de définir deux sortes d'objectifs:

• Axés sur les objectifs (c'est pourquoi nous sommes payés, après tout). Par exemple, "projet X en 1 juin 2009"). Ces objectifs sont souvent partagées entre plusieurs membres de l'équipe (et ils sont conscients de cela). L'équipe peut dépasser, l'objectif en mettant le projet en début ou en dépassant les fonctionnalités nécessaires. Les individus peuvent dépasser, l'objectif en produisant plus de fonctionnalités, d'avoir moins de bugs, ou le coaching et le soutien d'autres membres de l'équipe.

• Personnel les objectifs de croissance, par exemple la réalisation d'un projet portant sur une technologie que le développeur veut ajouter à leurs compétences, de la compréhension du domaine de l'utilisateur de mieux, de gagner de l'expérience en leadership, etc.

Je pense qu'il est important que:

• Les objectifs sont SMART
• Les objectifs sont en adéquation avec les besoins de l'entreprise
• Vous incluez "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 définissez

Enfin, je voudrais rester à l'écart de la métrique de logiciel par objectifs, ils sont trop faciles pour le jeu et ne sera probablement pas vous donner ce dont vous avez besoin. Je tiens seulement à l'utilisation d'une métrique où je veux quelqu'un entraîneur ou d'un comportement particulier.

Answer 3

Tout cela se résume au fait que "le premier niveau de gestion", et la plupart de gestion ne sait pas à leurs employés. Au lieu de faire partie de l'effectif de jour à jour de la planification et du développement, des choses comme SMART pop-up. Si les gestionnaires ont à passer plus de temps avec le gars qui fait tout le boulot, rien de tout cela serait nécessaire.

Personnellement, je préfère travailler dans un environnement agile où il est évident qui des développeurs effectue en termes de productivité et de sensibilisation à la qualité. Un vrai agile approche requiert non seulement de développeurs, de designers, testeurs, les clients et les chefs de produit sont inclus dans le processus. Cela conduit naturellement à une meilleure perception par les chefs de point de vue.

Answer 4

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

• Passer un certificat d'examen
• La recherche de la technologie de X et de tenir une présentation à ce sujet
• Nombre de construire des modifications importantes de la commis
• Nombre de wiki les articles écrits sur la gestion des connaissances internes

Pourquoi ne pas demander à vos développeurs directement s'ils ont quelques idées pour le développement personnel, qui pourront ensuite être utilisées à des objectifs?

Answer 5

"Veiller à ce qu'au moins n% de votre code est testé par un test unitaire" Utiliser un outil de couverture pour le prouver, et avoir quelqu'un d'autre examen pour le test de qualité.