Comment savoir si vos programmeurs sont sous-performants? [fermé]

60

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
Un chef d'équipe
la source
10
Pourquoi ne pas suggérer une programmation en binôme pour des tâches spécifiques et expliquer que c'est une méthode pour partager des connaissances et faire quelque chose de différent? Cela pourrait donner une idée de la façon dont il travaille et vous donner des connaissances de première main?
dreza
44
Avez-vous pensé que quelque chose d'autre pourrait bien se passer avec cette personne? Quand une personne fait souvent appel à des malades et doit assister à de nombreux événements personnels, je suppose que quelque chose dans sa vie privée le distrait au travail. Le harceler à propos de sa performance ne va vous aider. Parlez à ce gars, découvrez ce qui se passe dans sa vie privée, aidez-le si vous le pouvez, donnez-lui une marge de manœuvre s'il vous en a assez de valeur - il vous en remerciera et reviendra probablement avec intérêt lorsque sa vie personnelle le sera triés.
Marjan Venema
4
@MarjanVenema, je lui ai parlé, il a senti qu'il donnait déjà le meilleur de lui-même, à savoir, mon sentiment était faux. En outre, tout le monde ne veut pas partager sa vie privée avec vous. Vous risquez d'être qualifié de personne occupée en posant la question à la vie privée d'autrui
Un responsable d'équipe
3
Que pensent les autres développeurs de l'équipe de cette personne?
MarkJ
5
Je rouvre cette question. Pour moi, cela n’a aucun sens pour Workplace, pour des raisons générales et interdisciplinaires. La mesure spécifique de la performance des développeurs de logiciels est différente de celle de certaines autres professions. Je ne vois donc pas en quoi elle est appropriée pour la migration. Cependant, @ATeamLead, vous devez mettre à jour cette question avec davantage d'informations mentionnées dans les commentaires, telles que votre emplacement géographique.
Thomas Owens

Réponses:

49

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.

pdr
la source
3
we need to work together to improve my perception- Exactement ce que je pensais en lisant la question, en particulier la section "Résultats".
Robert Harvey
2
Mes sympathies sont avec le développeur. S'il livre ce qui a été demandé à temps, les "sentiments" du responsable de projet ne sont pas seulement sans fondement et non pertinents, ils sont insultants.
Steven A. Lowe
4
@ StevenA.Lowe: Est-ce qu'il me manque quelque chose? La question dit que les développeurs doivent définir leurs propres attentes et qu'il les manque toujours régulièrement. Je ne veux pas dire que je n’ai pas été coupable d’avoir surestimé mes propres capacités (et le PO fait la même concession), mais j’ai du mal à comprendre où vous lisez qu’il «livre ce qui était attendu, à temps».
pdr
@pdr: lol j'ai peut-être mal interprété, même si cette question semble être modifiée tous les jours. le développeur en question manque ses estimations, mais apparemment pas plus que les autres développeurs de l'équipe. soupçonne un manque de formation et / ou de leadership;)
Steven A. Lowe
2
+1 - le problème ici n'est pas qu'il est moins performant. Comme l'OP l'a dit, il ne sait pas qu'il l'est ou non, et c'est le problème que lui-même et le développeur doivent résoudre.
Zibbobz
12

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.

délire
la source
10

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

moucheron
la source
Je ne vois pas en quoi cela est lié à ma question.
Un chef d'équipe
@ATeamLead J'ai mis à jour la réponse pour clarifier la connexion. Fondamentalement, lorsque vous avez des 1: 1 réguliers, il y a beaucoup moins de mystère et de difficultés que vous décrivez. Au moins, c'était ma propre expérience
Gnat
1
Cela est lié à la question +1 car, si vous suivez cette pratique, des problèmes comme cette question risquent moins de se produire en premier lieu et sont plus faciles à résoudre en second lieu.
MarkJ
7

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.

Eoin
la source
Alors, quand as-tu fait le stand-up quotidien?
Un chef d'équipe
1
Nous le faisons à 9h30 GMT, ce qui fonctionne actuellement à 15h00, heure de l'Inde. Nous avons moi-même et une équipe responsable d'une téléconférence qui ne dure jamais plus de 15 minutes et se termine généralement par 10 minutes. Certains développeurs basés en Irlande travaillent à domicile et peuvent également appeler.
Eoin
7

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.

