Je suis un chef d'équipe avec plus de 5 développeurs. J'ai un développeur (appelons-le A ) qui est un bon programmeur, qui écrit un bon code propre, facile à comprendre. Cependant, il est un peu difficile à gérer, et parfois je me demande s'il est vraiment peu performant ou non.

1. Notre société demande aux développeurs d’indiquer l’avancement des travaux dans le système de suivi des bogues que nous utilisons, non pas pour surveiller les programmeurs, mais pour tenir les intervenants au courant des progrès. Le fait est que A met à jour uniquement la progression d’une tâche à la fin (peut-être 3 semaines après le début du travail), ce qui laisse tout le monde se demander ce qui se passe au milieu de la semaine du développement. Il ne changerait pas ses habitudes malgré les sondages répétés. (Ça va, les développeurs détestent la paperasse, moi aussi)
2. Depuis 2 ou 3 mois, il est en congé assez souvent à cause de divers événements - soit il est malade, soit il doit assister à de nombreux événements personnels, etc.
3. Nous définissons des sprints ou des feuilles de route pour chaque mois. Et au début du sprint, nous discuterons de la quantité de travail que chaque développeur doit effectuer dans un sprint et les développeurs ont la possibilité de définir la durée nécessaire à chaque tâche . Il ne sera généralement pas en mesure de les compléter. (Ce n'est pas grave, les développeurs ne respectent pas régulièrement les délais non dus à leur faute).
4. Je suis basé à Singapour. Je ne sais pas si ça 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 penserai pas que A est sous-performant, mais ils se produisent tous ensemble. J'ai donc le sentiment que A est sous-performant et peut-être - Dieu nous en préserve - nous relâchons.

Ceci 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 qu'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 s’est relâché. Tout ce que vous pouvez faire, est de faire confiance eux-- oui, faire confiance et donner leur autonomie est la meilleure façon pour les programmeurs au travail, je sais que, donc ne commencez pas à une conférence sur la raison pour laquelle vous avez besoin de faire confiance à vos programmeurs, je vous remercie tous les beaucoup - mais s'ils abusent de votre confiance, pouvez-vous savoir?

Résultat:

J'ai une conversation franche avec lui concernant ma perception de sa performance. Il était indigné quand j'ai suggéré que j'avais le sentiment qu'il ne performait 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 juste ou non. Il n'aurait rien de tout cela et a mis fin à la discussion immédiatement.

Avant de partir, il a déclaré qu'il "tenterait de donner davantage à la société" sur un ton très froid. Sa réaction m'a surpris. Je suis sûr que je l'ai offensé à certains égards. Pas vraiment sûr que ce soit la bonne chose à faire pour que je sois si franc avec lui, cependant.

Ma question est la suivante: comment savoir si vos programmeurs sont sous-performants? Il y a sûrement des chefs d'expérience qui connaissent mieux que moi à ce sujet? 

Notes supplémentaires:

1. Je déteste la microgestion. Donc, tout ce que nous avons pour notre processus logiciel est Sprint (où les tâches sont classées par ordre de priorité et attribuées, et à la fin du mois, un examen de la quantité de travail effectué). Les développeurs auraient besoin de mettre à jour les tâches au fur et à mesure de leur quotidien.
2. Il n'y a pas de réunion informelle, ou quoi que ce soit du genre. Principalement parce que nous avons la liberté de travailler à domicile et que tout le monde chérit cette liberté.
3. Bien que ce soit moi qui fixe la date limite, mais les développeurs fournissent l'estimation pour chaque tâche et je déciderai - en fonction de l'estimation - des tâches correspondant à 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 et ensuite pousser les 99 tâches restantes au prochain sprint et tout ira bien tant que cela sera justifié - sous la forme de mises à jour quotidiennes sur l'avancement des travaux

Cela devrait être un problème étonnamment facile à résoudre.

Avoir une deuxième réunion avec lui. Dites-lui que vous acceptez le fait que c'est probablement votre perception de la réalité qui est en cause. Puis qualifiez cela par "cependant, si tel est le cas, nous devons travailler ensemble pour améliorer ma perception." Enfin, défiez-le 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'aimais pas la possibilité que quiconque puisse penser que je cherchais un crédit supplémentaire pour simplement faire mon travail. Et c'était assez correct, mais il doit y avoir une boucle de rétroaction régulière entre tout membre du personnel et son supérieur hiérarchique.

S'il n'y en a pas, vous avez ces problèmes.

Régulier, planifié, 1: 1 est une excellente idée. Et, comme les gens l’ont souligné, il n’est pas nécessaire que les postes de travail soient orthogonaux au travail à domicile. Mais ils 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 vous retient (le cas échéant)?

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 un jour régulier que vous venez tous au bureau. Organisez une réunion régulière au cours de laquelle les gens peuvent exprimer des idées sur l'amélioration des processus ou autres.

Ne pas en faire un événement de rapport de ligne. Faites-en une occasion de simplement parler. Vous serez surpris de ce que vous apprenez. Si possible, transformez cela en événement social, prenez quelques verres sur votre temps de travail en tant qu'exercice de liaison.

Il y a beaucoup de bons conseils ici, et je ne veux rien en retirer, alors je publie cela séparément.

Premièrement, 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 savoir ce qui cause tant de frictions entre vous et ce développeur. Peut-être êtes-vous trop autoritaire (ma responsable de produit s'est récemment décrite comme ayant "un pouvoir infini" sur un projet et c'était choquant pour moi, même si elle a ri en le disant). Peut-être a-t-il de graves problèmes familiaux (expliquerait tout le temps passé au chômage). Il y a un problème fondamental ici, et jusqu'à ce que vous le trouviez, cela ne sera pas résolu.

Bonne prise!

Si ses performances pourraient être meilleures, c'est bien que vous ayez déterminé cela. Rappelez-vous cependant que si sa mauvaise performance reste une bonne performance en comparaison, vous devez agir avec prudence pour éviter de perdre un bon développeur. Il est difficile de trouver de bons développeurs et de bons développeurs exigent un ensemble très spécifique de choses. Peut-être jetez-vous un coup d’œil au test de Joël pour savoir si ses besoins sont satisfaits.

Trouver la source du problème

S'il est mécontent de quelque chose lié au travail qu'il fait, vous ne pouvez le résoudre qu'en déterminant la source du problème. Laissez-moi être clair, vous avez dit que votre programmeur a écrit un 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 de dire que sa performance est inférieure à ce qu'elle devrait être, mais ne supposez pas . Rappelez-vous que beaucoup de programmeurs n'ont tout simplement pas de compétences sociales.

Vous n'êtes pas parfait non plus

Rappelez-vous que parfois vous allez avoir des conflits de personnalité, en particulier avec les introvertis . S'il s'agit d'un conflit de personnalité, réfléchissez à la mesure dans laquelle vous êtes prêt à augmenter vos performances (voir 1).

Tout cela dit

J'ai écrit un article 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 le faire. Vous devez trouver la racine de ce problème, et il se peut que ce soit quelque chose qui ne puisse tout simplement pas être réglé et que vous deviez le laisser partir, mais quoi qu'il en soit, vous ne pouvez pas prendre une décision éclairée sans le déterminer.

Lorsque vous sentez que quelqu'un est "un peu difficile à gérer" comme vous le décrivez, pour mieux comprendre ses performances et savoir s'il existe des problèmes (objectifs ou subjectifs) affectant la productivité des membres de l'équipe de développement, envisagez de mettre en place une pratique régulière du 1: 1 avec votre membres de l’équipe, présentés dans un excellent article intitulé The Update, The Vent et The Disaster :

... Je ne dis pas que chaque 1: 1 est une affaire tortueuse de découvrir des catastrophes émergentes profondément cachées, mais vous voulez créer un lieu hebdomadaire où l'insatisfaction pourrait apparaître discrètement. Un 1: 1 est votre chance d'effectuer un entretien préventif hebdomadaire tout en comprenant la santé de votre équipe.

... Le son qui entoure le régime réussi de 1: 1 est le silence. Toutes les écoutes, les questions et les discussions qui se déroulent pendant un 1: 1 constituent une maintenance préventive par la direction. Vous verrez quand l'intérêt pour un projet commence à décliner et agissez avant qu'il ne devienne une insatisfaction au travail. Vous entendrez parler de tensions entre deux employés et modérerez une discussion avant que cela ne devienne un match hurlant lors d'une réunion. Votre récompense pour une culture du 1: 1 en bonne santé est un manque flagrant de drame .

_{Un point très fort de l’article mentionné est qu’il est autonome , en ce sens qu’en plus d’expliquer les avantages, il fournit également un ensemble de recommandations pratiques permettant essentiellement de commencer à pratiquer un 1: 1 régulier sans chercher dans d’autres sources (bien informations supplémentaires ne fera 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 l’impression que vous ne savez pas ce qu’il fait, cela est un problème en soi. Et si vous ne savez pas ce qu'il fait, ses collègues ne le savent probablement pas non plus. Cela peut causer des problèmes lorsqu'il vérifie son code vieux de deux semaines. Surtout s'il y avait quelqu'un qui travaillait dans une zone similaire.

Vous pouvez toujours lui suggérer de vérifier / de fournir des mises à jour plus régulièrement pour minimiser ce type de conflit. Cela pourrait vous permettre d'exprimer votre demande en termes d'aide à l'équipe plutôt que "je ne sais pas ce que vous faites".

Je sais que les combats suscitent beaucoup de haine, mais ils ne doivent pas nécessairement se tenir dans la même pièce. Un appel rapide ou une mise à jour groupée de Skype 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 contact quotidien avec chacun d'eux et je sais à peu près à quoi chacun d'entre eux est ou je peux le savoir très rapidement.

Inutile

Les mises à jour quotidiennes sont inutiles. Demander aux gens de déclarer "aujourd'hui, je suis achevé à 2,5%", "aujourd'hui, je suis achevé à 3,74%" est ridicule.

Cela 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

Sur quelles bases supposez-vous que le développeur A «sous-performe»? Si son travail est fait à temps, cela devrait suffire.

Vous dites que vous détestez la microgestion, mais ce que vous avez décrit est exactement cela.

Notre société demande aux développeurs d’indiquer l’avancement des travaux dans le système de suivi des bogues que nous utilisons, non pas pour surveiller les programmeurs, mais pour tenir les parties prenantes au courant des progrès. ... Les développeurs auraient besoin de mettre à jour les tâches au fur et à mesure de leur quotidien.

C'est absurde (voir ci-dessus). Votre équipe ne lance pas de hamburgers, elle élabore des solutions techniques. Les progrès ne sont ni 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 "impression" que le développeur A "sous-performe". Vous pensez qu'il / elle pourrait faire mieux, mais sur la base de quelles preuves?

Malheureux! = Moins performant

Continuez comme décrit et, à un moment donné, le développeur A décidera probablement qu’il est sous-estimé, qu’il en a donné suffisamment à la société et qu’il trouvera une autre société. Réduire les derniers 0,01% des efforts des employés est beaucoup moins important que de les conserver à long terme.

Les développeurs peuvent détester l'effort de documenter ce qu'ils font et de mettre à jour leurs statuts, mais cela fait partie du métier de développeur professionnel. Je suggérerais que vous puissiez essayer de lui faire remarquer que les dernières mises à jour de votre journal des problèmes entraînent 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.

En ce qui concerne l'estimation, c'est un problème classique. Je recommande de lire "Estimation du logiciel - Démystifier l'art noir" de Steve McConnell. Dans ce cas, vous donnez l'impression que la plupart de vos développeurs sous-estiment. Curieusement, ceci est normal et rarement abordé. Je suggérerais que vous avez un problème avec le processus d'estimation lui-même, plutôt que celui-ci.

Essayez de «boucler la boucle» d'estimation-mesure-revue et d'améliorer. Ensuite, si vos développeurs arrivent à l'heure plus régulièrement et que cette personne ne le fait pas, vous pouvez envisager ce qu'il faut faire à son sujet.

Enfin, ayez la réunion 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, tous les problèmes". Et s'il y a des problèmes, mettez-les hors ligne pour discussion plus tard. C’est ce que j’ai fait auparavant et c’est une réussite pour cette équipe.

Première chose, pourquoi vos sprints sont-ils aussi longs? Les sprints ne devraient jamais dépasser deux semaines. Je pense que la majorité de votre problème réside là. Je vous recommanderais de réduire la durée du sprint à titre d'essai, puis d'analyser à nouveau votre question.

Qu'en est-il de l'enregistrement de code? Est-ce qu'il enregistre son code tout le temps? 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 chefs de projet et les responsables sont là. Mais en même temps, je fournis un statut lors des réunions Scrum ou à chaque fois que nous nous rencontrons. Maintenant, lorsque vous attribuez une tâche, sont-ils engagés dans une chronologie ou est-ce vous qui leur attribuez la chronologie?

Par conséquent, la seule façon pour moi de savoir si une personne est sous-performante est de mapper la chronologie engagée sur le% de 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. Le calendrier doit donc être réaliste et accepté par les deux parties.

Prenez-le ainsi: si vous pouvez écrire un morceau de code en une heure, donnez-lui une heure + un peu de tampon. S'il vous le livre dans ce laps de temps, je pense que vous vous débrouillez bien. Si ce n'est pas le cas, interrogez-le et, plus tard, il vous appartient de décider s'il fournit une explication raisonnable ou non.

Une chose que vous pouvez faire est d'intégrer quelque chose comme XPlanner avec l'outil de gestion de versions.

Je ne pense pas que la profession de programmeur soit fondamentalement différente des autres professions en ce qui concerne l'identification de quelqu'un qui est relâché. Vous devrez peut-être y aller avec vos tripes.

Personnellement, je pense qu’il est étrange que A refuse de fournir des mises à jour pendant des semaines. Je suis un programmeur travaillant à domicile et il existe un contrat implicite entre moi et mon employeur, et je dois fournir des mises à jour quotidiennes sur mes progrès. Ce ne sont pas des mises à jour "officielles", c'est juste un bref courriel ou un message instantané lui permettant de 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 une fermeture pour 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 informelles 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 est relâché pendant une longue période, vous n'avez pas besoin d'une autre excuse pour le résoudre.

Des redressements quotidiens, même si sur Skype ou dans une salle de discussion, sont la solution, mais pas si vous les traitez comme une mise à jour pour les parties prenantes. Une fois par jour, toute l'équipe vérifie simplement sur quoi elle travaille, quels sont les défis à relever et ce qu'elle prévoit de faire par la suite, vous remportez plusieurs victoires:

• Que vous perdiez du temps pour de bonnes ou de mauvaises raisons, que quelque chose prenne trop de temps va devenir plus transparent, en encourageant vos développeurs à demander de l'aide quand ils en ont besoin et à ne pas aller trop loin dans des recherches qui n'auraient probablement pas dû être faites ou résoudre un problème pour relever le défi lorsque l’aide du reste de l’équipe les aiderait à résoudre le problème beaucoup plus rapidement.

• En tant que gestionnaire, vous pouvez voir où les gens rencontrent le plus souvent des obstacles, ce qui vous aide à mieux évaluer et éventuellement à résoudre des problèmes fondamentaux qui font perdre du temps / de l’argent.

• OMI, cela aide vraiment l’équipe à apprendre à mieux sous-estimer les estimations quand elle peut voir le temps qu’il faut habituellement à tout le monde pour accomplir des choses même parfois relativement simples.

• On vous rappellera souvent des choses à communiquer en termes de redéfinition des priorités lorsque les membres de votre équipe vous diront ce qu'ils vont faire par la suite.

Alors oubliez '% of complete'. Assurez-vous que tous les utilisateurs sont honnêtes avec eux-mêmes autant que les autres, en faisant des estimations meilleures / plus fiables à mesure qu'ils acquièrent de l'expérience, et en donnant aux gens un peu plus de motivation pour que les progrès soient rapportés sans que cela devienne un esprit. - exercice de la plomberie 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 redressements 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 fais pas la première chose. Toujours une erreur IMO. Les gens ont besoin de temps pour se remettre du problème avant de pouvoir faire rapport de manière plus fiable sur tous les problèmes, OMI.

À mon avis, la rapidité avec laquelle nous travaillons est plus agile que la communication plutôt que la responsabilité et que la définition d'objectifs est ce qui rend l'agile plus efficace. Je pouvais prendre ou laisser le reste, en particulier Scrum, que j’ai considéré comme une huile de serpent pour cadres / parties prenantes.

Sous-performant?

L'intensité fluctue au cours de la carrière d'une personne. S'il vaut plus que ce qu'il a coûté, parlez-lui et essayez de lui faciliter la tâche. Ou alors commencer à 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. Programmez plus de 1: 1. Demandez-leur comment les choses se passent, ce que vous pouvez faire de mieux et ce que vous pensez pouvoir faire de mieux. Parfois, il n'y aura rien à discuter, mais ce n'est pas grave. 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 auprès des personnes si vous ne leur donnez pas l'impression d'être une corvée supplémentaire. Si elles sont toutes distantes, demandez-leur d'utiliser un programme de discussion avec des fonctionnalités de journalisation telles que Hipchat ou IRC. Avoir un moyen de communication plus persistant encourage les gens à parler davantage. Dirigez par 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, rien qu'en regardant sur le chat, vous pouvez avoir une idée de la progression des choses.

Contrôle de la source

Demandez à chacun de vérifier son code quotidiennement. Si vous utilisez git, demandez-leur de transférer leur propre succursale sur le dépôt de la société. En regardant les commits, vous pouvez savoir comment ils se débrouillent.

Séparer les moyens des fins

Les parties prenantes veulent être mises à jour? Traitez vous-même avec les parties prenantes. Une partie de votre travail en tant que gestionnaire consiste à jouer le rôle de parapluie de merde afin que vos codeurs puissent se concentrer sur leur travail. Parcourez les journaux de discussion et les validations, puis écrivez un résumé de la situation.

Ce sont mes suggestions:

1. Innovation: L'imagination et la créativité sont utilisées pour réduire les coûts et améliorer la situation actuelle.

2. Corporation: Volonté d'aider les autres à atteindre leurs objectifs

3. Initiative: Tenter des travaux et des tâches non routinières.

4. Fréquentation: absences ou retard, en dessous des normes.

5. Vigilance: capacité à comprendre rapidement de nouvelles informations et situations

6. Exactitude et qualité: révision du code, respect des délais, taux d’émission).