Comment gérer un développeur qui a de faibles compétences en communication
Je gère une petite équipe de développeurs sur une application qui est au milieu de son cycle de vie, au sein d'une grande entreprise. Cela signifie malheureusement qu'il y a généralement une répartition 30/70 des tâches de programmation avec "d'autres travaux techniques". Ce travail comprend:
- Travailler avec des équipes DBA/Unix/Réseau/Loadbalancer sur diverses tâches
- Passer et gérer des commandes de matériel ou d'infrastructure dans différentes régions
- Exécution de tests qui n'ont pas encore été migrés vers CI
- Une analyse
- Support/Enquête
Il est juste de dire que les développeurs préfèrent tous coder, plutôt que de faire ces tâches plus banales, alors j'essaie de distribuer les tâches de programmation amusantes de manière égale au sein de l'équipe.
La plupart de l'équipe a été embauchée parce que, bien qu'ils n'aient pas les compétences de programmation Elite pour écrire leur propre compilateur/moteur de jeu/système d'échange à haute fréquence, etc., ce sont de bons communicateurs qui "peuvent faire avancer les choses", travailler avec d'autres équipes , et naviguer un peu dans la bureaucratie complexe ici. Ce sont de bons développeurs, mais ils sont également un bon personnel technique polyvalent.
Cependant, un membre de l'équipe a probablement des compétences de codage supérieures à la moyenne, mais des compétences de communication inférieures à la moyenne. Traditionnellement, le précédent directeur du développement avait tendance à lui confier les tâches de programmation et non les tâches plus banales énumérées ci-dessus. Cependant, je ne pense pas que cela soit juste pour le reste de l'équipe, qui a montré une aptitude à développer un ensemble de compétences bien équilibré qui est généralement requis dans un département informatique de grande entreprise.
Que dois-je faire dans cette situation? Si je continue à lui donner plus de travail de programmation, je sais que cela se fera plus rapidement (et inversement, je m'attendrais à ce qu'il termine l'autre travail plus lentement). Mais cela va à l'encontre de mes principes et favorise l'idée que vous pouvez vous créer une "niche confortable" simplement en étant mauvais dans les tâches que vous n'aimez pas.
Je tiens à préciser que je n'essaie pas de résoudre ce problème en raison d'une rancune, ou que j'ai une "puce sur mon épaule" comme cela a été mentionné. Je cherche des conseils pour garder une équipe équilibrée, heureuse et motivée. En observant la variété des réponses à cette question, il semble qu'il y ait beaucoup d'opinions différentes sur la façon d'y parvenir.
Il semble que vous déployiez trop d'efforts pour avoir un bon arrondi individus et pas assez d'effort pour avoir un bon arrondi équipe.
Il n'y a rien de mal à être bon dans quelque chose - en fait, c'est probablement pourquoi il a été embauché! Vous devriez être reconnaissant d'avoir quelqu'un qui est bon en programmation pour commencer.
Vous avez déclaré:
... cela va à l'encontre de mes principes et favorise l'idée que vous pouvez vous créer une "niche confortable" simplement en étant mauvais dans les tâches que vous n'aimez pas.
S'il était un programmeur médiocre, je serais d'accord. Mais tu n'as pas dit ça. Vous avez dit qu'il était un bon programmeur. Il n'est pas mauvais dans les autres tâches pour s'en sortir - il se concentre simplement sur ses efforts pour devenir un meilleur programmeur. Il n'y a rien de mal à cela.
En tant que manager, il ne vous appartient pas de vous assurer que tout le monde est "bien équilibré". Il est de votre devoir de vous assurer que s *** se fait. Et tu ne fais pas ça. En fait, vous prenez des décisions qui arrêtent les choses à faire.
Quel que soit le problème que vous rencontrez, vous devez le surmonter - vous rendez votre équipe moins productive.
Vous attrapez un peu de chaleur ici dans les autres réponses pour votre décision de "faire quelque chose" à propos de ce type, mais je comprends parfaitement ce que vous dites. Si les autres membres de l'équipe "préfèrent tous coder plutôt que de faire ces tâches plus banales", alors ils vont être ennuyés que vous soyez récompensant la mauvaise performance du pauvre communicateur en lui donnant juste les tâches que tout le monde veut.
Imaginez que vous êtes l'un des "bons communicateurs" de l'équipe dont les compétences sont comparables à celles du développeur en question. Vous gérez les appels, travaillez avec d'autres membres du personnel non informatique qui connaissent à peine une souris à partir d'un clavier, rédigez des plans pour la connexion des utilisateurs, et plus encore, tout cela parce que votre patron vous le dit. Le développeur grincheux, en attendant, parce qu'il a "de mauvaises compétences en communication", peut rester assis dans son cube toute la journée en ignorant les utilisateurs travaillant uniquement sur les trucs "amusants".
Maintenant, vous avez dit que le dev grincheux avait des compétences "supérieures à la moyenne", mais vous n'avez pas dit qu'il était le meilleur. Cela signifie que peut-être 1/3 de votre équipe, ces bons développeurs communicateurs qui sont au niveau de compétence du développeur grincheux ou au-dessus, se sentent tous énervés.
Vaut-il la peine de perdre de la productivité de votre MEILLEUR PERSONNEL PERFORMANT parce qu'ils sont ennuyés par les grincheux-dev? Vous devrez décider.
À moins que vous ne souhaitiez renvoyer le gars, je vous suggère d'adopter l'une de ces approches:
1) Mentorez-le pour qu'il soit un meilleur communicateur. Vous seul pouvez dire si cela est possible. Vous pourriez trouver que tenir sa main un peu plus pourrait aider. Certaines personnes sont simplement terrifiées par les interactions commerciales formelles et l'expriment en étant énervées lorsqu'on leur demande de le faire.
2) Encouragez la "bonne communication", soit avec de l'argent, soit avec d'autres avantages. Expliquez clairement que vous appréciez réellement les bons communicateurs et que vos développeurs ne seront pas si ennuyés, mais la récompense doit être réelle et significative. "Déjeuner avec le directeur de district" ne suffira pas. Un prix "joueur étoile/félicitations/attaché" ne sera pas non plus un simple morceau de papier. Ça doit être de l'argent supplémentaire, des congés supplémentaires, des horaires flexibles, une reconnaissance sérieuse avec les hauts responsables qui contrôlent les augmentations de salaire, etc.
Tout d'abord, blâmer les membres de votre équipe ... dénote mauvaises compétences en gestion.
Je veux dire, s'il a vraiment a de mauvaises compétences en communication, je suis vraiment désolé pour sa vie sociale, mais vraiment, au travail cela isn pas autant son problème que le vôtre. Et avouons-le, il pourrait en fait juste être ennuyé par votre environnement de travail ennuyeux, ou avoir des problèmes privés influençant ses performances, ou être complot en secret pour vous tuer tous.
La communication prend au moins deux, et après tout, celui qui a des compétences médiocres pourrait être vous. Peu importe le reste des membres de l'équipe qui s'entendent assez bien, ils pourraient tous compenser (même sans le savoir) pour certains problèmes de communication que vous avez et ignorer béatement.
Et de toute façon, n'allez pas demander à Internet des gens qui sont assis à trois bureaux de vous, allez voir le gars et demandez-lui s'il y a vraiment quelque chose qui ne va pas et si cela peut être résolu. (ou quelque chose de terne qui peut être optimisé ou amélioré)
Peut-être qu'il déteste juste sa position sur le bureau (fait-il face aux toilettes?) Et cela le met de mauvaise humeur.
Indice: écoutez la réponse, comme s'il était un être humain sensible, pas une ressource humaine.
(par exemple: essayez en lui expliquant en détail le besoin de certaines pratiques et le sens de certaines décisions, certaines personnes creusent les détails, car elles leur donnent le sentiment d'avoir un capitaine qui ne conduit pas le navire dans les falaises)
Les gens sont différents. En tant que manager, vous devez traiter les gens différemment (mais équitablement!) Pour tirer le meilleur parti de votre équipe.
Cela dit, il est probablement bon pour le développeur avec de faibles compétences générales de travailler dessus. Je voudrais savoir quelle chose non codante le développeur aime (ou aimerait faire) qui implique plus de ces compétences générales. Faites-les participer à cette tâche et, idéalement, ils amélioreront les compétences générales comme effet secondaire.
Souvent, les gens ne sont pas mauvais à quelque chose pour se retirer du travail; ils sont mauvais parce qu'ils ne l'apprécient pas ou n'ont aucune aptitude pour cela. Vous ne pouvez pas aider les seconds, alors travaillez sur les premiers.
Le partage 30/70 peut être le point de départ de tous vos problèmes. Je n'ai jamais vu de développeurs satisfaits d'une telle division.
J'ai vu des développeurs être à l'aise avec 10, 15% autre travail (et je suis content moi-même parce que c'est amusant quand la dose est juste) mais 30% l'est trop. Je préfère penser que les autres membres de l'équipe préfèrent ne pas exprimer leur opinion plutôt qu'un seul qui n'aime pas "30% d'autres travaux".
Je pense également qu'il est important d'ajuster vos "calculs de productivité" à des chiffres plus réalistes. Il ne totalisera jamais 100% en raison des pertes inévitables lors des "changements de contexte".
- 30 + 70, totalisant jusqu'à 100% de productivité lors du passage de la programmation à autre travail, ne se produira jamais dans la vie réelle; il est plus probable environ 20 + 50 ou même 20 + 40. Les commutateurs de contexte sont particulièrement douloureux pour les développeurs de logiciels - si vous êtes intéressé, consultez cet article pour une explication intéressante de la raison pour laquelle: NE RÉVEILLEZ PAS LE PROGRAMMATEUR!
Les programmeurs qui apprécient leur productivité seraient naturellement mécontents de telles pertes.
Quant à exécuter des tests partie du travail, avez-vous envisagé de le passer aux testeurs? Le fait que les programmeurs peuvent le font (je pense que tout programmeur expérimenté devrait être capable de cela) ne signifie pas qu'ils devraient. Les testeurs peuvent le faire aussi, ils le font mieux, et ils ne subiront pas de pertes de productivité lors des "changements de contexte".
Un autre point qui me fait me demander comment vous utilisez les ressources QA est votre mention de Support/Investigation. Les testeurs professionnels avec lesquels je travaillais ont tendance à avoir "le premier mot" dans des trucs comme ça.
- En tant qu'ex-testeur moi-même, je les comprends assez bien - les problèmes de production ont été pour moi (en tant que testeur) une source inestimable de données pour en savoir plus sur la couverture des tests ("ce problème a-t-il été correctement couvert par mes tests?") Et pour priorisation des défauts ("ok, il a été couvert par des tests et signalé avant la sortie, mais ai-je alors défini la priorité/gravité appropriée?").
Il est assez facile pour un bon testeur de savoir quand passer l'enquête de problème de support aux développeurs, et cela ne se produit pas très souvent. Les raisons de surcharger les développeurs avec cela m'échappent tout simplement. Comme je l'ai déjà écrit, ils sont sûrs - peut de faire cela (je m'attends généralement à ce que le développeur senior sache comment faire tout ce que fait le contrôle qualité), mais cela ne signifie pas qu'ils devraient.
J'ai 2 choses à dire à ce sujet
Avez-vous recruté un codeur ou développeur de logiciels?
Lorsque vous envisagez de développer un logiciel, toutes les choses que vous avez mentionnées font partie intégrante du développement de logiciels. Vous ne pouvez tout simplement pas les ignorer à moins que vous n'ayez recruté pour une tâche spécifique. IMO 50% du développement logiciel total est le reste du codage est la conception, l'analyse, les tests, la documentation, etc.Personne n'est né parfait.
Il est tout simplement impossible de trouver une personne qui soit bonne en tout. Vous devez les faire lutter et leur faire apprendre des choses.
En tant que manager, vous devez tirer le meilleur parti d'eux, je suis d'accord, mais à long terme, vous pourriez rencontrer des problèmes. Attribuez-leur des tâches légères afin qu'ils aient tendance à les maîtriser. Sortez-leur le sentiment que je ne suis pas bon dans ce domaine/je ne peux pas me permettre de le faire. Surtout, traitez tout le monde de la même manière pour obtenir la sortie la plus efficace de votre équipe.
Si tous les membres de votre personnel ont le même titre/description de poste et que la description de poste comprend tout ce que vous avez indiqué, ce programmeur doit avoir ces autres compétences affinées en obtenant plus de ces autres tâches non programmeur. De même, vos autres employés n'auront pas leurs compétences en programmation affûtées s'ils doivent continuellement travailler sur des tâches non liées à la programmation (utilisez-les ou perdez-les).
Mais je pense toujours que votre principale priorité devrait probablement être de respecter vos délais (ce que vous pourriez toujours être en mesure de distribuer le travail de manière égale).
EDIT: Si vous avez une petite équipe, il est probablement logique que tous les membres puissent porter plusieurs chapeaux. Si vous avez une équipe suffisamment grande, il est probablement logique d'avoir des groupes spécialisés dans différents domaines. D'après votre message, il semble que vous ne disposiez pas d'une équipe suffisamment importante pour avoir des groupes de spécialistes.
Il ne ressort pas clairement de votre message d'origine ce qui manque exactement sur les compétences en communication de ce développeur. Un manque d'intérêt pour aller à des réunions ou faire du travail de type planification/coordination (par exemple) n'indique pas nécessairement de mauvaises compétences en communication. Peut-être que le développeur pense simplement que ce type de travail est du travail de manager et réduit sa productivité en tant que développeur? Ou peut-être qu'il estime qu'il y a trop de frais généraux organisationnels et que c'est une forme de protestation contre ce qu'il considère comme du temps perdu dans l'ensemble? Après tout, le problème opposé, où les gens parlent toute la journée et ne font rien, est également assez courant au bureau.
Il est important que vous parliez avec ce développeur de manière non conflictuelle et que vous essayiez de comprendre pourquoi il évite les tâches hors programmation. Ce n'est probablement pas une seule raison, il peut avoir autant de raisons différentes qu'il existe de types de tâches différents. Assurez-vous qu'il comprend que le but de la conversation est de vous permettre d'apprendre comment améliorer efficacement la productivité de l'équipe et la satisfaction au travail pour tous les membres de l'équipe (vous n'êtes pas là pour le faire). C'est un moment pour vous d'écouter, et de ne pas discuter ou essayer de répondre à ses préoccupations avec des réactions instinctives. Vous devriez probablement aussi rencontrer les autres membres de l'équipe, peut-être qu'ils sont tout à fait d'accord pour laisser ce gars faire le gros travail de développement pendant qu'ils se concentrent sur le côté le plus bavard de la profession.
Après cette réunion, passez du temps à réfléchir aux conversations que vous avez eues et essayez de considérer le point de vue de cet employé avec un esprit ouvert. Peut-être que vos sentiments initiaux étaient corrects et qu'il lui manque des compétences importantes que vous devriez le pousser à développer. Ou peut-être qu'il a contesté valablement vos hypothèses. Vous pouvez peut-être travailler avec d'autres équipes pour formaliser certains processus et réduire le besoin de communication redondante. Peut-être que d'autres équipes ne tirent pas leur poids et vous devez avoir une conversation amicale avec leur gestion. Il existe de nombreuses possibilités que vous ne considérez peut-être pas.
Enfin et surtout, ayez une conversation de suivi avec des individus ou une réunion d'équipe si cela est approprié. Si vous avez identifié de vrais problèmes organisationnels que vous êtes en mesure d'affecter, parlez à vos employés des mesures que vous allez prendre pour améliorer leur situation de travail. Si vous croyez toujours que l'employé a tort, asseyez-vous avec lui et expliquez les changements dont vous avez besoin et pourquoi. Les développeurs ont tendance à bien répondre aux explications logiques/pratiques. "Ce n'est pas juste pour vos pairs de vous donner tout le travail amusant. Nous aimerions que vous soyez tous de purs développeurs, mais ce n'est pas la réalité de la situation, nous devons donc partager le fardeau du travail de merde."
Bien sûr, si ce gars est juste un crétin grincheux, refuse de vous dire pourquoi il est malheureux, ne répondra pas à la raison et n'est pas bien respecté par ses pairs ... eh bien ... il est temps pour le plan d'amélioration de la performance.
Bien que vous essayiez de gérer une équipe et que vous vouliez garder tout le monde motivé (avoir un sens de l'équité aide), mais sacrifiez-vous le projet en n'ayant pas votre meilleure programmation programmeur? Je veux dire, c'est le point n'est-ce pas.
N'avez-vous pas peur de sous-utiliser et/ou de risquer de perdre votre meilleur développeur? Votre travail consiste à essayer de soulager ces types de tâches de tout le monde.
Un traitement égal ne signifie pas que vous traitez tout le monde de la même façon. Si les autres veulent relâcher les tâches hors programmation afin de se voir attribuer davantage de tâches de programmation, ne courent-ils pas le risque d'être bons dans aucun des deux?
EDIT: À part vos sentiments personnels, vous n'avez pas identifié de problème. À un moment donné, le manque de communication gêne un programmeur. D'autres manifesteront du ressentiment et leur travail pourrait en souffrir. Jusqu'à présent, vous semblez être le seul à avoir un problème. À moins qu'il y ait autre chose que vous ne partagez pas?
EDIT 2 Finalement, tout le monde va demander une faveur spéciale. Cette personne fait moins de communication et plus de codage (ce qu'elle devrait selon tous les comptes). Quelqu'un d'autre veut venir un peu plus tard. Un autre devra sauter une réunion pour respecter un délai. Une personne graphique obtient un moniteur plus grand. Lorsque vous mettez trop l'accent sur le maintien du score, vous oubliez ce qui est important.
Je suis un administrateur Linux grincheux qui fait beaucoup de scripts, et il a été remarqué que j'ai de mauvaises compétences en communication. Je ressemble beaucoup à ton mec. En fait, c'est le seul domaine sur lequel je m'attarde dans les évaluations de performances. De l'autre côté, je dirige continuellement mon équipe dans l'innovation et la résolution de problèmes, et j'ai créé et ouvert la voie à la nouvelle plateforme que nous déployons et j'ai fait gagner beaucoup de temps à mon équipe et à mon entreprise une beaucoup d'argent en étant autorisé à être moi-même.
On a demandé à mon ancien patron sa famille/femme ET la haute direction de notre entreprise de quitter son poste ... simultanément. Il a travaillé sans relâche pour équilibrer les responsabilités équitablement et a assumé lui-même beaucoup de charge. Lors de toute interaction avec quelqu'un en dehors du département, s'il y avait un malentendu de communication qui lui était revenu, il était rapide, ah, pour le corriger de manière punitive. Il était médiocre dans la "gestion ascendante", donc notre équipe a été la dernière à obtenir des ressources jusqu'à ce que ce soit une urgence, puis la société a surpayé les fournisseurs avec des arguments de vente astucieux pour du matériel non testé sans consulter l'équipe qui utiliserait ces outils. Dans le but de créer une équipe "bien équilibrée", il a géré nos listes de tâches et a essayé d'équilibrer les tâches afin que les membres de l'équipe puissent améliorer leurs compétences dans des domaines où ils n'étaient pas excellents, ce qui a entraîné BEAUCOUP de code cassé ou implémentations mal architecturées. Alors que des personnes autres que l'auteur ont été spécifiquement affectées à des tâches de support pour ce code cassé afin qu'elles puissent "apprendre" - les implémentations, le code et les tests mal architecturés ont créé beaucoup de mauvaise volonté entre les membres de l'équipe et en fait augmenté occurrences du "jeu du blâme", qui est un itinéraire rapide vers un état d'équipe toxique.
Mon patron actuel est un individu calme et rassemblé qui est venu du poste d'administrateur junior et a progressé. Il prend de bonnes décisions et s'appuie fortement sur les membres de l'équipe pour établir leurs propres priorités. Il est un excellent communicateur et réagit calmement et de concert avec son superviseur à tout problème de communication, idée ou besoin exprimé par mon équipe. Il "travaille sans relâche". Il est lent à apporter des changements architecturaux majeurs, et consulte à fond toute l'équipe avant d'apporter des modifications à notre environnement et il est à l'aise de compter sur les spécialités des membres de notre équipe.
Sous le nouveau gestionnaire, notre temps d'arrêt est tombé à presque zéro (ce qui a également fait passer le pourcentage de temps que nous consacrons aux tâches de support d'environ 40% à environ 10%), la satisfaction de notre équipe est passée par le toit, et nous sommes sur la bonne voie pour passer d'une "rupture de la banque de nouveaux matériels tous les trois à cinq ans" à un plan d'acquisition continu qui devrait permettre à l'entreprise d'économiser environ un million de dollars par an sur cinq ans. Ce plan était un programme de base qui n'aurait jamais eu lieu sous le précédent manager, mais a été activement poussé à la haute direction par le nouveau manager et dépendait de trouver BEAUCOUP de synergies dans les compétences de l'équipe. Le CIO nous a dit de manière informelle que nous sommes maintenant la seule équipe de l'entreprise qui a vraiment "sa merde ensemble" et qu'il va interférer le moins possible avec notre environnement de travail et transférer autant de ressources vers les zones à problèmes que nous identifions comme possible. Cela s'est avéré vrai, et cela a fait baisser encore davantage le "coût" de notre support, bien qu'il ait perturbé la charge de travail de certaines autres équipes - mais cela a également fait baisser le "coût" du support de ces équipes.
Regardez, les développeurs peuvent améliorer leurs compétences à l'école ou à leur propre rythme. L'endroit pour eux de produire des choses est sur le temps de votre entreprise. La meilleure façon de produire des choses est de produire ce qu'ils savent le mieux. Lorsque vous travaillez dans des domaines où un développeur n'est pas à l'aise, il doit attirer un deuxième développeur spécialisé et travailler en équipe, ou le développeur spécialisé doit écrire le code et produire de la documentation et des diagrammes. Acheminez les tâches de support vers les personnes qui ont écrit le code. Oui, cela augmente ce que nous appelons votre "facteur de bus" - la probabilité que votre service frappe un ralentisseur si le spécialiste devait être heurté par un bus. (Ou mis à pied, ou changer d'emploi, ou ...) La vérité est que votre perte de productivité de cette peur est des ordres de grandeur supérieure à la perte réelle quand un "événement de bus" se produit. Ce qui se passe généralement lors d'un "événement de bus", c'est que l'héritier du travail du spécialiste le refait à son image afin qu'il puisse le soutenir le plus efficacement possible, en résolvant généralement un tas de problèmes et en réduisant encore plus le temps consacré au soutien, et la vie continue sur.
Attribuez des choses aux personnes qui peuvent le mieux les faire. Faites-leur soutenir et documenter leur travail. Stimulez leur créativité et permettez-leur de se concentrer sans distractions ni microgestion. Tout le reste est une école de gestion BS, ce qui donne malheureusement l'impression que votre entreprise nage. Cela ne signifie pas que votre équipe doit également y nager.
Du point de vue d'une entreprise, un bon gestionnaire promeut les valeurs de l'entreprise tout en exécutant des tâches en fonction de ces valeurs. Du point de vue d'un employé des TI, un bon gestionnaire laisse l'équipe faire ce qu'il faut faire le plus rapidement et le plus proprement possible et agit comme une barrière fécale contre la haute direction qui pousse les valeurs apprises dans les cours de MBA du week-end dans la gorge des sous-jacents. Vous êtes un homme d'affaires et ce n'est peut-être pas le meilleur pour votre équipe. Ceux qui ont de "bonnes" compétences en communication sont tout simplement trop polis pour le dire.
- Assurez-vous que l'employé sait à quel point les compétences en communication sont importantes pour sa description de travail. Travaillez avec lui pour vous améliorer.
- N'insistez pas pour qu'ils soient aussi bons que les autres membres de l'équipe dans de telles tâches.
- Attribuez des tâches selon les principes auxquels vous croyez. Trouvez un équilibre entre une affectation efficace des tâches aux compétences et l'équité/le plaisir.
Ce ne sont que des idées sommaires, j'espère que quelqu'un volera ces points et les pliera dans l'une des autres réponses. ;-)
La performance est tout. Donnez-lui les tâches de programmation. Parlez-en avec le reste du département. Invitez éventuellement quelqu'un à faire des tâches de com ou à charger quelqu'un sur des tâches de com uniquement. Ne pensez pas à la programmation de s'amuser. Tout est "amusant" à partir de votre POV.
Si vous ne le faites pas, vous créerez une situation extrêmement difficile à gérer et moins efficace qu'elle ne pourrait l'être.
Quelle grande question, c'est le genre de chose à laquelle tous les chefs d'équipe, les superviseurs, les gestionnaires de techniciens devraient penser. J'aime votre approche, tout le monde devrait avoir une tâche "amusante". Pousser plus loin le fait d'avoir une équipe capable de prendre en charge différentes tâches et ayant reçu une formation croisée empêche le principe de Peterbilt de causer des ravages `` un membre de l'équipe indesipensible quitte l'équipe ou prend même halètement des vacances ''.
Maintenant, comme l'ont souligné de nombreux articles, le travail n'est pas équitable et ne devrait pas l'être. Les gestionnaires sont mesurés sur la quantité de travail précieux qui est accompli.
- Les gestionnaires associent les tâches aux individus en fonction de leurs compétences.
- Les bons gestionnaires associent les tâches en fonction des compétences, de la croissance, de l'intérêt et de la productivité de l'équipe.
- Les bons gestionnaires font en sorte que leur équipe le fasse avec un peu d'aide et de conseils. C'est-à-dire sans que le manager passe toute la journée dessus.
Parlez à votre bon programmeur, demandez-lui s'il y a des choses qu'il veut apprendre. Quelles autres tâches accepterait-il ... même ce qui lui est le moins répréhensible. Peut-il aider d'autres membres de l'équipe dans leur programmation ... les encadrer. Oui, je sais que la communication est un problème, alors peut-être qu'il devrait y travailler.
Une autre façon de regrouper cela est d'avoir une liste de tâches et de laisser chaque membre du personnel choisir quelque chose. Laissez votre bon programmeur choisir en premier. Si vous l'avertissez à l'avance et lui montrez encore mieux la liste des tâches.
Si vous obtenez de la résistance, ce que vous faites presque toujours avec le changement, trouvez un argument de vente, quelque chose de valeur pour lui, pourquoi en bénéficiera-t-il. Enfin, vous pouvez simplement lui dire de le faire pour l'équipe.
Attendez-vous également à des erreurs et à une baisse de la productivité, c'est un signe que les gens apprennent. Ce projet peut souffrir, mais le prochain sera meilleur.
En terminant, c'est votre travail de vous assurer que tout est fait, mais il en va de même pour la croissance de votre personnel et si vous pouvez encore mieux l'impliquer dans le processus. Certains pourraient dire que la meilleure façon de s'assurer que les choses sont faites est une équipe qui sait ce qui doit être fait et qui possède les résultats.
Edit: Oh et continuez d'essayer, les conseils ci-dessus viennent d'années de fautes, mais j'ai toujours su que je voulais aider mon équipe à grandir, et je savais que la productivité était reine, alors j'ai continué d'essayer de nouvelles choses lorsque la dernière tentative a échoué.
La meilleure réponse a déjà été acceptée, mais je suis surpris que personne n'ait fait remarquer que l '"attribution de tâches" n'est pas la seule chose avec laquelle le gestionnaire peut travailler. Avoir un "programmeur au-dessus de la moyenne" qui a également des "compétences de communication au-dessus de la moyenne" devrait (toutes choses étant égales par ailleurs) être un développeur mieux payé/plus expérimenté que quelqu'un ayant des compétences de programmation similaires et de faibles compétences en communication. Cela peut aider à compenser tout "favoritisme" perçu de l'équipe. (Dans certaines organisations, avoir des compétences supérieures à la moyenne dans "Analyse des exigences" et des compétences inférieures à la moyenne dans d'autres domaines peut valoir beaucoup plus pour l'entreprise en raison du type de travail effectué. En tant que gestionnaire, vous devez décider comment gérer cela. .)
Une autre chose à surveiller: ne donner à la personne en question que des tâches de programmation mènera à l'isolement à long terme. Assurez-vous de continuer à leur confier certaines des autres tâches (mais celles-ci peuvent bien faire, ne les configurez pas pour des commentaires négatifs !!) afin qu'elles soient à la fois visibles et visibles par les autres départements/équipes.
Enfin ... vérifiez auprès des autres membres de l'équipe s'ils voient tout inégalité dans les affectations d'équipe périodiquement. Cela peut être une grande préoccupation pour vous, mais n ° 15 sur la liste de tous les autres.