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 existe généralement une division 30/70 des tâches de programmation en "autre travail technique". Ce travail comprend:

• Travailler avec des équipes DBA / Unix / Network / 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 s’acquitter de tâches plus banales. J’essaie donc de répartir les tâches de programmation amusantes de la même manière au sein de l’équipe.

La plupart des membres de l’équipe ont été embauchés parce que, même s’ils ne possèdent peut-être pas les compétences de programmation élites pour écrire leur propre compilateur / moteur de jeu / système de trading haute fréquence, etc., ils sont de bons communicateurs qui «peuvent faire avancer les choses» et travaillent avec d’autres équipes. et naviguez un peu dans la bureaucratie complexe ici. Ce sont de bons développeurs, mais ils constituent é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, l'ancien responsable du développement avait tendance à lui confier les tâches de programmation et non les tâches les 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 des compétences complètes, ce qui est généralement nécessaire dans un service 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 fasse l'autre travail plus lentement). Mais cela va à l’encontre de mes principes et encourage l’idée que vous pouvez vous tailler une "niche confortable" en vous opposant simplement à des tâches que vous n'aimez pas.

Je tiens à préciser que je n'essaie pas de régler ce problème en raison d'une rancune, ni que j'ai une "puce sur l'épaule", comme cela a été mentionné. Je cherche des conseils sur la manière de garder une équipe complète, heureuse et motivée. En observant la variété des réponses à cette question, il semble qu’il existe de nombreuses opinions divergentes sur la manière d’y parvenir.

On dirait que vous faites trop d'efforts pour avoir des individus bien formés et pas assez pour avoir une équipe bien formée .

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 de bon en programmation pour commencer.

Vous avez déclaré:

... cela va à l’encontre de mes principes et encourage l’idée que vous pouvez vous tailler une "niche confortable" simplement en étant mauvais dans les tâches que vous n'aimez pas.

S'il était un programmeur médiocre, alors je serais d'accord. Mais vous n'avez pas dit ça. Vous avez dit qu'il était un bon programmeur. Il ne craint pas 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 veiller à ce que tout le monde soit "complet". C’est à vous de veiller à ce que ce soit fait. Et tu ne fais pas ça. En fait, vous prenez des décisions qui empêchent les choses de se faire.

Quel que soit le problème rencontré, vous devez vous en occuper - vous rendez votre équipe moins productive.

Dans les autres réponses, vous attrapez un peu de pression pour que vous décidiez 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 s’acquitter de tâches plus banales», ils vont être fâchés que vous récompensiez la mauvaise performance du pauvre communicateur en lui donnant 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 des appels, travaillez avec des membres du personnel autres que les informaticiens connaissant à peine une souris depuis un clavier, écrivez des plans pour la déconnexion des utilisateurs, et plus encore, tout cela parce que votre supérieur hiérarchique vous le recommande. Le développeur grincheux, entre temps, parce qu'il a de "mauvaises compétences en communication", reste assis dans son cube toute la journée en ignorant les utilisateurs travaillant uniquement sur le "divertissement".

Maintenant, vous avez dit que le développeur 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 un tiers de votre équipe, ces bons développeurs qui communiquent et qui sont au moins le niveau de compétence du développeur, se sentent tous énervés.

Vaut-il la peine de perdre un peu de productivité de votre personnel performant parce qu’il est contrarié par le grumpy-dev? Vous devrez décider.

À moins que vous ne vouliez virer le gars, je vous suggère de prendre l'une de ces approches:

1) Le mentor lui pour être un meilleur communicateur. Vous seul pouvez savoir si cela est réalisable. Vous trouverez peut-être que le simple fait de tenir sa main pourrait aider. Certaines personnes sont simplement terrifiées par les interactions professionnelles formelles et l'expriment en se fâchant 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 valorisez les bons communicateurs et que vos développeurs ne seront plus aussi agacés, mais que la récompense doit être réelle et significative. "Le déjeuner avec le chef de district" ne suffira pas. Une récompense "joueur de star / kudos / attaboy" ne sera pas non plus une récompense. Il doit s'agir d'argent supplémentaire, de congés supplémentaires, d'horaires flexibles, d'une reconnaissance sérieuse de la part des supérieurs hiérarchiques qui contrôlent les augmentations de salaire, etc.

