Comment savoir si vos programmeurs sont sous-performants?
Je suis chef d'équipe avec plus de 5 développeurs. J'ai un développeur (appelons-le UN ) qui est un bon programmeur, qui écrit du bon code propre et facile à comprendre. Cependant, il est quelque peu difficile à gérer, et parfois je me demande s'il est vraiment sous-performant ou non.
- Notre entreprise demande aux développeurs d'indiquer la progression du travail dans le suivi des bogues que nous utilisons, non pas tant pour surveiller les programmeurs que pour tenir les parties prenantes informées de la progression. La chose est, [[# #]] a [~ # ~] ne met à jour la progression d'une tâche que lorsqu'elle est terminée (peut-être 3 semaines après son premier travail) et cela laisse tout le monde se demandant ce qui se passe au milieu de la semaine de développement. Il ne changerait pas ses habitudes malgré des sondages répétés. (Ce n'est pas grave, les développeurs détestent la paperasse, moi aussi)
- Au cours des deux ou trois derniers mois, il est en congé assez souvent en raison de divers événements - soit il est malade, soit il doit assister à de nombreux événements personnels, etc.
- Nous définissons des sprints, ou feuilles de route pour chaque mois. Et au début du sprint, nous discuterons de la quantité de travail que chacun des développeurs doit faire dans un sprint et du les développeurs peuvent définir le temps dont ils ont besoin pour chaque tâche. Il ne sera généralement pas en mesure de les terminer tous. (C'est bon, les développeurs manquent régulièrement de délais non pas à cause de leur faute).
- Je suis basé à Singapour. Je ne sais pas si cela compte. Oui, les Asiatiques sont connus pour être réticents, mais est-ce important?
Si seulement un ou deux des événements ci-dessus se produisent, je ne sentirai pas que A est sous-performant, mais ils se produisent tous ensemble. J'ai donc l'impression que UN est sous-performant et peut-être-- Dieu nous en préserve --- se relâcher.
C'est juste un sentiment basé sur mes années d'expérience en tant que programmeur. Mais je peux me tromper.
Il est notoirement difficile de mesurer le travail d'un programmeur, étant donné que les deux tâches ne sont pas toutes identiques, et il manque un objectif standard pour mesurer l'engagement d'un programmeur envers votre entreprise. Il est carrément impossible de dire si le programmeur fait son travail ou se relâche. Tout ce que vous pouvez faire, c'est leur faire confiance - oui, leur faire confiance et leur donner de l'autonomie est le meilleur moyen pour les programmeurs de travailler, je sais que, besoin de faire confiance à vos programmeurs, merci beaucoup - mais s'ils abusent de votre confiance, pouvez-vous le savoir?
Résultat:
J'ai une conversation directe avec lui concernant ma perception de sa performance. Il était indigné quand j'ai suggéré que j'avais le sentiment qu'il ne jouait pas à son meilleur niveau. Il a estimé que c'était un sentiment complètement injuste. J'ai alors répondu que c'était mon sentiment et je ne savais pas si mon sentiment était bon ou non. Il n'aurait rien de tout cela et a mis fin immédiatement à la discussion.
Avant de partir, il a dit qu'il "essaierait de donner plus à l'entreprise" sur un ton très froid. J'ai été surpris par sa réaction. Je suis sûr que je l'ai offensé à certains égards. Je ne sais pas trop si c'était la bonne chose à faire pour que je sois si franc avec lui, cependant.
Ma question est: comment savoir si vos programmeurs sont sous-performants? Il y a sûrement des chefs d'équipe d'expérience qui connaissent mieux que moi à ce sujet?
Notes supplémentaires:
- Je déteste la microgestion. Donc, tout ce que nous avons pour notre processus logiciel est Sprint (où les tâches sont hiérarchisées et attribuées, et à la fin du mois, un examen de la quantité de travail effectué). Les développeurs devraient mettre à jour les tâches au fur et à mesure de leur progression quotidienne.
- Il n'y a pas de réunion debout, ni rien de ce genre. Principalement parce que nous avons la liberté de travailler à domicile et que tout le monde chérit cette liberté.
- Bien que ce soit moi qui fixe la date limite, mais les développeurs fourniront l'estimation de chaque tâche et je déciderai - en fonction de l'estimation - les tâches qui entrent dans un sprint particulier. S'ils ne peuvent pas terminer les tâches à la fin du sprint, je les pousserai au suivant. Donc, théoriquement, on ne peut faire que 1 ou 2 tâches pendant tout le sprint, puis pousser les 99 tâches restantes au sprint suivant et il ira bien aussi longtemps que cela le justifie - sous la forme de mises à jour quotidiennes de la progression du travail
Cela devrait être un problème étonnamment facile à résoudre.
Avoir une deuxième rencontre avec lui. Dites-lui que vous acceptez que c'est probablement votre perception de la réalité qui est en cause. Puis qualifiez cela avec "cependant, si c'est le cas, alors nous devons travailler ensemble pour améliorer ma perception." Enfin mettez-le au défi de résoudre ce problème afin qu'il ne se sente pas micro-géré.
Cette chose exacte m'est arrivée il y a longtemps. Pour moi, le problème était que je n'aime pas la possibilité que quelqu'un pense que je cherche un crédit supplémentaire pour simplement faire mon travail. Et c'était assez juste, mais il doit y avoir une boucle de rétroaction régulière entre tout membre du personnel et leur supérieur hiérarchique.
Si ce n'est pas le cas, vous obtenez ces problèmes.
Régulier, planifié, 1: 1 est une excellente idée. Et, comme les gens l'ont souligné, les standups n'ont pas besoin d'être orthogonaux au travail à domicile. Mais elles doivent impliquer les trois questions: qu'avez-vous fait hier? Que comptez-vous faire aujourd'hui? Et celui que la plupart des gens oublient ... Qu'est-ce qui (le cas échéant) vous retient?
Cela dit, vous devriez essayer de décourager les situations où les membres de l'équipe ne travaillent jamais ensemble. J'ai déjà travaillé dans cette situation auparavant et cela a semé la méfiance au sein de l'équipe et à l'extérieur. Ayez une journée régulière où vous venez tous au bureau. Organisez une réunion régulière où les gens peuvent exprimer leurs idées sur l'amélioration des processus ou quoi que ce soit.
N'en faites pas un événement de reportage en ligne. Faites-en une occasion de simplement parler. Vous serez surpris de ce que vous apprendrez. Si possible, transformez cela en un événement social, optez pour quelques verres sur le temps de travail comme un exercice de liaison.
Il y a beaucoup de bons conseils ici, et je ne veux pas en retirer quoi que ce soit, donc je poste ceci comme une réponse distincte.
Tout d'abord, il est évident pour moi (et apparemment pour d'autres) que vous n'avez pas découvert la racine du problème . Vous regardez un symptôme et essayez de le guérir. Vous devez découvrir ce qui cause tant de friction entre vous et ce développeur. Peut-être que vous êtes trop autoritaire (ma propriétaire de produit s'est récemment décrite comme ayant "Infinite Power" sur un projet et cela m'a choqué, même si elle a ri quand elle l'a dit). Peut-être qu'il a de graves problèmes familiaux (expliquerait tout le temps sans travail). Il y a un problème racine ici, et jusqu'à ce que vous le trouviez, cela ne sera pas corrigé.
Bonne prise!
Si sa performance pourrait être meilleure, c'est bien que vous l'ayez déterminé. Rappelez-vous cependant que si ses mauvaises performances sont toujours de bonnes performances en comparaison, vous devez faire preuve de prudence pour éviter de perdre un bon développeur. Les bons développeurs sont difficiles à trouver et les bons développeurs nécessitent un ensemble de choses très spécifique. Jetez un œil au Joel Test pour voir si ses besoins sont satisfaits.
Trouver la source du problème
S'il n'est pas satisfait de quelque chose lié au travail qu'il fait, vous ne pouvez le résoudre qu'en déterminant la source du problème. Permettez-moi d'être clair, vous avez dit que votre programmeur avait écrit du bon code. Cela signifie qu'il aime la programmation. Il est plus qu'évident qu'il est frustré au travail (d'après votre description de la réunion), et vous avez probablement raison que sa performance est inférieure à ce qu'elle devrait être, mais ne présumez pas . N'oubliez pas que de nombreux programmeurs n'ont tout simplement pas de compétences sociales.
Vous n'êtes pas parfait non plus
N'oubliez pas que parfois vous allez avoir des conflits de personnalité, surtout avec les introvertis . Si cela s'avère être un conflit de personnalité, considérez jusqu'où vous êtes prêt à aller pour augmenter les performances (voir 1)
Tout cela a dit
J'ai écrit un article de blog sur la gestion des programmeurs. Je pense que vous devriez le lire.
http://deltreey.blogspot.com/2012/07/managing-programmers.html
Je ne saurais trop insister sur la dernière partie de ce post.
Si vos développeurs sont bons du tout, ils veulent coder.
Votre programmeur, même s'il se relâche, ne veut pas se relâcher. Vous devez trouver la racine de ce problème, et cela peut s'avérer être quelque chose qui ne peut tout simplement pas être résolu et il doit être abandonné, mais quoi qu'il en soit, vous ne pouvez pas prendre une décision éclairée sans le déterminer.
Quand vous sentez que quelqu'un est "quelque peu difficile à gérer" comme vous le décrivez, pour mieux comprendre comment on fonctionne et s'il y a des problèmes (objectifs ou subjectifs) affectant la productivité des membres de l'équipe de développement, envisagez d'établir une pratique de 1: 1 régulier avec les membres de votre équipe, comme présenté dans un excellent article The Update, The Vent et The Disaster :
... Je ne dis pas que chaque 1: 1 est une affaire tortueuse pour découvrir des catastrophes émergentes profondément cachées, mais vous voulez créer un lieu hebdomadaire où l'insatisfaction pourrait apparaître tranquillement. Un 1: 1 est votre chance d'effectuer une maintenance préventive hebdomadaire tout en comprenant la santé de votre équipe.
... Le son qui entoure le régime réussi de 1: 1s est le silence. Toute l'écoute, le questionnement et la discussion qui se produisent pendant un 1: 1 sont de l'entretien préventif de gestion. Vous verrez quand l'intérêt pour un projet commencera à décliner et passerez à l'action avant qu'il ne devienne une insatisfaction professionnelle. Vous entendrez parler de tension entre deux employés et animerez une discussion avant qu'elle ne se transforme en hurlement lors d'une réunion. Votre récompense pour une culture de 1: 1 en bonne santé est un manque de drame distinct .
Un point très fort de l'article mentionné est qu'il est autonome, dans le sens où en plus d'expliquer les avantages, il fournit également un ensemble de recommandations pratiques permettant essentiellement de commencer à pratiquer des 1: 1 réguliers sans creuser dans d'autres sources (bien que la recherche d'informations supplémentaires ne fasse pas de mal, vous savez).
De toute évidence, il y a un problème de communication majeur ici. Il fait peut-être un travail fantastique, mais si vous avez le sentiment que vous ne savez pas ce qu'il fait, alors en soi, c'est un problème. Et si vous ne savez pas ce qu'il fait, ses collègues ne le savent probablement pas non plus. Cela peut provoquer des problèmes lorsqu'il vérifie son code vieux de deux semaines. Surtout s'il y avait quelqu'un qui travaillait dans un domaine similaire.
Vous pouvez toujours suggérer qu'il vérifie/fournit des mises à jour plus régulièrement pour minimiser ces types de conflits. Cela pourrait vous permettre de formuler votre demande en termes d'aide à l'équipe plutôt que de "je ne sais pas ce que vous faites".
Je sais que les standups suscitent beaucoup de haine, mais ils ne doivent pas nécessairement avoir lieu dans la même pièce. Un appel rapide ou une mise à jour Skype de groupe une fois par jour est très rapide et garde tout le monde sur la même page.
Je travaille actuellement en Inde avec une équipe en Irlande et je ne peux pas imaginer ne pas être en communication avec chacun d'eux quotidiennement et je sais à peu près où ils en sont ou je peux le découvrir très rapidement.
Inutile
Les mises à jour de statut quotidiennes sont inutiles. Faire en sorte que les gens déclarent "aujourd'hui, j'ai terminé à 2,5%", "aujourd'hui, j'ai terminé à 3,74%" est ridicule.
Il n'apporte aucune valeur aux parties prenantes et agace les personnes qui effectuent le travail.
Laissez-les à leur travail, sans être dérangés.
Sans fondement
Pour quelles raisons pensez-vous que le développeur A est "sous-performant"? Si son travail est effectué à temps, cela devrait suffire.
Vous dites que vous détestez la microgestion, mais ce que vous avez décrit est exactement cela.
Notre entreprise demande aux développeurs d'indiquer la progression du travail dans le suivi des bogues que nous utilisons, non pas tant pour surveiller les programmeurs que pour tenir les parties prenantes informées de la progression. ... Les développeurs devraient mettre à jour les tâches au fur et à mesure de leur progression au quotidien.
C'est un non-sens inutile (voir ci-dessus). Votre équipe ne retourne pas les hamburgers, elle élabore des solutions techniques. Les progrès ne sont pas linéaires, ni faciles à mesurer ni même à estimer. Même si c'était le cas, ces mesures ou estimations quotidiennes n'ont aucune valeur.
Dangereux
Réexaminez la base de votre "sentiment" que le développeur A est "sous-performant". Vous pensez qu'il/elle pourrait faire mieux, mais sur la base de quelles preuves?
Malheureux! = Sous-performant
Continuez comme décrit, et à un moment donné, le développeur A décidera probablement qu'il est sous-estimé, a donné suffisamment à l'entreprise et trouvera une autre entreprise. Il est beaucoup moins important de restreindre les 0,01% des derniers efforts des employés que de les conserver à long terme.
Les développeurs peuvent détester l'effort de documenter ce qu'ils font et de mettre à jour les statuts - mais cela fait partie du fait d'être un développeur professionnel. Je vous suggère d'essayer de lui faire remarquer que ses mises à jour tardives de votre journal des problèmes provoquent une perception négative inutile de son travail. S'il ne voit pas que son incapacité à communiquer est un problème de performance - eh bien, vous êtes son chef d'équipe; dites-lui que c'est.
Concernant l'estimation - c'est un problème classique. Je recommande la lecture de "Estimation logicielle - Démystifier l'art noir" par Steve McConnell. Dans ce cas, vous donnez l'impression que la plupart de vos développeurs sous-estiment. C'est curieusement normal et rarement abordé. Je dirais que vous avez un problème avec le processus d'estimation lui-même, plutôt qu'avec celui-ci.
Essayez de "fermer la boucle" de l'estimation-mesure-revue et d'améliorer. Ensuite, si vos développeurs arrivent à l'heure plus régulièrement et que cette personne ne l'est pas, vous pouvez réfléchir à ce qu'il faut faire à son sujet.
Enfin, rendez-vous debout. Même si c'est par message instantané. Tout ce que vous voulez, c'est que tout le monde sache "ce que j'ai fait, ce que je fais aujourd'hui, tout problème". Et s'il y a des problèmes, mettez-les hors ligne pour en discuter plus tard. C'est ce que j'ai fait auparavant, et cela a été un succès pour cette équipe.
Première chose, pourquoi vos sprints sont-ils si longs? Les sprints ne doivent jamais dépasser deux semaines. Je pense que la majorité de votre problème est là. Je vous recommande de raccourcir le temps de sprint à titre d'essai, puis d'analyser à nouveau votre question.
Qu'en est-il de l'enregistrement du code? Vérifie-t-il tout le temps son code? Personnellement, je pense que les programmeurs ne sont pas vraiment des gestionnaires et plus vous essayez de gérer, plus ils seront frustrés. En fait, je déteste faire ces tâches de mise à jour et c'est probablement pour cela que les PM et les leads sont là. Mais en même temps, je donne un statut lors des réunions de mêlée ou chaque fois que nous nous rencontrons. Maintenant, lorsque vous attribuez une tâche, s'engagent-ils sur une chronologie ou est-ce vous qui leur attribuez la chronologie?
Par conséquent, la seule façon de savoir si quelqu'un est sous-performant est de mapper la chronologie validée au% du travail effectué. Maintenant, bien sûr, si quelqu'un dit qu'il lui faudra deux jours pour écrire une méthode qui additionne deux nombres, vous savez qu'il y a un problème, donc le calendrier devrait être quelque chose de réaliste et convenu par les deux parties.
Prenez-le de cette façon: si vous pouvez écrire un morceau de code en une heure, donnez-lui une heure + du tampon. S'il vous livre cela dans ce laps de temps, je pense que vous vous débrouillez bien. Si ce n'est pas le cas, interrogez-le et ensuite, c'est à vous de décider s'il fournit ou non une explication raisonnable.
Une chose que vous pouvez faire est d'intégrer quelque chose comme XPlanner avec l'outil de versioning.
Je ne pense pas que la profession de programmeur soit intrinsèquement différente des autres professions lorsqu'il s'agit d'identifier quelqu'un qui se relâche. Vous devrez peut-être aller avec votre instinct.
Personnellement, je pense qu'il est étrange que A refuse de fournir des mises à jour pendant des semaines à la fois. Je suis un programmeur travaillant à domicile, et il y a un contrat implicite entre moi et mon employeur que je dois fournir des mises à jour quotidiennes sur mes progrès. Ce ne sont pas des mises à jour "officielles", c'est juste un court e-mail ou une messagerie instantanée lui faisant savoir ce qui se passe avec le logiciel que je suis payé pour créer. La mise à jour prend moins d'une minute ou deux à écrire, et offre la fermeture à nous deux. Pour les corrections de bogues, je marque le ticket comme résolu dans notre outil de suivi des bogues d'ici la fin de la journée. Ce ne sont pas des procédures difficiles pour moi, bien que j'apprécie un environnement de travail détendu avec très peu de paperasse.
Même des mises à jour occasionnelles seraient appréciées de sa part, j'en suis sûr. Vous semblez très, très indulgent dans votre message. Si vous soupçonnez qu'il se relâche depuis longtemps, vous n'avez pas besoin d'une autre excuse pour lui en parler.
Les standups quotidiens, même si sur Skype ou dans une salle de discussion, sont le moyen de contourner cela, mais pas si vous le traitez comme une mise à jour pour les parties prenantes. Lorsqu'une fois par jour, toute l'équipe vérifie simplement sur quoi elle a travaillé, quels défis elle rencontre et ce qu'elle prévoit de faire ensuite, vous obtenez plusieurs victoires:
Que vous perdiez du temps pour de bonnes ou de mauvaises raisons, que quelque chose prenne trop de temps sera plus transparent, encourageant vos développeurs à demander de l'aide quand ils en ont besoin et à ne pas aller trop loin dans des recherches qui n'avaient probablement pas besoin de se produire. ou résoudre un problème pour le relever du défi lorsque la contribution du reste de l'équipe les aiderait à éliminer beaucoup plus rapidement.
En tant que gestionnaire, vous pouvez voir où les gens rencontrent les obstacles les plus fréquents, ce qui vous aide à estimer mieux et peut-être à résoudre les problèmes fondamentaux qui font perdre du temps/de l'argent.
OMI, cela aide vraiment l'équipe à mieux sous-estimer les estimations lorsqu'elle peut voir combien de temps il faut généralement à tout le monde pour faire parfois des choses relativement simples.
Vous vous souviendrez souvent des choses qui doivent être communiquées en termes de redéfinition des priorités lorsque les membres de votre équipe vous disent ce qu'ils prévoient de faire ensuite.
Oubliez donc "% de terminé". Il suffit de faire le processus pour que tout le monde soit honnête avec lui-même autant qu'avec tout le monde, en faisant de meilleures estimations/plus fiables à mesure qu'ils acquièrent plus d'expérience et en donnant aux gens un peu plus de motivation pour avoir des progrès à signaler sans que cela devienne un esprit. -numériser l'exercice de mettre un numéro sur quelque chose que vous ne pouvez vraiment pas.
Il semble que la haute direction comprenne que les délais ne sont pas toujours atteints. Faire des standups quotidiens vous donnera plus de munitions à cet égard, car vous aurez des idées beaucoup plus précises sur les raisons pour lesquelles ils ne sont pas touchés.
Et ne les faites pas en premier. Toujours une erreur OMI. Les gens ont besoin de temps pour repousser leurs dents dans le problème avant de pouvoir rendre compte de manière plus fiable de tous les problèmes, OMI.
Des standups rapides qui sont plus sur la communication que sur la responsabilité, et sur la simple définition d'objectifs, c'est ce qui fait que l'agilité fonctionne à mon avis. Le reste, je pourrais le prendre ou le quitter, en particulier Scrum, que je considère comme de l'huile de serpent pour les dirigeants/parties prenantes.
Sous-performant?
L'intensité monte et descend au cours de la carrière d'une personne. S'il vaut plus que ce qu'il coûte, alors parlez-lui et essayez de lui faciliter la tâche. Ou bien commencez à chercher un remplaçant.
La communication
Ne comptez pas sur les réunions hebdomadaires. La plupart des gens ne vont pas faire un braindump complet. Planifiez plus de 1: 1. Demandez-leur comment vont les choses, ce que vous pouvez faire de mieux et ce que vous pensez qu’ils peuvent faire de mieux. Parfois, il n'y aura rien à dire, mais ça va. En ayant plus de 1: 1, vous augmentez la probabilité qu'ils se souviennent de mentionner quelque chose.
Avoir un moyen de communication plus persistant
Vous pouvez obtenir plus d'informations des gens si vous ne vous sentez pas comme une corvée supplémentaire. S'ils sont tous distants, demandez-leur d'utiliser un programme de chat avec des capacités de journalisation comme Hipchat ou IRC. Le fait d'avoir des moyens de communication plus persistants encourage les gens à parler davantage. Montrez l'exemple et parlez souvent pour encourager les autres à faire de même. Au moins une fois par jour, demandez aux gens de dire où ils en sont avec leurs projets. Parfois, juste en regardant le chat, vous pouvez avoir une idée de la façon dont les choses progressent.
Contrôle de source
Demandez à chacun de vérifier quotidiennement son code. Si vous utilisez git, demandez-leur de pousser vers leur propre succursale sur le référentiel de l'entreprise. En regardant les commits, vous pouvez dire comment ils vont.
Séparez les moyens des extrémités
Les parties prenantes veulent être mises à jour? Traitez vous-même les parties prenantes. Une partie de votre travail en tant que manager consiste à être le parapluie de la merde, afin que vos codeurs puissent se concentrer sur leur travail. Parcourez les journaux de discussion et les validations, puis rédigez un résumé sur la façon dont les choses se déroulent.