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

quelle approche a le mieux fonctionné pour vous?

un seul objectif: passer une inspection de code/examen par les pairs, avec moi en tant que l'examinateur, sans que je trouve des bogues ou d'avoir toute autre critique, qui m'a demandé de vous demander de refaire quelque chose.

Notes:

• Je ne mesurais pas la capacité des nouveaux employés à terminer rapidement, et je ne les encourageais pas à le faire: je voulais des gens apprendre à finir (parce que si c'est pas fini bien, alors il n'est pas fini)
• les gens ont appris ce que j'ai cherché dans une révision du code: c'est donc une occasion d'apprentissage et une mesure de contrôle de la qualité, et pas seulement un objectif de gestion
• mes commentaires auraient deux catégories:
  1. c'est un bug: vous devez le corriger avant de vous enregistrer
  2. comme suggestion, j'aurais fait tel ou tel
• après un certain temps, mes examens du code d'une personne cesserait de trouver des éléments" doit corriger " (à ce moment-là, je n'aurais plus besoin de revoir leur travail).

personnellement, J'essaie de fixer deux sortes d'objectifs:

• objectifs axés sur les affaires (c'est pourquoi nous sommes payés après tout). Par exemple,"achever le projet X d'ici au 1er juin 2009"). Ces objectifs sont souvent partagés par plusieurs membres de l'équipe (et ils en sont conscients). 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 par produire plus de fonctionnalités, avoir moins de bugs contre eux, ou coaching et soutenir d'autres membres de l'équipe.

• objectifs de croissance personnelle, par exemple la réalisation d'un projet impliquant une technologie que le développeur veut ajouter à leur ensemble de compétences, une meilleure compréhension du domaine de l'utilisateur, l'acquisition d'une expérience de leadership, etc.

je pense qu'il est important que:

• les objectifs sont intelligents
• les objectifs sont alignés 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 l'occasion de dépasser les objectifs que vous lui avez fixés

enfin, je resterais à l'écart de la métrique logicielle comme objectifs - ils sont trop faciles à Jouer et ne vous donneront probablement pas ce dont vous avez besoin. Je n'utiliserais une métrique que si 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 cadres 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 passaient 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 qui des développeurs effectue dans termes de productivité et de sensibilisation à la qualité. Une véritable approche agile exige que non seulement les développeurs, mais aussi les concepteurs, les testeurs, les clients et les gestionnaires de produits soient inclus dans le processus. Cela conduit naturellement à une meilleure compréhension du point de vue des gestionnaires.

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

• réussir un examen d'attestation
• la Recherche de la technologie de X et de tenir une présentation à ce sujet
• nombre de changements de rupture de construction commis
• nombre d'articles wiki écrits sur la gestion des connaissances internes

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

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

doit fixer des objectifs pour les développeurs, même si elles ne sont pas emploi 151920920"

si vos développeurs ne fonctionnent pas, peut-être que certains objectifs sont juste ce dont ils ont besoin pour leur donner une certaine incitation? ;- )

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

le problème, c'est que nos objectifs progressifs changent. Les affaires changent 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 qui correspondent à l'objectif de votre équipe ou de votre groupe organisation. Votre équipe ne serait pas financée si elle ne servait pas un objectif - un objectif macro. Avoir des objectifs collectifs qui existent dans l'ensemble de votre équipe et qui s'harmonisent à l'entreprise. Donner aux gens la responsabilité et tenir les gens responsables. Célébrez leurs réussites et leurs échecs (si nous n'échouons pas parfois, nous n'essaierons probablement pas et c'est ce que vous voulez des gens). HTH

nous avons un certain nombre de mesures qui sont recueillies comme les programmeurs ne fonctionnent, tels que:

• nombre de SLOC changé / ajouté
• nombre d'erreurs / bogues injectés à diverses étapes du processus (au cours de l'examen par les pairs, après l'examen par les pairs, après la publication)
• demandes de modification satisfaites /rejetées
• documents officiels (descriptions de versions de logiciels, documents de conception, etc.)

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

Malheureusement, nous vivons tous dans un monde où les mesures sont exigées par autres (Gestion, assurance Qualité, contractants extérieurs, etc.)). J'ai constaté qu'il faut trouver un juste équilibre - en fournissant ces paramètres, mais aussi en fournissant des preuves d'éléments intangibles - intangibles é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 à enquêter sur le code d'héritage que personne d'autre ne voulait toucher. Même si ses mesures étaient faibles pour cette période de temps, cet effort a été inestimable.

le seul moyen que j'ai trouvé pour inclure de telles choses a été de pousser à la création d'une catégorie intangible supplémentaire et de lui donner un poids égal avec les autres mesures. Habituellement, cela est suffisant pour balancer l'équilibre pour un programmeur.

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. Si ils l'ont fait, il serait plus facile de fixer les objectifs pour les individus.

p. ex. S'il y avait une initiative ministérielle pour réduire le nombre de billets à problème soulevés, alors, vous pourriez fixer un objectif individuel basé sur le nombre de billets liés au logiciel dont ils s'occupent.

depuis le développement du logiciel est il serait plus logique de fixer des objectifs au niveau de l'équipe, puis de noter les individus en fonction de leur contribution à l'équipe.

déterminer comment aligner le développement personnel avec les projets en cours est un point clé dans ce que je pense. Le fait que les développeurs s'analysent eux-mêmes pour trouver des faiblesses en même temps que de donner des commentaires sur les autres peut être un moyen de trouver ce qui peut être amélioré et ensuite trouver un moyen de le mesurer. Par exemple, je pourrais constater que je documente rarement les éléments complétés et ainsi de suite sur mes objectifs pour l'année je peux dire que je veux améliorer ceci et que la quantité de documentation que je produit peut être un mesure de qui. Cela peut fonctionner ou cela peut se retourner contre moi en fonction de la façon dont je le suis vraiment. D'une part, il peut y avoir des préoccupations valables pour ce qui est de la façon dont j'améliore mon travail et de faire ce qui peut être considéré comme la bonne façon alors qu'une vision passive agressive ou enfantine serait de produire une montagne de documentation si ce n'est pas aussi bon en termes de qualité que cela peut être amélioré l'année prochaine car cela peut être un autre point à considérer: ce qui est censé être la motivation pour améliorer autant que possible tout en une année par rapport à l'espacement des choses?

définir un développeur efficace est un autre élément à cela. Est-ce la personne qui corrige le mieux les bugs? N'nouveau travail plus rapide? N'nouveau travail complet avec des tests et de la documentation, même si elle n'est pas rapide? Qu'est-ce que vous appelez efficace puisque "cela dépend" la réponse standard devrait être clarifiée ici.

Un des objectifs que j'aime c'est:

sollicitez du client du projet des commentaires positifs sur votre participation à un projet.

Cette aide, car il est toujours bon d'avoir des retours positifs des clients (internes ou externes). Ce n'est pas difficile à obtenir, sa pertinence et il est un facile, mais pas insignifiant coche sur la liste.