Steven A. Lowe
la source
Alors, comment géreriez-vous vos développeurs? Donnez-leur des tâches à accomplir pendant un certain temps, laissez-les faire ce qu'ils veulent, ne vous inquiétez pas de leurs progrès et, à la fin du mois, acceptez avec démission que seule une partie des tâches désignées soit accomplie?
Un chef d'équipe
Exiger% de choses complètes est idiot, mais les problèmes quotidiens, IMO, sont un avantage considérable quand on les tient brefs, de manière informelle, et davantage sur la communication des besoins / défis et des priorités au moment où toute l'attention de l'équipe est mobilisée.
Erik Reppen
1
Je ne gère pas mes développeurs, je gère mes projets. Si un développeur s'engage à achever la tâche A dans X jours, je l'enregistre après X / 2 jours pour voir comment il se débrouille comme une formalité, mais mes développeurs savent me dire immédiatement s'ils rencontrent un problème qui les ferait glisser. date limite. Après X jours, ils livrent. Si vous avez des personnes qui surpromisent et sous-livrent de manière chronique, leur demander de composer chaque jour un pourcentage de progrès imaginaire ne fera rien pour changer le problème fondamental (estimation, outils, formation, etc.). Processus et nombres! = Gestion.
Steven A. Lowe
1
@ErikReppen: Je suis d'accord avec le type d'informations échangées, mais je crois fermement que ces informations doivent être transmises au moment où elles sont découvertes, et uniquement aux parties intéressées, plutôt que de distraire quotidiennement l'équipe entière sans raison valable. La communication en temps opportun est la clé, pas les rituels;)
Steven A. Lowe
1
J'ai travaillé dans trop d'environnements où ce n'est tout simplement pas une chose sur laquelle on puisse compter, même si toutes les parties étaient aussi responsables que possible. Que ce soit intéressé ou non, chaque membre d'une équipe doit être conscient des obstacles que ses coéquipiers rencontrent. Il ne s'agit pas de gérer les employés, mais bien de travailler en équipe. Dans les cas où ce ne serait pas le cas, je conviendrais que ce n'est qu'une distraction inutile.
Erik Reppen
5

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.

Andy Burns
la source
4

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.

Bytekoder
la source
Qu'en est-il de l'enregistrement de code? Est-ce qu'il enregistre son code tout le temps? Non, il ne le fait pas - il ne vérifie que lorsqu'il a terminé une fonctionnalité, ce qui pourrait représenter un écart d'une semaine en termes d'enregistrement. Lorsque vous attribuez une tâche, s’engagent-ils dans une chronologie ou est-ce vous qui leur attribuez la chronologie? Ils s'y sont engagés.
Un chef d'équipe
1
C'est encore un problème! Et si quelque chose arrive à sa machine? Je pense qu'il devrait vérifier son code tous les jours. Je comprends qu’une construction nocturne peut être interrompue si son code comporte des erreurs, mais qu’il n’est pas difficile de corriger les erreurs de compilation à moins qu’il ne code sur le bloc-notes lol.
Bytekoder
En outre, de nombreuses tâches de programmation non triviales ne sont pas aussi faciles à estimer. Et bien sûr, chaque programmeur - par définition - effectue ce type de tâches à la place des tâches de programmation qu’il avait auparavant (Pourquoi voudriez-vous refaire quelque chose que vous pourrez facilement réutiliser?). Cela rend donc l'estimation très difficile et je ne leur reprocherai rien même si leur estimation manque à grands pas
Un chef d'équipe
2
@Bytekoder, il existe des milliers d'erreurs d'exécution / logique qui vont casser une application. Votre code compilé ne signifie pas qu'il est stable.
Un chef d'équipe
2
-1. La longueur du sprint est à peine la question. Et en enregistrant le code souvent, dans la seule branche disponible ne servira qu'à casser la construction.
Amadeus Hein
4

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.

UndergroundHero
la source
0

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.

Erik Reppen
la source
0

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.

Rog182
la source
-7

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

Ahmed Essawy
la source