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

84

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:


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é!

Paul Stephenson
la source
16
Je préfère la méthodologie DUMB: "Do Ur Most Best".
Robert S.
3
Beaucoup de liens brisés.
crh225
Les liens sont rompus
Rodrigo Leite

Réponses:

21

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).
ChrisW
la source
Merci, j'aime ça. Lorsque je révise leur code, je suis généralement assez anal sur des choses pas si urgentes mais importantes à long terme comme la dénomination des variables et le style de code. Un objectif comme celui-ci pourrait les inciter à réfléchir plus rapidement à moi!
Paul Stephenson
6
J'aime ça aussi, mais cela pourrait conduire à un modèle de développement aveugle où tout le monde essaie simplement de VOUS plaire au détriment possible du meilleur code objectivement. Combien de défauts dans votre propre approche avez-vous corrigés au fil des ans, combien estimeriez-vous qu'il reste à aplanir?
Ed Guiness
1
Pour moi, la dénomination des variables et le style de code appartiennent à la 2ème catégorie; sauf si le style est vraiment mauvais, par exemple en réutilisant une variable pour trop de différences, je pourrais dire "vous devrez retravailler ceci parce que c'est trop compliqué pour moi de l'examiner, je ne peux pas voir" par inspection "si c'est correct" .
ChrisW
Heh, évidemment je sais ce qui est objectivement le mieux :-). Mais oui, ils pourraient passer du temps à satisfaire mes bizarreries folles au lieu de faire des choses plus utiles. Je pense que cela fonctionnerait mieux pour les nouveaux développeurs que pour les anciens.
Paul Stephenson
@edg: c'est vrai pour "blinkered" et "essayer de me plaire", mais leur code devait aussi, bien sûr, passer les tests du système de boîte noire de QA. Et le fait de juger si je pourrais ou non maintenir leur code si nécessaire est une mesure assez objective (pas seulement subjective), n'est-ce pas?
ChrisW
14

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.

Offres
la source
9

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.

Martin Wickman
la source
1
Je suis essentiellement un chef d'équipe et je fais partie de la planification et du développement quotidiens. Je pense aussi que le niveau de performance de chaque développeur est "évident", mais c'est mon opinion subjective et cela ne cadre pas avec les objectifs, donc ils deviennent inutiles. Je préférerais que nous puissions les ignorer complètement!
Paul Stephenson
Le fait est que vous ne pouvez obtenir aucune mesure scientifique ici, donc essayer de le faire est voué à l'échec et vous devriez passer du temps ailleurs dans le monde. martinfowler.com/bliki/CannotMeasureProductivity.html a un article à ce sujet.
Martin Wickman
8

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?

Petteri H
la source
1
Tout sauf briser la construction est mon approche 1: ce qui se passe, c'est que les bons développeurs disent "J'étais trop occupé à faire ce projet critique sur lequel vous m'aviez demandé de travailler, donc je n'ai pas fait la présentation ni écrit l'article". Je ne peux pas les pénaliser pour cela, alors les objectifs perdent leur sens.
Paul Stephenson
1
idem ce que Paul a dit, et j'aurais un problème avec quelque chose d'aussi éphémère que d'écrire des articles wiki - étaient-ils bons? sont-ils toujours là? qu'en est-il de l'édition des contributions? avaient-ils même du temps libre pour ça?
annakata le
8

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? ;-)

Andrzej Doyle
la source
3
+1 pour l'humour: je me suis demandé si c'était ambigu, mais j'ai décidé que si vous avez délibérément mal compris :-)
Paul Stephenson
2
Notez que quelqu'un a changé le titre en "même si (les objectifs) ne fonctionnent pas". Depuis, je l'ai resserré à «même si les objectifs ne fonctionnent pas». Il suffit d'ajouter le commentaire pour quiconque est confus par cette réponse!
Paul Stephenson
7

"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.

Ed Guiness
la source
1
Définissez «exercé». Si vous n'utilisez que des outils de couverture, il est facile d'obtenir le code à exécuter sans l'exercer réellement.
Kent Boogaart
@Kent, je voulais dire exercice == exécuter. Pourriez-vous expliquer comment l'exécution n'est pas un exercice et je mettrai volontiers à jour ma suggestion
Ed Guiness
Sûr. Écrivez simplement un test unitaire qui appelle votre méthode mais ne fait aucune affirmation sur les résultats de l'appel. Vous avez exécuté le code - donnant ainsi une couverture de code plus élevée - sans réellement prouver qu'il est fonctionnellement correct.
Kent Boogaart
Merci, quelque chose comme ça pourrait être réalisable, car les tests unitaires deviendront partie intégrante de leur travail de développement et de maintenance. Il peut y avoir des problèmes avec les gens qui écrivent des tests unitaires sans valeur pour atteindre l'objectif alors qu'ils pourraient faire un travail plus utile, cependant.
Paul Stephenson
D'accord, il y aura probablement toujours des moyens de jouer avec une mesure spécifique, ce qui renforce en quelque sorte le point OP.
Ed Guiness
4

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

Eric Sabine
la source
3

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.

Matt Jordan
la source
2

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.

James Anderson
la source
1
+1 pour fixer des objectifs uniquement au niveau de l'équipe. Épingler chaque ticket problème sur un individu est démotivant, détruit l'esprit d'équipe et donne souvent une mesure biaisée et inexacte de la situation réelle, surtout si le nombre de tickets problème probables est assez faible (par exemple environ un par développeur).
Paul Stephenson
1

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.

Nat
la source
Et si vous travaillez toute l'année sur un seul projet qui n'a pas été livré aux clients? 0 avis. Et si vous travaillez sur un site Web générique sans liste de clients définie?
jmucchiello le
1
Dans les deux cas, vous travaillez toujours sur un projet qui a des clients, qu'ils soient internes ou non. Vous sollicitez un examen de votre implication avec le client, pas un examen du projet.
Nat
1

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.

JB King
la source