Tout d’abord, blâmer les membres de votre équipe ... dénote de mauvaises compétences en gestion.

Je veux dire, s'il a vraiment de mauvaises compétences en communication, je suis vraiment désolé pour sa vie sociale, mais vraiment, au travail, ce n'est pas autant son problème que le vôtre . Et avouons-le, il pourrait en réalité être ennuyé par votre environnement de travail ennuyeux, par des problèmes privés influant sur ses performances ou par des préparatifs secrets pour vous tuer tous.

La communication en prend au moins deux et, après tout, celui qui a les compétences des personnes pauvres pourrait être vous. Peu importe le reste des membres de l’équipe qui s’entendent bien, ils pourraient tous compenser (même inconsciemment) un problème de communication que vous avez et que vous ignorez avec béatitude.

Et de toute façon, n'allez pas demander à Internet si des personnes occupent trois bureaux, allez voir le type et demandez-lui s’il ya vraiment quelque chose qui ne va pas et si on peut y remédier. (ou quelque chose de terne qui peut être optimisé ou amélioré)

Peut-être qu'il déteste juste sa position de bureau (est-il face aux toilettes?) Et cela le met de mauvaise humeur.

Indice: écoutez la réponse, comme s'il s'agissait d'un être humain sensible, pas d'une ressource humaine.

