Un conte à partir de l'expérience personnelle. Mes excuses pour la longueur.
Il y A quelques années, notre groupe de développement essayé paramètre "propres", des objectifs mesurables pour les particuliers et les chefs d'équipe. L'expérience a duré à peine un an, parce que dur métriques n'a pas vraiment très bien pour les objectifs individuels (voir ma question sur le sujet pour certains liens, et d'autres discussions).
Notez que j'ai été un chef d'équipe, et de les impliquer dans la planification de tout cela avec ma technique de boss et les autres chefs d'équipe, de sorte que les objectifs n'étaient pas quelque chose de dictée d'en haut par un ignorant de la haute direction à l'époque, nous voulions vraiment à travailler. Il est également intéressant de noter que la structure de bonus, par inadvertance, encourage la concurrence entre les développeurs. Voici mes observations sur les choses que nous avons essayé.
Client-visible questions
Dans notre cas, nous avons compté les pannes sur le service que nous avons fourni aux clients. Dans un film rétractable produit, il pourrait être le nombre de bugs signalés par les clients.
Avantages: C'était la seule vraie mesure qui a été visible à la haute direction. Il a également été le plus objectif, mesuré à l'extérieur du groupe de développement.
Inconvénients: Il n'y avait pas beaucoup de pannes -- juste autour de l'un par le développeur de l'ensemble de l'année, ce qui signifiait que le défaut ou le dépassement de l'objectif a été question de "l'épinglage de blâmer" les quelques pannes qui se produisent dans chaque équipe. Cela a conduit à de mauvais sentiments et de la perte de moral.
Quantité de travail accompli
Avantages: C'était le seul positif de la mesure. Tout le reste a été "nous avons remarqué lors de mauvaises choses arrivent," qui était démoralisant. Son inclusion a été aussi nécessaire, car, sans cela, un développeur qui n'a rien fait tout l'exercice dépasse tous les autres objectifs, qui, clairement, ne serait pas dans l'intérêt de la société. La mesure de la quantité de travail accompli vérifié l'optimisme naturel des développeurs lors de l'estimation de la taille des tâches, ce qui est utile.
Inconvénients: La mesure de "travail terminé" a été basé sur les estimations fournies par les développeurs eux-mêmes (généralement une bonne chose), mais il fait partie de leurs objectifs encouragé jeu du système pour gonfler les estimations. Nous n'avions pas viable mesure du travail accompli: je pense que la seule manière valable de mesure de la productivité est "l'impact sur les résultats de l'entreprise," mais la plupart des développeurs sont si éloignés de la vente directe que c'est rarement pratique à un niveau individuel.
Les défauts présents dans le nouveau code de production
Nous avons mesuré les défauts introduits dans le nouveau code de production au cours de l'année, comme il a été estimé que les bugs de la précédente ans ne devrait pas compter l'encontre de toute personne dans cette les objectifs de l'année. Les défauts repérés par la qualité interne des équipes ont été inclus dans le décompte, même si ils n'ont pas d'incidence sur les clients.
Avantages: Étonnamment peu. Le décalage dans le temps entre l'introduction d'un défaut et de sa découverte signifiait qu'il y avait vraiment aucun mécanisme de rétroaction pour améliorer la qualité du code. Macro-tendances au niveau de l'équipe ont été plus utile.
Inconvénients: Il y avait un accent lourd sur le négatif, étant donné que cet objectif a été invoqué lorsqu'un défaut a été trouvé et nous avons besoin de quelqu'un à blâmer pour cela. Les développeurs sont réticents à enregistrer les défauts qu'ils ont trouvé eux-mêmes, et un simple comptage signifiait que des bugs mineurs ont été aussi mauvais que de graves problèmes. Étant donné que le nombre de défauts par individu était encore assez faible, le nombre de mineurs et de graves défauts n'ai même pas comme il le peut avec un échantillon plus grand. Vieux défauts n'ont pas été inclus, de sorte que la réputation du groupe pour la qualité du code (basé sur tous les bugs trouvés) ne correspondent pas toujours à la mesurables introduit cette année le comte.
La rapidité de la livraison du projet
Nous avons mesuré la rapidité que le pourcentage de travail à l'interne équipes QA par la date d'échéance indiquée.
Avantages: à la différence de comptage des défauts, c'était une mesure qui a été immédiat, le contrôle direct de la part des développeurs, qu'ils ont effectivement décidé, quand le travail était terminé. La présence de l'objectif concentre l'esprit sur la façon de remplir les tâches. Cela a permis à l'équipe de s'engager à réaliste quantités de travail, et l'amélioration de la perception par les clients internes du groupe pour le développement de la capacité à tenir ses promesses.
Inconvénients: le seul objectif directement sous les développeurs de contrôle, il a été maximisée au détriment de la qualité du code: le jour d'une date limite, étant donné le choix entre dire qu'une tâche est terminée ou de faire d'autres tests pour améliorer la confiance dans la qualité, le développeur devra choisir de marquer il complète et l'espoir de tout les bugs ne viennent jamais à la surface.
Les plaintes des clients internes
Pour évaluer la mesure dans laquelle les développeurs communiqué avec les clients internes au cours du développement et de soutien ultérieur de leur logiciel, nous avons décidé que le nombre de plaintes reçues au sujet de chaque personne serait enregistrée. Les plaintes seraient validées par le gestionnaire, afin d'éviter toute envie de vengeance.
Avantages: Vraiment rien, je me souviens. Mesurée à un groupe suffisamment grand niveau, il devient plus utile pour la "satisfaction du client" score.
Inconvénients: Non seulement très négatif, mais aussi une mesure subjective. Comme avec d'autres objectifs, les chiffres de chaque individu ont été autour de la barre du zéro, ce qui signifie qu'un seul commentaire à propos de quelqu'un qui pourrait signifier la différence entre "l'infiniment dépassé" et "ne pas répondre".
Commentaires généraux
La bureaucratie: Alors que notre mission des outils de gestion a tenu une grande partie des données pour ces indicateurs, il y a encore beaucoup d'efforts consacrés à rassembler tout cela. Le temps consacré à l'obtention de tous les nombres n'était pas agréable, généralement porté sur les aspects négatifs de nos travaux et peuvent même ne pas avoir été remis en état par l'augmentation de la productivité.
Moral: Pour les mesures où les individus ont été blâmés pour des problèmes, pas seulement ceux de "mauvais" scores se sentent démotivés, mais ceux avec les "bons" scores, car elles n'ont pas, comme la perte de moral du groupe et s'est parfois senti qu'ils étaient d'un rang plus élevé, non pas parce qu'ils sont meilleurs, mais parce qu'ils ont eu plus de chance.
Résumé
Qu'avons-nous donc apprendre à partir de l'épisode? Dans les dernières années, nous avons essayé de ré-utiliser certaines des idées, mais dans un "plus doux", où il y avait moins d'accent sur l'individu blâmer et plus sur l'équipe d'amélioration.
- Il est impossible de définir des objectifs pour les développeurs individuels qui sont objectivement mesurables, ajouter de la valeur à l'entreprise et ne peut pas être gamed, donc ne vous embêtez pas à essayer.
- Les problèmes des clients et les défauts peuvent être comptés à un plus large niveau de l'équipe, si l'emplacement du défaut est, sans équivoque, la responsabilité de l'équipe-qui est, vous n'avez pas à jouer le "jeu du blâme".
- Une fois que vous mesurer uniquement les défauts au niveau de la responsabilité d'un module de code, vous pouvez (et devriez) mesure de vieilles bugs ainsi que les nouveaux, car il est dans l'intérêt du groupe pour éliminer tous les défauts.
- La mesure de défaut de compte au niveau du groupe, augmente la taille de l'échantillon par groupe, et donc des anomalies entre les mineurs et de graves défauts sont lissés et un simple "nombre de bugs" mesure peut signifier quelque chose, comme pour voir si vous êtes l'amélioration de mois à mois.
- Inclure quelque chose que la direction supérieure de soins, parce que les garder heureux est votre objectif principal en tant que groupe de développement. Dans notre cas, c'était à la clientèle-visible des pannes, de sorte que même si la mesure est parfois arbitraire ou apparemment injuste, si c'est ce que les patrons sont de mesure, alors vous devez prendre l'avis de trop.
- La haute direction n'avez pas besoin de voir les mesures qu'ils n'ont pas dans leurs propres objectifs. De cette manière, il évite la tentation de blâmer les individus pour les erreurs.
- La mesure des délais de livraison du projet n'a changement de développeur de comportement et de mettre l'accent sur l'achèvement de tâches. Il a amélioré l'estimation et permis au groupe de faire des promesses. Si c'était facile de recueillir la rapidité de l'information, alors je voudrais envisager de l'utiliser à nouveau à un niveau de l'équipe, afin de mesurer l'amélioration au fil du temps.
Tout cela n'aide pas lorsque vous avez besoin de fixer des objectifs mesurables pour les développeurs individuels, mais j'espère que les idées vont être plus utile pour l'équipe d'amélioration.
