Quel est un bon objectif SMART pour un programmeur?
À la suite de cette question , je me demandais si les gens pouvaient suggérer des exemples de ce qui pourrait être considéré comme un "bon" objectif dans un cycle de révision périodique pour un programmeur?
Définissons SMART à partir des définitions les plus populaires de la entrée Wikipedia :
- Spécifique
- Mesurable
- Réalisable
- Pertinent
- Limité dans le temps
Je me suis rendu compte que les objectifs SMART sont mieux utilisés lorsque les gens ont une carence qu'ils doivent corriger et ne sont pas si bons pour les moments où vous voulez que les gens grandissent ou passent de bons à grands. Si quelqu'un ne fait pas de feuilles de temps, par exemple, et cela nuit à l'entreprise parce que vous devez parfois retarder la facturation, vous pourriez avoir un objectif intelligent comme "au cours des 6 prochaines semaines, au moins 5 semaines de feuilles de temps seront remplies à 10 heures du matin. Lundi matin suivant. "6 semaines plus tard, vous avez un vrai ou un faux; le développeur l'a fait ou l'a manqué. Soit la nouvelle habitude est en place, soit vous décidez si vous voulez toujours employer quelqu'un qui ne craint pas de retarder votre facturation . Fonctionne également pour les personnes qui ont d'autres mauvaises habitudes: "au cours des deux prochaines semaines, au moins 75% de vos enregistrements auront un commentaire d'enregistrement qui suit les consignes d'enregistrement (lien vers le document interne)." Encore une fois, vous avez un Nice crisp did/pas à la fin de ce court laps de temps.
Là où je trouve ces constructions moins utiles, c'est lorsque le délai s'allonge, lorsque la réalisation que vous voulez est floue (apprendre une langue, être plus utile), ou quand ça va si l'objectif n'est pas atteint (vous pouvez valoriser les certifications, mais si quelqu'un a échoué leur test, vous ne prendriez probablement pas de mesures disciplinaires.) Soudain, tous les avantages de l'objectif intelligent disparaissent. N'essayez pas de les utiliser pour autre chose que des actions correctives, et ils sont faciles à écrire, ils aident le développeur à atteindre le niveau attendu et ils sont faciles à tester lorsque le temps est écoulé. Avoir du mal à les écrire signifie qu'ils ne sont pas le bon outil pour atteindre cet objectif.
Puisque je suis sur le point d'entrer dans une conversation de définition d'objectifs avec mon patron, j'ai pensé ajouter quelques exemples qui sont similaires à certains que j'envisage de me suggérer:
- Augmentez la couverture des tests pour le code du projet X à au moins 95% d'ici le 31 mars.
- Terminer et distribuer la première ébauche du document d'architecture du projet Y d'ici le 30 avril
- Recueillir les commentaires de révision pour le document d'architecture, mettre à jour si nécessaire et publier la v1.-0 du document d'ici le 30 juin
Je m'attends à ce que du travail supplémentaire se matérialise dans les délais que j'ai spécifiés (il en a toujours avant, après tout) et ce travail peut avoir un effet sur l'aspect "opportun" en particulier. Cela ne devrait pas être un problème: les objectifs devraient être réexaminés régulièrement pour s'assurer qu'ils continuent de répondre au critère "réalisable". Je vais devoir m'assurer de garder mon manager informé - personne n'aime les mauvaises surprises de fin d'année ...
Si vous vendez un logiciel ou un produit contenant un logiciel ...
Augmenter les ventes n%.
Vraiment.
Si le logiciel ne fonctionnait pas, vous n'en vendriez pas beaucoup.
Si le logiciel fonctionnait VRAIMENT RALLYEZ BIEN, vous vendriez des lots.
(Cela permettra aux gars du logiciel de surveiller les vendeurs comme les faucons pour s'assurer qu'ils ne dépensent pas leur bonus de performance.)
Si votre logiciel est un système interne:
réduction du coût de l'entreprise n%.
Si les nouveaux systèmes logiciels prennent 10 fois plus de temps, cela coûte de l'argent à l'entreprise. Si le nouveau système est rapide et empêche les erreurs, l'entreprise économise de l'argent.
Cette approche semble s'appliquer aux vendeurs ou peut-être au vice-président du processus de changement commercial, mais en réalité, les développeurs de logiciels sont en première ligne pour les deux types de processus.
Mon idée sous-jacente ici est d'essayer d'aligner explicitement la structure de récompense des employés avec le meilleur résultat possible pour l'entreprise.