Je suis manager. Comment puis-je améliorer les relations de travail et la communication avec les programmeurs?
Un peu de fond d'abord. Je suis chef de projet dans une entreprise de taille moyenne. J'ai commencé en tant que major CS et j'avais une petite exposition à la programmation, mais après quelques mois, je savais que ce n'était pas mon chemin, alors je suis passé à la gestion. Cela s'est avéré être une bonne décision, et après avoir obtenu mon diplôme, j'ai travaillé dans la gestion de logiciels dans diverses entreprises (depuis 5 ans maintenant).
Récemment, nous avons eu un projet très douloureux. Ce fut la pire des pires, avec de nombreuses erreurs de notre côté et du côté des clients et à peine à y mettre fin sans pertes. Cela a conduit à de nombreuses situations frustrantes, dont l'une a dégénéré au point où l'un de nos développeurs seniors a quitté l'entreprise après une discussion vocale avec nous (la direction). C'était un drapeau rouge pour moi: j'ai fait quelque chose de terriblement mal. (pour mémoire, l'argument portait sur plusieurs estimations de temps erronées)
J'ai cherché dans de nombreux endroits des réponses et un ami m'a dirigé vers ce site. Il y a beaucoup de questions ici sur les frustrations de la direction. Je peux comprendre que les mauvaises expériences générales conduisent à une réticence générale contre "ces gars en costume".
Je suis ce type en costume. Cela peut ne pas lui ressembler, mais tout ce que je veux, c'est un projet réussi, et avec des ressources limitées, il prend des décisions douloureuses. C'est mon travail. Le développeur principal susmentionné s'est plaint de l'équipement de travail. Franchement, je ne savais pas que les ordinateurs que nous avions n'étaient pas adaptés pour fonctionner. Après cela, j'ai demandé à de nombreux programmeurs et le consensus général était que nous avons besoin de meilleures machines. J'ai corrigé cela depuis lors, mais il y avait évidemment un énorme fossé de communication entre moi et les programmeurs. Certains des développeurs les plus brillants sont les personnes les plus timides et silencieuses. Je le sais et cela n'a jamais posé de problème lors d'une interview. Les gens sont différents et ont des forces dans différents domaines.
Le cas des PC sous-alimentés n'est que l'un des nombreux qui m'ont amené à penser qu'il y a un problème de communication. Comment puis-je améliorer la communication avec les programmeurs sans être intimidant et répétitif?
Ce que j'espère, c'est que les gens ne se plaignent pas de bonnes choses. Si vous aimez votre lieu de travail et aimez (ou au moins comme :)) votre manager, veuillez m'en parler. Que font-ils bien? De même, si vous le détestez, veuillez expliquer en détail pourquoi. Je cherche des réponses sur l'amélioration de la communication parce que je pense que c'est mon problème, mais je peux me tromper.
Hou la la! Merci d'avoir posé la question. Techniquement, comme vous, je suppose que je suis gestionnaire, car je passe beaucoup plus de temps à communiquer et à diriger des équipes que j'écris du code ... mais voici mon point de vue aux deux extrémités de l'horizon de gestion. Que je sois développeur ou manager travaillant pour un autre manager, voici quelques trucs qui m'aident dans ma communication avec ma direction:
- Pourquoi? est une question très importante - presque toutes les réponses factuelles ont un "pourquoi" et ce "pourquoi" pourrait bien être plus important que le réel question. Il y a quelques tangentes à cela:
- Pourquoi les développeurs - Les développeurs auront beaucoup de réponses qui n'ont absolument aucun sens pour la direction. Je l'ai certainement fait, et l'une des façons dont je me suis lancé dans la gestion a été de bien expliquer les "pourquoi" des équipes en termes de compréhension que la direction pouvait comprendre. Si vous n'avez pas de "locuteur pour les geeks", vous pouvez apprendre à parler geek en reformulant leurs réponses à la question du pourquoi dans des métaphores plus communément comprises. Continuez à le faire jusqu'à ce que vous compreniez et conveniez de ce qui se passe.
- Le pourquoi de la gestion - votre "pourquoi" est tout aussi important. Pourquoi avez-vous besoin des estimations de temps? Pourquoi les utilisez-vous? À quel point serons-nous vissés en tant qu’entreprise si elles sont trop hautes ou trop basses? Ce sont des choses que vous, en tant que manager, avez probablement un aperçu approfondi, mais tout cela vaudou pour le développeur. L'astuce est que le développeur ne peut pas demander. La direction lui a demandé quelque chose, et il fera de son mieux pour être précis, opportun et réfléchi - mais s'il ne sait pas le "pourquoi", il peut optimiser comme vous préférez qu'il ne le fasse pas. Proposez votre pourquoi et demandez-lui de faire la même chose - reformulez la réponse dans ses propres termes. De même - expliquez le pourquoi de l'entreprise - souvent les développeurs se soucient mais n'ont aucune connaissance directe du fonctionnement du développement commercial - demander à quelqu'un de fournir ces informations est à la fois motivant et instructif.
En ce qui concerne les estimations de temps en particulier - j'ai dû faire des tonnes, et j'ai absolument profité de dire à mon équipe de développement "J'en ai besoin parce que je vais demander plus d'argent pour payer nos salaires, je vais faire confiance à ce que vous me direz et J'utiliserai vos chiffres ... cela veut dire que si vous me baissez la tête, nous sommes tous foutus car je ne pourrai pas demander d'argent une deuxième fois - nous devons vivre avec ce que nous proposons ". Dans ce contexte, les développeurs sont passés de faibles estimations qui ont tenté de me montrer à quel point elles étaient confiantes et brillantes à des estimations élevées qui se sont beaucoup rapprochées du cadre des attentes réelles.
Personne ne se trompe - La question du "pourquoi" va longtemps avec un corollaire - demander "pourquoi" au lieu de dire "c'est scandaleux! Pas question!" maintient la conversation fluide. Parfois, il y a un grave décalage entre ce que l'on demande à quelqu'un et ce que le demandeur demande. Ma meilleure direction a été horriblement surprise par mes réponses, et lorsqu'elle est surprise, elle clignote d'étonnement et demande ensuite "pourquoi dites-vous cela?". Ils ne disent pas (immédiatement) - "vous devez le changer". J'ai réduit le nombre de propositions pour atteindre un objectif concurrentiel, mais seulement après avoir longuement discuté de la façon dont nous pourrions changer la scène et créer un contexte différent pour la question.
écoutez le bruit ambiant, le choix des mots et l'espace entre les mots - Voici un tas de choses que j'ai aimé et volé pour moi-même:
- traîner dans la zone de travail, faire quelque chose de productif de votre part (n'essayez pas de faire du travail de développeur, ils savent que vous n'êtes pas un développeur) et écoutez simplement. Comment l'équipe résout-elle les problèmes? Quels sont leurs gros problèmes? Vous n'entendrez jamais le vrai maigre sur leur évaluation directe de vous ou de la direction en général, mais vous pouvez avoir une très bonne idée de l'endroit où se trouvent les problèmes. Assurez-vous que vous faites quelque chose de vous-même qui est productif. Personne n'aime espionner, mais à moins que le moral ne soit si bas que vous ne puissiez pas être près d'eux sans que tout le monde évacue, la productivité à proximité devrait être tolérable.
- recherchez les choix de mots - ils sont souvent aussi importants que les mots eux-mêmes. Lorsque j'ai utilisé des mots particulièrement positifs ou négatifs, ma direction me demande fréquemment pourquoi j'ai choisi ces mots alors que c'est une situation qu'ils ne connaissent pas.
- recherchez les pauses, les lacunes et le langage corporel. S'il y a une distance de puissance entre vous et les développeurs (et cela semble être le cas), ils ne voudront peut-être pas vous contredire ou vous confronter. Mais l'instinct de base de dire "hé, vous avez tort" se manifeste généralement quelque part.
s'ouvrir à autant de supports de communication que possible - être prêt à discuter en personne, au téléphone, par email, par IM - tout et n'importe quoi pour établir le flux de communication. Les gens sont tellement diversifiés qu'une seule astuce ne fonctionnera pas. Et je considère que le travail du manager est d'être le communicateur multiformat, pas le développeur.
il vaut la peine de vous parler Si quelqu'un vous parle d'un problème et peut-être d'une solution possible, il devrait et probablement accepter que vous êtes le gestionnaire et peut donc décidez en faveur d'une solution différente, ou pas de solution du tout parce que vous ne pensez pas que cela en vaille la peine. Mais après la troisième fois, cela se produit, surtout si cela se produit sans explication, environ 99% des gens cesseront de vous dire quoi que ce soit.
Et voici celui qui est incroyablement difficile pour moi, mais qui a très bien fonctionné quand je peux le faire - soyez conscient de la différence entre les introvertis et les extravertis . Il y a de fortes chances que vous soyez un extraverti - c'est pourquoi votre travail semblait bon et pas un poste de développement. Les développeurs sont, pour la plupart, des introvertis. "Introverti" ne signifie pas "ne peut pas communiquer", mais cela signifie que leur schéma, leur processus et leur vitesse sont sensiblement différents et que l'envie de communiquer sans cesse est pratiquement inexistante. Planifiez dans le temps et dans un espace calme (mais colocalisé) pour laisser sortir les pensées introverties. Beaucoup de mes amis introvertis me disent qu'ils n'attendent que moi que je me taise pendant environ 5 minutes pour qu'ils puissent réfléchir et répondre. Voici quelques excellents articles sur la même chose - 5 choses que les extravertis devraient savoir sur les introvertis et Rands in Repose on the Nerd Cave - un exemple particulièrement révélateur de ce qui est génial pour les introvertis =. Soit dit en passant, Rands est assez fantastique. C'est un geek lui-même, donc il vient du développeur, ce qui peut être rebutant si ce n'est pas votre style, mais il est drôle et a de très bonnes idées sur le développement de l'équipe.
Je pense que les choses que j'ai adorées chez mes managers préférés étaient:
ils étaient aussi profondément engagés et enthousiastes à propos du projet que moi (sinon plus)
Je n'ai jamais douté qu'ils m'ont soutenu - je savais avec certitude que lorsqu'ils seraient devant le prochain niveau d'autorité que moi (ou mes pairs) ne serais jamais le bouc émissaire. Ce serait toujours un échec de groupe, s'il y avait un échec.
On m'a donné la propriété de quelque chose d'important et approprié à mes compétences à l'époque, mais avec suffisamment de ressources pour développer mes compétences et faire le travail.
ils me considéraient à la fois comme un individu et comme faisant partie de l'équipe - ils étaient activement engagés à connaître mes forces et mes faiblesses et à travailler pour m'aider à jouer sur mes forces et à augmenter mes faiblesses.
ils étaient conscients de mes objectifs personnels et souhaitaient les incorporer autant qu'ils le pouvaient
ils étaient francs lorsqu'ils me rendaient heureux ne pouvaient pas et ne seraient pas une priorité. Il y a une réelle valeur à entendre "Je sais que vous détestez ce type de travail, mais j'ai besoin que vous le fassiez - voici comment cela ne sera pas éternel ...".
il y avait toujours du temps dans une semaine (peut-être pas pour l'instant) pour expliquer la situation dans son ensemble
il y avait une rétroaction et un statut presque constants sans pointage du doigt mais beaucoup de reconnaissance pour le travail individuel.
il y avait toujours la vérité. Si quelque chose était sensible et ne pouvait pas être discuté, ils l'ont dit sans détour. Si quelque chose était incertain, ils donnaient un niveau de confiance.
La partie facile d'abord: il y a un drapeau rouge technique dans votre message: je frémis à votre mention d '"estimations erronées" - c'est une estimation, elle NE PEUT PAS ÊTRE MAUVAIS, c'est pourquoi on l'appelle une estimation. Cela peut être un peu décalé, il peut l'être beaucoup, c'est pourquoi cela s'appelle une estimation. Si vous considérez les estimations comme du gospel, ce sera l'un des principaux problèmes que "vos" développeurs rencontrent avec votre style.
Cependant, je suis à 100% d'accord avec vous sur la difficulté de communiquer avec les développeurs. J'ai eu une révélation il y a plusieurs années, en tant que développeur dans une formation en gestion de projet. J'ai vu plusieurs de mes collègues développeurs s'opposer absolument à la direction après la création d'une atmosphère de discussion ouverte (la direction était présente ici). Tout ce qui n'allait pas était la faute des managers aux yeux des développeurs. Le coup de pouce était que la direction n'avait aucune idée de la quasi-totalité des énormes problèmes soulevés ce jour-là. Les développeurs supposaient que tout était si évident que la direction ne pouvait pas l'avoir manqué, et la direction supposait que les développeurs leur diraient ce dont ils avaient besoin.
Par conséquent, à mon humble avis, la première partie de la réponse doit être de faire savoir à vos développeurs que vous n'êtes pas psychique, et en fait probablement carrément stupide en ce qui concerne le côté technique. Vous comptez sur eux, vous comptez sur eux et vous leur faites confiance pour venir à vous en temps opportun. Vous êtes là pour leur faciliter la vie, pas plus dur.
Et quoi que vous fassiez, ne leur posez PAS de questions auxquelles vous ne voulez pas vraiment répondre - en vous référant aux "estimations erronées" ci-dessus ;-). C'est la kryptonite d'un développeur.
Il y a beaucoup de bonnes choses ici, mais je pense que ce qui suit doit être dit .. ..Désolé d'être dur .. Mais cela doit être dit:
- 5 ans en tant que PM, et ne pas savoir de quel type de PC un développeur a besoin, c'est scandaleux.
- Pour un développeur quitter à cause de mauvaises conditions de travail comme premier vrai drapeau rouge, c'est fou.
Ce que je pense que vous avez est un problème de confiance, plus qu'un problème de communication. Personne ne dit ce qui ne va pas parce qu'ils ne font pas confiance à ce que vous ferez de ces informations, et peut même craindre que cela soit utilisé contre eux. Le développeur qui vous a parlé de tous ces problèmes l'a fait parce que il n'y avait aucune conséquence à le faire, il quittait.
Personnellement, je n'embaucherais jamais un PM qui n'avait pas d'expérience en développement dans son passé. Je pense que sur votre prochain projet, vous devriez consacrer une petite partie de votre temps à l'équipe de développement. Disons 8 heures par semaine, travaillant en tant que développeur Jr sous la direction de l'équipe.
Cela vous ouvrira vraiment les yeux sur la dynamique d'une équipe de développement, car en ce moment, vous ne faites même pas partie de cette équipe, vous êtes un outsider. Le fait que votre développeur ait cessé de vous choquer le prouve. Tout le monde dans l'équipe savait qu'il était mécontent. Et aucun d'eux ne vous a dit:
"Nous allons perdre notre meilleur gars si vous ne faites rien"
Cela devrait être le drapeau rouge # 2.
En tant que manager, je suis sûr que vous avez entendu parler de kaizen, l'un des principes du système de production Toyota qui signifie amélioration continue.
Vous avez admis que vous avez un problème, c'est donc un bon début.
Kaizen a cinq éléments principaux:
Cercles de qualité : Groupes qui se réunissent pour discuter des niveaux de qualité concernant tous les aspects du fonctionnement d'une entreprise.
Moral amélioré : Un moral élevé parmi la main-d'œuvre est une étape cruciale pour atteindre l'efficacité et la productivité à long terme, et kaizen le définit comme une tâche fondamentale pour rester constant contact avec le moral des employés.
Travail d'équipe : Une entreprise solide est une entreprise qui rassemble à chaque étape du processus. Kaizen vise à aider les employés et la direction à se considérer comme des membres d'une équipe plutôt que comme des concurrents.
Discipline personnelle : Une équipe ne peut réussir sans que chaque membre de l'équipe soit fort en lui-même. Un engagement à la discipline personnelle de chaque employé garantit que l'équipe restera forte.
Suggestions d'amélioration : En demandant la rétroaction de chaque membre de l'équipe, la direction s'assure que tous les problèmes sont examinés et traités avant qu'ils ne deviennent significatifs.
( Source )
Si vous y regardez longuement, une constante sur ces éléments est l'accent mis sur le travail d'équipe et les commentaires.
Un exemple, vous dites que vous aviez un argument sur les estimations de temps. Êtes-vous responsable de ces estimations de temps? En parlez-vous avec l'équipe? Je suis désolé mais j'ai vu des managers retirer un numéro de leur dossier. Une chose cruciale: ne jamais marchander au fil du temps, les estimations que votre équipe vous donne. Beaucoup de managers s'imaginent que s'ils peuvent respecter des délais plus courts si leur équipe travaille plus dur. Ceci est un mensonge. Neuf femmes ne peuvent pas avoir de bébé en un mois, rappelez-vous cela.
Donc, mon premier conseil:
Écoutez : commencez par un simple e-mail à l'équipe: "Quelle est la meilleure façon pour l'équipe de développement de donner un feedback à la direction sur les performances de la gestion ? ". Itérer avec l'équipe et mettre en œuvre le consensus. Votre tâche est de permettre à l'équipe de développer d'excellents logiciels, pas de les rassembler. Garde ça en tête.
Honnêteté et loyauté : Si personne ne répond quand vous demandez quelque chose, c'est parce qu'ils ne croient pas que vous allez écouter ou, pire encore, ils croient que vous allez les punir pour ça. Alors soyez honnête. Si quelqu'un dit que vous êtes nul, prenez cela comme un feedback et ne prenez pas de vengeance. Comprenez leurs raisons, améliorez-les.
Et, enfin, bien que j'aie vu des critiques à ce sujet ici, je voudrais vous recommander de lire un livre intitulé The Mythical Man-Month: Essays on Software Engineering . Le livre traite de l'expérience de Fred Brooks chez IBM lors de la gestion du développement d'OS/360. Bien que certaines choses ici et là puissent être datées, c'est la première étape pour comprendre comment fonctionne le processus de développement de logiciels complexes. S.Lott cite le Agile Manifesto , que je n'apprécie pas particulièrement, mais qui vaut également la peine d'être lu.
Lis ça:
Individus et interactions sur les processus et les outils
Logiciel de travail sur une documentation complète
Collaboration client sur négociation de contrat
Répondre au changement au sujet d'un plan
Dans de nombreux cas, l'organisation (c'est-à-dire votre patron) vous demande
suivre un processus clairement rompu jusqu'à sa conclusion logique conduisant à une "marche de la mort". Cela conduit à son tour à des arguments et à des démissions.
créer une documentation excessive, de faible valeur et inutilisée.
s'engager dans le contrôle du changement complexe a/k/a négociation de contrat. Chaque changement d'utilisateur nécessite un rituel élaboré pour "qualité" et "prioriser" le changement. Vraiment, tout tourne autour du "gel" - empêcher le changement.
suivre le plan indépendamment des conséquences. Certaines organisations apprécient la livraison à temps de logiciels cassés (voire inutiles). C'est le plan qui est apprécié, pas la solution d'un problème commercial.
Il se peut que le problème ne soit pas vos compétences personnelles en communication.
Il se peut que l '"environnement" ou la "méthodologie" de développement soit fatalement brisé, et les mauvais sentiments ne sont que le symptôme de mauvaises pratiques générales.
Pour moi, cela ressemble à vous n'avez jamais parlé avec les développeurs dans une atmosphère facile. Vos entretiens avec eux étaient simplement de nature officielle? C'est dommage.
Pourquoi ne pas les connaître personnellement et ainsi savoir ce qui est bon et ce qui est mauvais dans l'entreprise, leur lieu de travail et leurs projets? Respectez-les et gagnez leur respect, en montrant un intérêt sincère et une appréciation pour leur travail.
S'ils vous font confiance et n'ont pas à craindre d'être des offres de pion, ils vous diront probablement même des vérités peu attrayantes.
Je suis chef d'équipe et mon équipe me fait confiance. Je les protège. Je prends tout le blâme et je partage la gloire avec eux. Notre gestion me protège. Cela renforce le moral. Nous avions un projet très dur et un client presque diabolique, presque impossible à terminer mais nous l'avons fait finalement, parce que nous parlons de tout d'une manière très franche et ouverte.
Taper! Taper! Taper! Vous devez certainement être une bonne personne, car vous vous êtes manifesté ouvertement pour voir ce qui peut être fait pour améliorer votre travail.
Veuillez trouver ci-dessous ce que j'ai vu dans un grand manager et que j'ai personnellement adopté lorsque je dirige l'équipe en tant que membre senior.
- M entor plus que gérer.
- A permet aux membres de l'équipe d'exprimer leurs pensées et leurs préoccupations. Soyez à l'écoute. Prenez les constructifs.
- N jamais trahir les membres de l'équipe en jouant à la politique de division. Cela se retourne plus tôt et silencieusement.
- A non. N'ayez jamais de grimaces sur votre visage lorsque vous êtes avec votre équipe, quoi qu'il arrive. Celui-ci est vraiment difficile.
- G apprécie ouvertement et ouvertement le gagnant pour son bon travail. Dans le même ordre d'idées, très doucement et tactiquement, critiquez le travail et non la personne pour des torts, à la personne responsable, isolée et non ouverte.
- E n encouragez l'appropriation et le leadership de chaque individu. Cela renforce le moral et l'engagement de la personne, car elle se sentirait respectée.
- R jongle avec votre équipe de temps en temps. Celui-ci induit/augmente le lien au sein des membres de l'équipe.
Je vous souhaite bonne chance dans vos efforts sincères :)
En général, les gars dans les tranchées commencent à se sentir mutinés lorsqu'ils sentent que leurs rancunes ne sont pas entendues par des gens qui peuvent et vont régler les situations. Quand ils ne se sentent même pas capables de se plaindre sans risquer leur statut dans l'entreprise, c'est encore pire.
Je suis un peu le type de Theory-Y, et la plupart des "travailleurs du savoir" ont tendance à l'être; Si nous avons une chance, nous aimons notre travail et voulons bien le faire. Cependant, l'inconvénient d'un lieu de travail Theory-Y est qu'il ne peut pas être immédiatement évident qu'il y a un problème, parce que les gens, qui veulent bien faire et donc ne veulent pas faire de vagues, trouveront des moyens de contourner ce problème, ou l'ignoreront simplement. Cela conduit à une frustration refoulée, qui finit par exploser au visage de toute l'équipe. Un magasin géré par un manager de Theory-X aurait probablement des gars qui se plaindraient beaucoup plus tôt; les employés ne sont là que pour l'argent, donc si le travail aspire plus que d'habitude, ils se plaindront.
Quant à ce que vous pouvez faire, dans un environnement avec des seniors et des leads dans la salle qui font le travail, ils sont votre meilleur atout. Parlez-leur. Vous pouvez planifier 30 minutes par semaine pour les "deux voies", où les prospects vous donnent des mises à jour et des préoccupations concernant le quotidien du projet, et vous leur donnez des mises à jour du côté commercial et planifiez avec eux pour résoudre les problèmes avant qu'ils ne deviennent des problèmes qui affectent sérieusement l'équipe.
En Agile, à la fin de chaque "sprint" ou "itération" (qui est une unité de travail de développement qui dure généralement entre une et trois semaines), toute l'équipe, des membres les plus juniors jusqu'au PM, a une "rétrospective" ". Ils regardent en arrière ce qu'ils ont fait, ce qui s'est bien passé, ce qui n'a pas fonctionné, et identifient les choses à continuer à faire et les choses à changer. Il existe plusieurs formats, et vous pouvez inventer le vôtre, mais le résultat du rétro devrait être que les gens sentent que leur voix a été entendue et que les choses vont changer en conséquence.
Parler d'Agile; mon premier emploi était pour une petite entreprise, et par "petite" je veux dire que toute l'entreprise ne pouvait pas aligner une équipe de softball. Il y avait quatre programmeurs quand j'ai commencé, et cela a diminué à deux avant mon départ. Le fondateur, président, chef de la direction et actionnaire à 95% de l'entreprise l'a dirigée avec une poigne de fer, et il était la seule source de planification dans l'organisation, ce qui signifie qu'il n'y avait pas grand-chose. Le Boss était un bourreau de travail et s'attendait à ce que tout le monde le soit aussi; Tout ce que vous aviez à donner n'était ni plus ni moins que son attente, et pour cela, il a payé un salaire d'entrée de gamme à des personnes qui avaient travaillé pour lui pendant une décennie.
J'ai quitté cette entreprise et j'ai commencé à travailler pour une autre entreprise qui faisait les choses TRÈS différemment; ils ont pratiqué la méthodologie de base SCRUM Agile, avec des standups quotidiens, la programmation de paires, des équipes de sprint et des rétrospectives. Pendant une journée toutes les deux semaines au début de chaque sprint, nous n'avons fait que planifier les deux semaines de travail suivantes. Pour une grande partie d'un autre jour, nous n'avons rien fait d'autre que de revenir sur ce que nous avions fait et de trouver des moyens de nous améliorer en équipe. Il y avait des développeurs assis à côté de moi qui étaient des MVP Microsoft, faisant le travail, encourageant et complétant ce que je faisais.
Nuit. Et. Journée. La principale différence? Premièrement, je n'avais pas l'impression que je devais me suicider pour le projet; un principe fondamental d'Agile est le rythme de développement durable. Deuxièmement, j'avais une voix pour décider de la façon dont je devrais faire mon travail. Je devais faire le travail, mais si j'avais des "brûlures d'estomac" sur ce que j'allais attendre au prochain sprint, je pourrais exprimer cette opinion et elle serait entendue et recevrait du poids. Si je sentais qu'il y avait une meilleure façon, je pourrais le dire et ce serait divertissant.
En ce qui concerne la recherche de solutions et la résolution de problèmes, vous devez faire attention à ne pas avoir l'air de travailler de haut en bas. Pour les ordinateurs; disons que votre RMR (revenu mensuel récurrent) permet uniquement à l'entreprise de mettre à niveau quatre ordinateurs toutes les deux semaines. Les quatre premiers ordinateurs ne doivent pas tous aller aux leads et aux seniors; ils devraient s'adresser aux personnes possédant les ordinateurs les plus lents. Si vous donnez des bonus à l'équipe, ne les donnez pas seulement à "nos précieux seniors et prospects, sans qui cela n'aurait pas été possible"; TOUT LE MONDE dans votre équipe de développement a réussi. Si un junior a une plainte, écoutez-le; ce n'est pas parce qu'il est junior qu'il ne sait rien.
Amélioration des relations:
Vous venez d'avoir un projet difficile? Donnez-leur une pause après. Le temps des vacances pour se détendre, reprendre son souffle.
Charte des droits des codeurs Ces choses sont une évidence. Des choses de base qui devraient aller de soi. Si vous les violez, vous abusez de vos clés de code.
Le test Joel Je suis d'accord avec la plupart d'entre eux. Mais certains dépendent vraiment. Si vous en manquez, vous rendez probablement la vie à vos programmeurs plus difficile que ce ne doit être.
Dette technique . Vous pouvez donc pousser pour l'achèvement, mais vous devez réaliser qu'en coupant les coins, encourir une dette technique qui prendra plus de temps à une date ultérieure pour la réparer. Si cette date arrive AVANT la fin du projet, vous avez vraiment foiré.
RSA animate: Motivation C'est un morceau fantastique qui montre vraiment comment motiver les travailleurs du savoir.
Journée libre pour coder ce qu'ils veulent. À partir de la vidéo RSA. Je ne me souviens pas du nom, mais l'entreprise qu'elle mentionne en a une courte explication sur son site. Cela me semble une bonne idée. Dans la plupart des magasins, il y a des choses que tout le monde sait, mais personne n'a le temps de réparer et ce n'est pas une priorité. Cela leur permet de s'attaquer à la dette technique. Cela leur permet également de montrer leurs idées brillantes.
Et pour l'amour de Dieu, essayez de garder une semaine de travail de 40 heures. Aussi, flextime. Flextime peut compenser tout un monde de conneries. Pour moi au moins.
Amélioration de la communication entre les programmeurs et les patrons
C'est plus difficile pour moi. Toute cette chose shmoozing est plus un ensemble de compétences de boss que le focus d'un programmeur. Je pourrais dire que certaines choses fondamentales comme les estimations de temps ne sont que des estimations. Marcher sur l'eau et satisfaire aux exigences est facile s'ils sont gelés. Peut-être demander aux programmeurs timides de faire une présentation de leur projet lors d'une révision de code ou quelque chose. La pratique rend parfait, hein? Mais je m'inclinerais devant les conseils des autres sur celui-ci.
"De même, si vous détestez, veuillez expliquer en détail pourquoi."
Eh bien, cela va ouvrir les vannes ici. Et si je n'utilisais pas un identifiant ouvert qui pourrait évidemment être lié à moi, je m'exposerais probablement aussi. Si vous voulez vraiment une liste géante de ce qu'il ne faut pas faire, demandez sur un forum plus convivial pour les publications anonymes.
J'ai toujours trouvé que les gens en général ne vous traiteront pas mieux que vous ne les traitez (bien qu'ils puissent vous traiter plus mal). Personnellement (je suis développeur), je réponds à l'honnêteté avec honnêteté, au respect avec respect, à la confiance avec confiance, etc. Vous devriez avoir une conversation informelle avec votre équipe dans une atmosphère neutre et leur dire ce que vous venez de nous dire. Le point qui est oublié dans les environnements toxiques "nous contre eux" est que ce devrait être tous "nous". La direction et les travailleurs doivent le savoir, et l'entreprise doit le soutenir.
Bonne chance.
Vous avez désormais la preuve non seulement d'accepter les commentaires, mais aussi d'agir en conséquence. Vous avez démontré que vous avez de l'influence auprès des décideurs supérieurs et que vous pouvez faire avancer les choses pour votre équipe. Cela fait une grosse différence. Les programmeurs peuvent être plus introvertis, mais nous aimons parler de programmation. Un environnement informel est agréable, mais tout le monde doit encore être professionnel. Laissez les gens en évacuer certains, mais assurez-vous que les discussions sont productives et pas seulement une séance de salope.
D'après mon expérience, le facteur le plus important pour moi d'aimer ou de ne pas aimer mon manager est s'il comprend le développement en général et comprend le travail que je fais. Quelques résultats positifs sont répertoriés ici:
- Je n'ai pas à perdre trop de temps pour justifier pourquoi un changement prendrait si longtemps ou ne peut pas être mis en œuvre. Eh bien, techniquement, tout changement peut être mis en œuvre et la haute direction exige généralement la mise en œuvre de toute façon. Mais au moins dans une telle situation, votre manager direct est de votre côté, demandant plus de temps (au lieu de vous pousser ou de vous épuiser).
- Je sais que j'ai une meilleure chance d'être pris en charge en cas de mauvaise situation (un hack WTF, un problème de production, etc.). Habituellement, une personne non technique a tendance à blâmer le développeur pour une telle situation tandis qu'un bon gestionnaire COMPREND ce qui se passe réellement et soutient son développeur (pas seulement savoir ou vouloir le prendre comme étant Nice).
- Je sais que mon travail et mes performances doivent être évalués par une personne appropriée.
À mon avis, si vous ne faites plus de programmation et généralement avec un calendrier ou un budget de projet serré, la chance pour vos développeurs d'aimer est très faible. Si tel est le cas, vous feriez mieux de monter rapidement et d'avoir quelqu'un d'autre pour être le gestionnaire direct. Désolé, je sonnais mal dans ce paragraphe, mais c'est ainsi que je le vois. Vous semblez être une bonne personne et mérite une certaine vérité.
Je crois qu'avec le bonheur des développeurs, la productivité se résume aux petites choses. Le calcul fonctionne plutôt bien pour la gestion. Donnez-moi un beignet (-25 cents) le matin et je travaillerai deux fois plus dur toute la journée (+ plusieurs dollars). Ce n'est pas que nous sabatons activement les choses en travaillant lentement lorsque nous sommes insatisfaits, c'est que nous travaillons sur des systèmes extrêmement compliqués et il est extrêmement difficile de se concentrer lorsque nous sommes frustrés par quelque chose. Il vaut vraiment mieux que nous ne codions pas autant quand nous sommes en colère.
Cependant, les estimations doivent être traitées par elles-mêmes. Chaque problème que j'ai peut être résolu en me remettant un beignet, à l'exception des estimations irréalistes. Vrai ou faux, voici comment un développeur le voit: la direction a tout à gagner (comme un nouveau bateau) par une estimation plus courte, tandis que les développeurs ont tout à perdre (comme un mois de sommeil). La direction est cependant en charge, donc ils gagnent la guerre d'estimation à chaque fois. Je pense que le système d'estimation fonctionne mieux lorsque les développeurs décident de la date limite (il est assez difficile pour nous de donner une estimation précise, alors comment serait un gestionnaire?), Mais la direction les motive positivement à être ambitieux, étant entendu qu'aucun développeur ne se voit être un peu décalé.
Je suis aussi l'un des gars en costume, depuis plus de 15 ans. J'étais développeur de logiciels quand j'ai commencé, et j'écris toujours du code quand j'en ai l'occasion. Je pense donc pouvoir parler des deux côtés et j'ai un peu d'expérience dans ces situations. J'ai également des titres de compétences, tels que "Employé de l'année", élu par le personnel, qui me rendent confiant dans la gestion de ces situations.
Ce que je constate très souvent, c'est qu'il existe des différences substantielles dans les systèmes de valeurs et les méthodes/approches opérationnelles adoptées entre la direction et les développeurs.
Pour beaucoup de développeurs, la sincérité, l'honnêteté et sinon un environnement de travail flexible sont très élevés sur la liste. Malheureusement, les mêmes valeurs ne sont pas très élevées sur la liste des cadres supérieurs. Et cela conduit inévitablement à d'énormes affrontements, en particulier si les cadres intermédiaires (vous et moi) décident de prendre complètement le côté de la haute direction. La seule issue à cela (de mon point de vue) est de prendre une position ferme devant votre équipe, de les soutenir tout le long et de bâtir une relation de confiance par une communication ouverte et, surtout, en faisant ce que vous dites (ce qui est souvent l'opposé de ce que vous obtenez de la haute direction, où la politique domine complètement la sincérité).
Dans le même temps, vous devez vous-même rester opérationnel, vous devez donc trouver un moyen de communiquer avec la direction dans une langue qu'ils comprennent et jouent leur jeu. C'est le vrai défi de la gestion intermédiaire.
Considérez quel type de réaction donnez-vous à un programmeur qui peut avoir une question, un commentaire ou une préoccupation. Y a-t-il un "Que voulez-vous maintenant ?" ou "Pourquoi me dérangez-vous avec ce ?" une sorte de réponse? Dans quelle mesure êtes-vous capable d'encourager les développeurs à exprimer leurs préoccupations et leurs commentaires? Mais ce n'est qu'un point de départ.
Deuxièmement, faites attention à l'endroit où vous essayez d'avoir ces discussions. Je doute que je serais très ouvert à discuter de ma machine de travail avec quelqu'un dans le cube suivant si je savais que mon manager était à portée de voix pour entendre le tout. Si vous voulez que les gens donnent des commentaires ouverts et honnêtes, il faut veiller à ce que leurs réponses ne soient pas diffusées publiquement ou utilisées contre eux.
Troisièmement, considérez quel type de Intelligence émotionnelle compétences avez-vous. Intelligence émotionnelle pour les chefs de projet: les compétences humaines dont vous avez besoin pour obtenir des résultats exceptionnels par Anthony Mersino serait une recommandation de livre que j'ai reçue hier d'un déjeuner et en savoir plus sur l'égalisation. Si vous voulez vraiment approfondir la psychologie ici, il existe différents outils de profil de personnalité qui pourraient être utilisés, par exemple. Ennéagramme, styles sociaux et MBTI.
Enfin, réfléchissez à la culture de votre entreprise. Les erreurs sont-elles quelque chose balayées sous le tapis? Les plaintes sont-elles un grand non-non qui pourraient causer des problèmes à quelqu'un très facilement? Quels comportements sont récompensés ou encouragés et lesquels sont tolérés et acceptés? Bien que certaines de ces observations soient des observations, certaines d'entre elles peuvent également nécessiter des conversations qui devraient avoir lieu soit loin du bureau, soit dans une pièce où il n'y a probablement pas d'écoute. Vous serez probablement répétitif en essayant de l'utiliser au début. Ce n'est pas une mauvaise chose si vous essayez d'établir une nouvelle pratique et de faire participer les gens à la prise de parole si la culture était principalement celle où tout le monde savait juste "aspirer". Cela peut être plus délicat que d'autres réponses, mais ce serait ce que je donnerais pour une réponse si on me demandait où je travaillais.
En tant que développeur, je suis un nerd majeur et manque de compétences sociales et je ne m'en excuse pas. Après tout, je suis le talent, et vous m'avez engagé pour mon talent. Si vous aviez besoin de papillons sociaux pour faire le travail, vous auriez une salle pleine de chefs de projet au lieu de développeurs.
Je sais que certains développeurs sont très astucieux socialement, mais je pense que la médiane penche vers un nerd introverti.
Lorsque quelqu'un me demande de faire quelque chose, je ne fais absolument aucune inférence et je fais exactement ce qui est demandé. Il semble qu'avec certains chefs de projet, je me retrouve toujours avec des problèmes parce qu'ils s'attendent à ce que je fasse des inférences sur leur projet, ce que je ne ferai absolument pas, donc parfois les choses ne se passent pas comme elles le pensent, même si elles se révèlent être exactement ce que ils ont demandé. Je pense que la raison pour laquelle cela se produit avec certains chefs de projet est qu'ils ne fournissent pas de DLD, de BRD de haute qualité et accordent trop de valeur à l'aspect social de la gestion de projet plutôt qu'à ce qui est en noir et blanc.
Je pense que c'est là que les mondes entrent en collision. Je pense que dans le monde de la gestion de projet, les compétences sociales et la qualité de la franchise personnelle sont des facteurs importants, mais pour les développeurs comme moi, cela ne signifie absolument rien. Cela ne m'impressionne pas de dire à quel point telle ou telle tâche est importante. Je ne veux même pas sortir pour le déjeuner ou les bières comme certains l'ont suggéré.
Ce que je veux vraiment, ce sont de bons DLD et BRD de haute qualité. Je veux que les calendriers et les délais soient réalisables, et si de nouveaux modèles ou plans sont introduits, je veux que le calendrier et les délais soient réajustés. J'ai travaillé sur des projets où les exigences semblent changer à la volée - pour moi, c'est mon drapeau rouge que je traite avec un leadership de projet de mauvaise qualité. En tant que développeur, la pire chose que vous puissiez faire est de m'apporter de nouvelles exigences de projet au quotidien, surtout après que nous ayons déjà un calendrier ou que nous ayons pris des engagements de calendrier. C'est intolérable lorsque de nouvelles exigences sont introduites, sans compensation dans les délais. Travailler plus d'heures, travailler tard, je n'ai aucun problème avec ça, mais ce n'est pas quelque chose qui est toujours quantitatif avec le développement. Certains changements peuvent prendre quelques heures supplémentaires, certains changements peuvent prendre des semaines pour une recherche et un développement appropriés, des tests, un contrôle qualité, etc. Ce n'est pas toujours comme faire un gâteau, parfois un seul changement aux exigences peut être comme changer la recette entière. J'ai vu des chefs de projet fondre et avoir des crises de colère lors des conférences téléphoniques parce que leurs délais ne permettent pas le développement supplémentaire, mais ils demandent un développement qui n'était pas dans les exigences initiales de leur projet.
Je ne peux que donner mon parti pris et mon expérience personnels à titre d'exemple, alors s'il vous plaît, ne déduisez pas que je parle au nom de tous les développeurs. Je ne vois ces choses qu'à travers le microcosme de ma propre carrière, mais ce post décrit les conditions exactes qui m'ont fait jeter l'éponge proverbiale.
Les développeurs estiment-ils que vous êtes leur défenseur? J'entends par là qu'ils savent qu'ils sont libres de partager avec vous leurs préoccupations/frustrations sans être battus? Sentent-ils que vous vous battez pour eux? Sentent-ils que vous appréciez leur travail? Sentent-ils que vous voulez vraiment qu'ils réussissent dans leur carrière?
S'ils se sentent appréciés, vous aurez probablement une meilleure communication.
Court et doux. Excel dans ce que vous faites - cela engendrera la communication.
Que signifie exceller pour vos développeurs? .. Lire, relire, oui même étudier PeopleWare
À quelle fréquence parlez-vous à vos développeurs? Je ne parle pas des réunions sur l'état du projet, des questions sur les livrables ou d'autres sujets que vous leur apportez - à quelle fréquence vous asseyez-vous avec l'un de vos programmeurs, leur demandez-vous comment les choses se passent, et écoutez .
Beaucoup d'autres réponses sont vraiment bonnes - vous devriez vous pencher sur le développement agile. Vous avez besoin que vos développeurs apprennent et évoluent dans leurs rôles. Mais si vous n'écoutez pas réellement ce que vos développeurs disent (ou ne disent pas!), Vous devez d'abord vous en occuper.
Bonne référence en tête-à-tête - http://www.randsinrepose.com/archives/2010/09/22/the_update_the_vent_and_the_disaster.html
Juste pour répondre à une recommandation qui a déjà été formulée dans quelques-unsréponses déjà. Michael Lopp (aka rands ) a écrit sur la gestion des développeurs et "se mettre dans la tête" sur son blog, Rands in Repose , et dans un livre, Gestion des humains ( sources du livre ). Le livre contient principalement du contenu édité de ses publications avant 2007 et fournit un bon moyen de rattraper les parties liées à la gestion de son blog (il parle également, par exemple, des jeux de hasard, et si vous voulez lire c'est une autre question). Son écriture est généralement géniale et souvent humoristique, donc il y a peu de risques à le lire.
Je suis en retard à la fête, mais je viens de voir cette question.
Une chose que je ne vois pas très bien abordée est la suivante:
Les grognements ne disent jamais toute la vérité aux costumes. Rands le dit dans ADN mais ne l'aborde pas de front, il est sur un sujet différent.
Vous portez un costume et vous signez les chèques. Vous représentez l'intérêt de l'entreprise. Vous ne représentez pas les ingénieurs. Si vous l'avez fait, vous ne signeriez pas leurs chèques, ils le feraient signeriez les vôtres.
Ce n'est bien sûr pas une nouvelle pour vous ou les ingénieurs. Mais lorsqu'un ingénieur sait que le fait de soulever certains problèmes - des problèmes - avec son lieu de travail entraînerait un conflit important - le compromis risque/récompense ne favorise pas l'ingénieur. Les ingénieurs sont payés pour produire des produits et non pour lancer des combats de culture en milieu de travail. S'impliquer dans ceux-ci est un moyen rapide de mal faire le travail.
Ainsi, une partie de la tâche de gestion consiste à fournir aux ingénieurs un moyen d'être ouvert sur les problèmes, sans encourir de politique d'entreprise ni de retour de carrière. C'est agréable d'avoir des augmentations, après tout, et il y a sont d'autres entreprises, si celle-ci ne se sent pas sympathique.
Sortez l'équipe pour la bière (et vous achetez).
Toutes les bonnes idées et commentaires dans les articles ci-dessus!
Voici une idée: envoyez votre I.T. le personnel aux ateliers de communication de votre collège communautaire local - payés par l'entreprise, bien sûr.
Assurez-vous a) que les ateliers ont une bonne réputation, et b) de ne pas envoyer vos employés ensemble. Ils auront tendance à rester ensemble et à ne pas se mêler aux autres membres de la classe, non seulement en réduisant la valeur des ateliers, mais en perturbant les autres.
La communication productive axée sur l'équipe est une compétence que tout le monde peut apprendre, mais c'est un sujet qui me semble manquer dans la plupart des parcours scolaires.
Cette idée n'est en aucun cas une balle magique, mais c'est une bonne pièce de base du puzzle. Non seulement vos associés apprendront à mieux communiquer entre eux, mais le bonus sera qu'ils commenceront également à mieux comprendre et respecter VOTRE travail (la communication étant au cœur de PM).
Juste mes 2 bits :)
Je suis surpris que personne n'ait mentionné ce grand livre qui traite exactement de votre question et de votre sujet - "Peopleware: Projets et équipes productifs" par DeMarco et Lister . Extrait de l'éditorial: les problèmes majeurs du développement logiciel sont humains, pas techniques . Les trois premières critiques sur Amazon seraient facilement suffisantes pour me convaincre d'acheter ce livre si j'étais dans votre situation.
J'ai occupé divers postes au cours de nombreuses années - développeur, développeur senior, responsable technique, etc.
D'après votre question - il est assez évident que vos développeurs ne vous disent rien parce qu'ils ne pensent pas que vous pouvez aider.
Cela peut être dû à 2 raisons.
- Ils ne pensent pas que vous ayez le pouvoir de réparer les choses. Cependant, je pense que cela est peu probable car vous le sauriez probablement et les développeurs se seraient également lamentés à ce sujet.
- Vous êtes le genre de personne qui, lorsqu'un développeur vous présente un problème, fait une ou plusieurs des choses suivantes
- Quand ils viennent à vous avec des problèmes, vous leur dites - j'aime les solutions et non les problèmes.
- Vous les écoutez bien et vous leur demandez ensuite de résoudre le problème. Vous leur donnez du courage pour dire quel honneur c'est pour eux de se voir confier la responsabilité de régler le problème. Au fil du temps, vos gars comprennent que lorsqu'ils vont vers vous avec un problème, ils se retrouveront avec du travail supplémentaire, donc ils ne viennent pas vers vous avec des problèmes.
- Vous niez que c'est un problème. Vous en donnez des raisons convaincantes. Mais comme cela continue de se produire, au fil du temps, vos gars apprennent qu'il est inutile de vous approcher d'un problème.
- Vous dites "oui, je comprends". Vous dites que ce genre de choses se produit de temps en temps et qu'il n'y a rien à faire. Si c'est un modèle, vos gars le comprennent à nouveau.
Si c'est tout ou partie de ce qui précède, vous devez le rectifier.
Beaucoup de réponses ici ont de très bons points, mais je voudrais juste ajouter quelques ressources qui pourraient aider. J'ai été dans quelques situations qui se sont effondrées sur elles-mêmes dans un gâchis géant ou ont été résolues très efficacement en raison de la communication entre les personnes impliquées. Trois livres m'ont aidé à améliorer personnellement mes compétences en communication, en particulier dans les situations de stress élevé où il y a beaucoup à faire:
- Conversations difficiles: comment discuter de ce qui compte le plus
- Conversations cruciales: outils pour parler lorsque les enjeux sont élevés
- Confrontations cruciales: outils pour résoudre les promesses non tenues, les attentes violées et les mauvais comportements
À la lecture de votre question, je pense que vous voyez la valeur de la communication. Je pense personnellement que la communication est plus importante pour un manager ou un leader que les compétences commerciales ou techniques. Les personnes que vous dirigez devraient avoir les compétences dont vous avez besoin pour réaliser la majorité du projet. Un bon chef technique ou chef de projet doit pouvoir se concentrer sur la communication, que ce soit au sein de l'équipe ou entre l'équipe et le client ou l'équipe et l'entité commerciale (ou même une combinaison de ces trois).
Lisez quelques grands romans qui donnent un aperçu des perspectives de la main-d'œuvre technique:
- Hackers, Steven Levy - http://en.wikipedia.org/wiki/Steven_Levy
- Microserfs, Douglas Coupland - http://en.wikipedia.org/wiki/Douglas_Coupland
- Cathédrale et le bazar, Eric Raymond - http://en.wikipedia.org/wiki/Cathedral_and_the_Bazaar
Celles-ci sont aussi importantes que tout mémoire typique sur la gestion (Drucker et al).