(par exemple: essayez de lui expliquer en détail la nécessité de certaines pratiques et la signification de certaines décisions, certaines personnes creusent des détails, car ils leur donnent l'impression 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 que le développeur ayant de faibles compétences non techniques y travaille. Je voudrais savoir ce que le développeur aime (ou aimerait faire) sans impliquer davantage de compétences non techniques. Engagez-les dans cette tâche et, idéalement, ils amélioreront les compétences générales en tant qu'effet secondaire.

Les gens ne sont souvent pas mauvais pour quelque chose pour sortir du travail; ils sont mauvais parce qu'ils ne l'apprécient pas ou n'ont pas d'aptitude à le faire. Vous ne pouvez pas aider le dernier, alors travaillez sur le premier.

La division 30/70 peut être le point de départ de tous vos problèmes. Je n'ai jamais vu de développeurs heureux de se séparer comme ça.

J'ai vu des développeurs être à l'aise avec 10, 15% d' autres travaux (et j'étais heureux parce que c'est amusant quand la dose est correcte), mais 30%, c'est trop. Je préférerais penser que les autres membres de l'équipe préfèrent ne pas dire ce qu'ils en pensent, il n'y en a qu'un qui n'aime pas "30% autre travail".

Je pense également qu’il est important d’ajuster vos «calculs de productivité» à des chiffres plus réalistes. Il ne sera jamais égal à 100% à cause des pertes inévitables lors des "changements de contexte".

• ^{30 + 70, qui totalise jusqu'à 100% de productivité lors du basculement entre la programmation et un autre travail , ne se produiront jamais dans la vie réelle; il est plus probable que ce soit 20 + 50 ou même 20 + 40. Les changements de contexte sont particulièrement pénibles pour les développeurs de logiciels - si cela vous intéresse, consultez cet article pour une bonne explication de la raison qui explique cela: NE RÉVEILLEZ PAS LE PROGRAMMEUR!
  Les programmeurs qui attachent de l'importance à leur productivité seraient naturellement mécontents de telles pertes.}

Pour ce qui est des tests en cours d’emploi, avez-vous envisagé de les passer aux testeurs? Le fait que les programmeurs puissent le faire (je pense que tout programmeur expérimenté devrait en être capable) ne veut pas dire qu'ils devraient le faire . Les testeurs peuvent le faire aussi, et ils le font mieux, et ils ne subiront aucune perte de productivité lors de "changements de contexte".

Un autre point qui me fait me demander comment vous utilisez les ressources d’AQ est votre mention de Support / Investigation . Les testeurs professionnels avec qui j'avais l'habitude de travailler ont tendance à avoir le "premier mot" dans des choses comme ça.

• ^{En tant qu'ex-testeur moi-même, je les comprends assez bien - les problèmes de production m'ont été (en tant que testeur) une source précieuse 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 la hiérarchisation des défauts ("d'accord, cela a été couvert par des tests et signalé avant la publication, mais ai-je défini la priorité / gravité appropriée à l'époque?").}

Il est assez facile pour un bon testeur de savoir quand passer l’enquête sur les problèmes de support aux développeurs, et cela ne se produit pas très souvent. Les raisons pour surcharger les développeurs avec cela échappent tout simplement à mon esprit. Comme je l'ai déjà écrit, ils peuvent certainement le faire (je m'attendrais généralement à ce que le développeur principal sache comment faire ce que fait l'assurance qualité), mais cela ne veut pas dire qu'ils devraient le faire .

J'ai 2 choses à dire à ce sujet

1. Avez-vous recruté un codeur ou un développeur de logiciels?
   Lorsque vous envisagez de créer un logiciel, tout ce que vous avez mentionné fait partie intégrante du développement de logiciels. Vous ne pouvez en ignorer aucun, à moins que vous ne l'ayez recruté pour une tâche spécifique. OMI 50% du développement logiciel total est codé reste tout est la conception, l'analyse, les tests, la documentation, etc.

2. Personne n'est né parfait.
   Il est impossible que vous trouviez une personne qui est bonne en tout. Vous devez les faire lutter et leur faire apprendre des choses.

En tant que responsable, vous devez en tirer le meilleur parti. Je suis d’accord mais, à long terme, vous pourriez vous heurter à des problèmes. Attribuez-leur des tâches légères pour qu’elles aient tendance à s’y prendre. Donne-leur le sentiment que je ne suis pas bon en la matière / que je ne peux pas me permettre de le faire . Surtout, traitez tout le monde de la même manière, afin que votre équipe produise le meilleur rendement possible.

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 énuméré, le programmeur doit alors approfondir ses autres compétences en se voyant attribuer davantage de tâches autres que celles de programmeur. De même, vos compétences en matière de programmation ne seront pas améliorées si vos autres membres du personnel doivent constamment travailler à des tâches autres que celles de 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 pourrez peut-être tout de même faire tout en répartissant 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 votre équipe est suffisamment nombreuse, il est probablement logique de créer des groupes spécialisés dans différents domaines. D'après votre article, il semble que votre équipe ne soit pas assez nombreuse pour former des groupes de spécialistes.

Il n’est pas clair dans votre message d’origine que les compétences de ce développeur en matière de communication manquent tout à fait. Un manque d'intérêt pour aller à des réunions ou pour effectuer un 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 un travail de manager et réduit sa productivité en tant que développeur? Ou peut-être pense-t-il qu'il y a trop de frais généraux d'organisation et qu'il s'agit d'une forme de protestation contre ce qu'il estime être une perte de temps globale? Après tout, le problème inverse, où les gens parlent toute la journée et ne font rien, est également courant au bureau.

Il est important que vous discutiez avec ce développeur de manière non conflictuelle et que vous essayiez de comprendre pourquoi il évite les tâches non liées à la programmation. Ce n'est probablement pas une raison unique, il peut avoir autant de raisons différentes qu'il existe différents types de tâches. Assurez-vous qu'il comprend bien que l'objectif de la conversation est d'apprendre à améliorer efficacement la productivité de l'équipe et la satisfaction au travail de tous les membres de l'équipe (vous n'êtes pas prêt à l'obtenir). C’est le moment pour vous d’écouter et de ne pas discuter ni essayer de répondre à ses préoccupations concernant les réactions instinctives. Vous devriez probablement également rencontrer les autres membres de l’équipe. Peut-être qu’ils sont tout à fait en mesure de laisser ce gars faire le gros travail de développeur tout en se concentrant sur le côté plus bavard de la profession.

Après cette réunion, prenez le temps de 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 certaines compétences importantes que vous devriez le pousser à développer. Ou peut-être a-t-il contesté vos hypothèses avec des arguments valables. Peut-être pouvez-vous 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 épingle du jeu et vous devez avoir une conversation amicale avec leur direction. Il existe de nombreuses possibilités que vous ne pouvez pas envisager.

Enfin, et surtout, organisez une conversation de suivi avec des personnes ou organisez une réunion d’équipe si cela convient. Si vous avez identifié de véritables problèmes d’organisation qui sont en votre pouvoir, informez 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, assoyez-vous avec lui et expliquez-lui les changements que vous attendez de lui 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 ce travail amusant. Nous aimerions que vous soyez tous de purs devs, 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 type n'est qu'un imbécile grincheux, refuse de vous dire pourquoi il est malheureux, ne répondra pas à la raison et ne sera pas bien respecté par ses pairs ... eh bien ... il est temps de passer au plan d'amélioration des performances.

Bien que vous essayiez de gérer une équipe et que vous vouliez garder tout le monde motivé (avoir un sens de l'équité peut vous aider), mais sacrifiez-vous le projet en n'ayant pas votre meilleur programme de programmation? 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 décharger tout le monde de ces tâches.

Être traité de manière égale ne signifie pas que vous traitez tout le monde de la même manière. Si les autres veulent se libérer des tâches non liées à la programmation pour se voir attribuer davantage de tâches de programmation, ne courent-ils pas le risque de ne pas être bons dans ces domaines?

EDIT: En dehors de vos sentiments personnels, vous n'avez pas identifié de problème. À un moment donné, le manque de communication empêche 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 au dire de tous). Quelqu'un d'autre veut venir un peu plus tard. Un autre devra sauter une réunion pour respecter une date limite. Une personne graphique obtient un moniteur plus grand. Lorsque vous mettez trop d'emphase sur le pointage, vous oubliez ce qui est important.

Je suis un administrateur grincheux de Linux qui écrit beaucoup de scripts et il a été remarqué que mes compétences en communication sont médiocres. Je ressemble beaucoup à ton mec. En fait, c’est le seul domaine qui m’attire dans les évaluations de rendement. De l'autre côté, je dirige continuellement mon équipe en matière d'innovation et de résolution de problèmes. J'ai créé et ouvert la voie à la nouvelle plate-forme que nous déployons et fait gagner beaucoup de temps à mon équipe et à mon entreprise. beaucoup d'argent en étant autorisé à être moi-même.

Mon ancien patron a été demandé à sa famille / épouse ET à la haute direction de notre société de quitter son poste ... simultanément. Il a travaillé sans relâche pour équilibrer équitablement ses responsabilités et a lui-même pris beaucoup de charge. Au cours de toute interaction avec des personnes extérieures au ministère, s'il y avait un malentendu dans la communication qui lui revenait, il était prompt à, euh, le corriger de manière punitive. Il était faible en «gestion ascendante»; notre équipe a donc été la dernière à obtenir des ressources en cas d'urgence, puis la société a sur payé des fournisseurs qui vendaient du matériel informatique 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é notre liste 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 géniaux. ce qui a entraîné BEAUCOUP de code cassé ou d'implémentations mal architecturées. Alors que des personnes autres que l'auteur se voyaient attribuer des tâches de support spécifiques pour ce code erroné afin de pouvoir "apprendre" - les implémentations, le code et les tests mal architecturés créaient beaucoup de mauvaise volonté entre les membres de l'équipe etla multiplication des "jeux de reproches", voie rapide vers un état d'équipe toxique.

Mon patron actuel est une personne calme et recueillie qui vient du rôle d'administrateur junior et a gravi les échelons. Il prend de bonnes décisions et compte beaucoup sur les membres de l'équipe pour définir leurs propres priorités. Il est un excellent communicateur et réagit calmement et de concert avec son superviseur face aux problèmes de communication, aux idées ou aux besoins exprimés par mon équipe. Il "travaille vers le haut" sans relâche. Il est lent à effectuer des modifications architecturales majeures et consulte minutieusement toute l'équipe avant de modifier notre environnement. Il est à l'aise avec le fait de pouvoir compter sur les spécialités de ses membres.

Avec le nouveau responsable, notre temps d’arrêt est tombé à près de zéro (ce qui a également fait baisser le pourcentage de temps consacré aux tâches de support d’environ 40% à environ 10%), la satisfaction de notre équipe a explosé, et nous sur le point d’être passé d’un «cambodge à la banque de nouveau matériel tous les trois à cinq ans» à un plan d’acquisition continu qui devrait permettre à la société d’économiser environ un million de dollars par an sur cinq ans. Ce plan était un programme de base qui n'aurait jamais existé sous le précédent directeur mais qui a été activement poussé vers la haute direction par le nouveau directeur et reposait sur la recherche de nombreuses 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 la société qui «a vraiment sa merde» et qu'il ■ Nous allons interférer le moins possible dans notre environnement de travail et utiliser autant de ressources que possible pour résoudre les problèmes identifiés. Cela est vrai, et le "coût" de notre support est encore réduit, même si cela a perturbé la charge de travail de certaines autres équipes - mais il a également réduit le "coût" du support de ces équipes.

Regardez, les développeurs peuvent améliorer leurs compétences à l’école ou à leur propre rythme. La place 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 connaissent le mieux. Lorsqu'ils travaillent dans des zones où un développeur n'est pas à l'aise, ils doivent faire appel à un second développeur spécialisé et travaillant en équipe, ou le développeur spécialisé doit rédiger le code et produire la documentation et les diagrammes. Route des tâches de support aux personnes qui ont écrit le code. Oui, cela augmente ce que nous appelons votre "facteur d'autobus" - la probabilité que votre service rencontre un ralentisseur si le spécialiste devait se faire renverser par un bus. (Ou mis à pied, ou changer d'emploi, ou ...) La vérité, c'est que votre perte de productivité due à cette peur est un ordre de grandeur supérieur à la perte réelle résultant d'un "événement d'autobus". arrive. Ce qui se produit généralement lors d’un "événement de bus", c’est que l’héritier du spécialiste le reconfigure à son image afin de le soutenir de la manière la plus efficace, en résolvant généralement un tas de problèmes et en réduisant encore le temps consacré à l’assistance. sur.

Attribuez des choses aux personnes qui peuvent le mieux faire. Faites-les soutenir et documenter leur travail. Encouragez leur créativité et permettez-leur de se concentrer sans distractions ni microgestion. Tout le reste est une école de gestion BS, qui semble malheureusement donner l'impression que votre entreprise y va. Cela ne veut pas dire que votre équipe doit aussi y nager.

Du point de vue de l'entreprise, un bon manager promeut les valeurs de l'entreprise tout en exécutant les tâches conformément à ces valeurs. Du point de vue des employés informatiques, un bon manager laisse l'équipe faire ce qu'il convient de faire le plus rapidement et le plus proprement possible et constitue une barrière fécale contre les cadres supérieurs qui transmettent les valeurs qu'ils ont apprises lors des cours de MBA en fin de semaine. Vous êtes un homme d’entreprise et cela n’est peut-être pas le meilleur pour votre équipe. Ceux qui ont de "bonnes" compétences en communication sont trop polis pour le dire.

• Assurez-vous que l'employé sait à quel point les compétences en communication sont essentielles à la description de son poste. Travailler avec lui pour s'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 en fonction des principes auxquels vous croyez. Trouvez un équilibre entre une affectation efficace des tâches à des compétences et équité / plaisir.

Ce ne sont que des idées sommaires. Espérons que quelqu'un vole ces points et les intègre dans l'une des autres réponses. ;-)

La performance est tout. Donnez-lui les tâches de programmation. Parlez-en avec le reste du ministère. Vous pouvez éventuellement faire venir quelqu'un pour effectuer des tâches de communication ou charger quelqu'un uniquement sur des tâches de communication. Ne pensez pas à la programmation de vous amuser. Tout est "fun" de votre POV.

Sinon, vous créerez une situation extrêmement difficile à gérer et moins efficace qu'elle ne le pourrait.

Quelle bonne question, c’est le genre de chose à laquelle tous les chefs d’équipe, superviseurs et responsables techniques doivent penser. J'aime votre approche, tout le monde devrait avoir une tâche "amusante". Prendre plus d' avoir une équipe qui peut pick - up différentes tâches et empêche la Croix formés Peterbilt Principe de causer des ravages 'équipe de feuilles de membre de l' équipe indesipensible ou prend même le souffle coupé vacances.

Maintenant, comme le signalent de nombreux articles, le travail n’est pas équitable et ne devrait pas l'être. Les gestionnaires sont évalués en fonction du travail précieux accompli.

• Les gestionnaires associent des tâches à des personnes 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 grands gestionnaires demandent à leur équipe de le faire avec un peu d'aide et de conseils. C'est-à-dire sans que le responsable y passe toute la journée.

Parlez à votre bon programmeur, demandez-lui s'il a des choses qu'il veut apprendre. Quelles autres tâches accepterait-il… même le moins inacceptable pour lui? Peut-il aider les autres membres de l'équipe dans leur programmation ... les encadrer? Oui, je sais que la communication est un problème, alors il devrait peut-être y travailler.

Une autre façon de procéder consiste à dresser une liste de tâches et à laisser chaque membre du personnel choisir quelque chose. Laissez votre bon programmeur choisir en premier. Si vous le prévenez à l'avance et montrez-lui 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 productivité, c'est un signe que les gens apprennent. Ce projet peut en souffrir, mais le prochain sera meilleur.

En conclusion, votre travail consiste à vous assurer que tout est fait, mais votre personnel aussi va grandir et si vous pouvez les impliquer encore plus dans le processus. Certains pourraient dire que le meilleur moyen de s’assurer que tout est accompli est une équipe qui sait ce qui doit être fait et qui détient les résultats.

Edit: Oh, continue d'essayer, les conseils ci-dessus proviennent d'années de erreurs, mais j'ai toujours su que je voulais aider mon équipe à grandir, et je savais que la productivité était primordiale. J'ai donc essayé 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 ne souligne le fait que "l'attribution de tâches" n'est pas la seule chose avec laquelle le gestionnaire peut travailler. Avoir un "programmeur supérieur à la moyenne" qui possède également "des compétences de communication supérieures à la moyenne" devrait (toutes choses étant égales par ailleurs) être un développeur mieux payé / plus expérimenté qu'une personne ayant des compétences de programmation similaires et de faibles compétences en communication. Cela peut aider à neutraliser tout "favoritisme" perçu de la part de l'équipe. (Dans certaines organisations, avoir une compétence supérieure à la moyenne dans "l'analyse des besoins" et une compétence inférieure à une moyenne dans d'autres domaines peut valoir beaucoup plus pour l'entreprise en raison du type de travail effectué. En tant que responsable, vous devez décider comment gérer cela. .)

Une autre chose à surveiller: ne donner à la personne en question que des tâches de programmation conduira à l'isolement à long terme. Assurez-vous de continuer à leur donner certaines des autres tâches (mais ils peuvent bien le faire, ne les configurez pas pour un retour négatif !!) afin qu'elles soient visibles et visibles pour les autres départements / équipes.

Enfin ... vérifiez auprès des autres membres de l'équipe s'ils constatent périodiquement des inégalités dans les tâches assignées à l'équipe. Cela peut être un gros problème pour vous, mais le n ° 15 sur tous les autres.

Étant donné que, de par votre propre évaluation, ce programmeur est le meilleur de l’équipe, il est en quelque sorte "juste" de donner à cette personne le travail souhaité (après avoir démontré qu’elle est la plus apte à le faire). Après tout, il y avait probablement des personnes qui auraient aimé travailler dans cette entreprise mais qui n’aient pas été embauchées - mais personne ne dira que ce n’est pas «juste» pour elles de ne pas coder.

Je pense qu’une approche juste consisterait à dire à un autre membre de l’équipe moins expérimenté qui souhaite faire plus de codage: "nous laissons (tel et tel) prendre les devants sur celui-ci. Peut-être pouvez-vous prendre les devants la prochaine chose qui se passe, si vous pouvez démontrer avoir acquis des compétences x et y ".

Comme certains des autres qui ont répondu, je comprends votre position et j'aurais des ambitions similaires.

S'il est raisonnable d'affirmer qu'il est judicieux de confier des tâches aux personnes les mieux équipées pour les mener à bien, il est également judicieux d'élargir les compétences de chacun afin de constituer une équipe dynamique et flexible.

Si ce type est obligé de faire des éléments non codants dans son rôle, mais que ses compétences en communication sont plus médiocres qu'il n'est vraiment nécessaire, il doit s'améliorer. En supposant que vous disposiez d’un système d’examen / évaluation du développement, le moment est venu de soulever la question.

L’essentiel est de définir clairement ce que vous attendez de lui, d’évaluer s’il possède les compétences nécessaires pour s’y conformer et d’élaborer un plan de formation permettant de le faire. La formation ne doit pas nécessairement être formelle, mais vous devez l'aider à acquérir les compétences requises.

S'il ne peut tout simplement pas être dérangé, il en résulterait finalement une question de discipline. S'il n'en a pas la capacité, malgré les tentatives et l'appui de votre part, des mesures disciplinaires peuvent être prises (ce qui, selon moi, serait sévère et contre-productif), mais vous pouvez également accepter qu'il ne le soit pas. découpé pour certaines tâches.

Parler à ce type sera l’un de vos premiers ports d’appel . Vous pourriez trouver qu'il manque de confiance ou de perspicacité. Vous constaterez peut-être également qu’il est très réactif et qu’il appréciera l’occasion de s’améliorer.

Vous devriez engager un junior pour faire tout le travail difficile et faire savoir à tout le monde qu’ils ont besoin de l’aider pour tout ce qu’il demande.

Ils seront plus enclins à déranger le codeur «supérieur à la moyenne» en raison de leurs capacités et le reste de l'équipe obtiendra un nouveau laquais. La junior apprend de fond en comble et l'entreprise finit par trouver un employé bien formé.

S'attendre à ce que tout le monde ait les mêmes compétences en communication est aussi rationnel qu'espérer apprendre à l'homme infirme à courir aussi vite que le reste de l'équipe.

Les gens sont différents, ils ont des compétences et des faiblesses différentes. Renvoyer un bon programmeur simplement parce qu'il ne peut pas rattraper les autres en communication, ce serait comme virer un homme infirme parce qu'il ne peut pas marcher aussi vite que les autres. Ce serait injuste d'un point de vue éthique et cela irait à l'encontre de vos propres intérêts économiques: faire le travail.

Au début, si vous aviez échoué, lisez à propos du syndrome d'Asperger. . Les compétences sociales médiocres sont le principal indicateur de ce syndrome.

Deuxièmement, vous pouvez engager et licencier qui vous voulez, mais si vous ne parvenez pas à faire face aux forces et aux faiblesses de vos employés, vous vous retrouverez avec un tas de programmeurs moyens, car les meilleurs partiront (s'ils ne sont pas licenciés en premier). .

Il y a un film, Adam , dans lequel le génial programmeur est renvoyé pour avoir écrit quelque chose à quoi il ne s'attendait pas. Son idée pourrait rapporter beaucoup d’argent à l’employeur, mais il ne pouvait pas en profiter parce qu’il était concentré sur ses "principes".