Question:
Comment puis-je gérer le jeu de blâme joué par mon collègue au bureau?
TheHungryCoder
2018-06-14 19:11:26 UTC
view on stackexchange narkive permalink

Mon collègue (appelle-le Bob) et moi sommes des développeurs de logiciels avec une expérience d'un an. Notre CTO me considère plus intelligent que lui. Ces derniers mois, nous travaillons tous les deux sur la même technologie.

Désormais, chaque fois que Bob fait face à un problème, notre directeur technique suggère de me consulter. De 80 à 90% du temps, je suis en mesure de résoudre son problème et j'informe le directeur technique que j'ai fourni la solution à Bob.

Maintenant, il est arrivé plus de 10 fois que Bob a implémenté la solution fournie par moi de manière incorrecte et il se rend immédiatement à notre CTO en lui disant que la solution fournie par moi est soit incorrecte, soit ne fonctionne pas.

En l'écoutant, le CTO se met toujours en colère contre moi et me réprimande fermement chacun temps. Des incidents comme ceux-ci ont créé une très mauvaise impression de moi dans son esprit que je ne fais pas mon travail correctement la première fois et que je ne fais le bon travail qu'après 5-6 répétitions et améliorations.

compassion pour Bob, je n'ai jamais dit à notre CTO qu'il implémentait souvent ma solution de manière incorrecte. Si je lui parle de l'inefficacité de Bob, alors Bob pourrait être renvoyé.

C'est pourquoi je reste toujours silencieux lorsque Bob commet des erreurs lors de la mise en œuvre de ma solution. Mais le niveau de ma patience a atteint ses limites maintenant et je pense qu'il est temps de trouver une solution qui pourrait donner une leçon à Bob.

Bien que j'aie parlé à Bob de la même chose dans le passé et qu'il dit qu'il comprend, il continue de faire les mêmes erreurs encore et encore.

Maintenant, je ne veux pas me venger de Bob mais je veux une solution dans laquelle je peux rester à l'écart de ce jeu de blâme joué par Bob, ce qui fait que le CTO ne lui fait rien mais affecte beaucoup ma réputation.

Quelqu'un peut-il suggérer quelle serait une bonne stratégie pour faire face à cette situation?

Les commentaires ne sont pas destinés à une discussion approfondie;cette conversation a été [déplacée vers le chat] (https://chat.stackexchange.com/rooms/78923/discussion-on-question-by-dg4-how-can-i-deal-with-the-blame-game-joué-par-mon-co).
Avez-vous essayé de lui demander de vous consulter avant de vous rendre au CTO?
Pourquoi pensez-vous que dire au CTO * "Je devais aider Bob avec X, il faisait A et je lui ai dit de faire B" * est OK, mais dire au CTO * "Je devais aider Bob avec X à nouveau parce qu'ila fait C, au lieu de B comme je lui ai dit "* n'est pas OK?
Ce n'est pas un jeu de blâme.Le titre devra peut-être changer.
Sept réponses:
dwizum
2018-06-14 19:39:47 UTC
view on stackexchange narkive permalink

Je pense que @Neo a fourni une réponse solide en ce qui concerne la documentation et la concentration sur les faits, mais je pense aussi que vous pouvez aller plus loin. Documenter / souligner simplement que les implémentations de Bob ne fonctionnent pas peut vous aider à vous protéger, mais cela ne résout pas le problème ultime (le code de Bob est cassé).

En gros, vous avez l'opportunité de soutenir Bob et transformez cela en une expérience d'apprentissage pour vous deux.

Votre patron vous a demandé d'aider Bob lorsqu'il vous demande de l'aide. En fin de compte, cela signifie que aider Bob fait partie de votre travail. Vous lui offrez des solutions et ses implémentations ne fonctionnent pas. Dans une certaine mesure, vous avez la responsabilité de l'aider à réussir. Il y a plusieurs choses que vous pouvez faire pour remédier à la situation:

  1. Avant de donner une solution à Bob, assurez-vous de comprendre le vrai problème. Souvent, des programmeurs moins talentueux concentrez-vous sur un symptôme et non sur le problème racine. S'il vous donne un symptôme à résoudre, assurez-vous que vous êtes tous les deux d'accord sur la cause première avant de discuter d'une solution.
  2. Une fois que vous avez une solution en tête, assurez-vous que vous " vous le lui donnez d'une manière qui l'aide à réussir. S'il est moins compétent que vous, vous pouvez prendre pour acquis des choses dont il ne sait rien - comment créer ou déployer la solution, comment le configurer ou le tester, etc. Assurez-vous que vos instructions sont explicites et complètes. Cela lui permettra de réussir au lieu de devoir échouer encore et encore avant de tomber sur le correctif réel.
  3. Après avoir essayé votre idée, aidez-le activement à la tester avant qu'il n'ait une chance pour vous plaindre que ce n'est pas correct. Cela vous donnera l'occasion de "détecter" tout problème avant qu'il ne puisse dire au CTO que votre solution est une poubelle. Cette étape peut inclure une révision du code ou une autre révision de la mise en œuvre, mais elle doit au minimum inclure la vérification que le problème réel a été résolu.
  4. En post-mortem, une fois que la solution est enfin en place et fonctionne, passez en revue l'ensemble du processus avec Bob. Passez en revue ce qui a fonctionné et ce qui n'a pas fonctionné pendant la mise en œuvre. Documentez les raisons pour lesquelles vous avez dû essayer cinq ou six fois avant que tout fonctionne. Documentez votre solution et pourquoi vous l'avez choisie. La prochaine fois qu'il vous demandera de l'aide, vous pourrez commencer par examiner la ou les dernières solutions - cela vous aidera tous les deux à éviter de tomber sans cesse dans les mêmes problèmes.

Tout cela peut sembler beaucoup de travail , mais en général, à long terme, il est plus facile / préférable de faire les choses «correctement» de manière à aider les gens à tirer des leçons de leurs erreurs, plutôt que de simplement gifler solution la plus rapide / la plus simple. Pour résumer: Si vous êtes invité à aider quelqu'un, vous devez vous assurer que votre aide est réellement utile, plutôt que de simplement jeter une idée sur ses genoux et de passer à autre chose.

+1 à cela, bien que vous devriez inclure la révision du code de l'implémentation de Bob à 3 ou entre 2 et 3.
Bon point, je vais le modifier.
Toutes ces solutions sont des solutions au problème fondamental, à savoir que l'OP ne communique pas efficacement ... soit avec Bob, le CTO ou probablement les deux.
J'aimerais pouvoir voter plus d'une fois.Prendre le temps d'enseigner correctement la solution permet d'économiser du temps et du chagrin à l'avenir.
Si OP a ce niveau de responsabilité pour superviser le travail de Bob, ils sont effectivement le superviseur de Bob ... et cela devrait être précisé par le CTO à Bob et OP.Si OP essaie de gérer le travail de Bob sans clarifier cela au préalable, il y a de fortes chances que cela suscite du ressentiment.
@AllTheKingsHorses ne sais pas si je suis à 100% d'accord.Il y a une différence entre être explicitement chargé d'une personne en tant que superviseur et être invité à l'aider à résoudre ses problèmes.Je pense que même dans ce dernier cas, l '«assistant» est responsable de l'application correcte de la solution, même s'il n'est pas explicitement le superviseur de l'autre membre du personnel.En d'autres termes, ** si on vous demande d'aider quelqu'un, vous devez vous assurer que votre aide est réellement utile ** plutôt que de simplement jeter une idée sur ses genoux et de passer à l'étape suivante.
Le fait que le CTO soit manifestement contrarié par le PO à cause des échecs répétés de Bob me donne l'impression qu'il est évident que le PO devrait étendre ses efforts pour être plus approfondi et utile - d'où la réponse.Bien sûr, à votre avis, cela ne fait pas de mal de clarifier les orientations du CTO - mais il est peut-être un peu tard pour cela, car il semble que ce schéma se soit déjà répété plusieurs fois et que les sentiments du CTO soient assez bien connus.
@dwizum À mon avis, il est de la responsabilité de Bob d'accomplir ses tâches correctement.Il devrait obtenir un soutien utile des autres employés (y compris OP) - mais finalement c'est sur lui.Mais au lieu d'utiliser toutes les ressources disponibles (y compris OP) pour accomplir efficacement ses tâches, Bob court vers le CTO et se plaint.Donc quelque chose cloche.Soit les tâches de Bob ne sont pas vraiment celles de Bob, soit Bob ne s'en soucie pas, soit OP est censé superviser sans qu'on le lui dise, soit le CTO est trop occupé / paresseux / quoi que ce soit pour gérer leurs rapports ou * quelque chose *.Les attentes ne correspondent pas ici ...
Je suis d'accord ... regardez l'exemple comme si c'était autre chose que la programmation.Si vous étiez tous les deux des maçons qui posaient des briques pour les murs ... et que Bob a besoin d'instructions constantes pour faire le bon travail, la responsabilité vous incombera toujours en tant que «superviseur».Peu importe qui a réellement posé la brique ou mal mélangé le mortier, ce qui compte, c'est que le travail soit mal fait et qu'il doive être refait.
"Assurez-vous que vos instructions sont explicites et complètes."C'est fondamentalement impossible.Avec la technologie, il n'est généralement pas possible de prévoir tous les facteurs possibles qui pourraient avoir un impact sur votre solution.Toute solution que vous suggérez sans la mettre en œuvre vous-même sera toujours une meilleure estimation.
Gagnez un rôle de supervision officiel sur Bob.Assurez-vous que vos responsabilités globales reflètent la charge de travail associée, afin que ce ne soit pas quelque chose qui prend du temps non budgété.Notez que cela nécessite l'approbation de la direction, donc peut ne pas être facile à trouver rapidement.Cependant, ce qui peut être facile, c'est d'établir une règle selon laquelle si l'implémentation ne fonctionne pas, Bob doit venir vers * vous * ** en premier *.Cela réduira les plaintes que le CTO doit traiter (le CTO devrait donc aimer ça), et si Bob se plaint au CTO, vous pouvez signaler la violation de cette règle simple.C'est facile et vous sauve, sans attaquer les compétences de codage racine de Bob
Version TLDR;imposez la programmation par paires et la révision du code jusqu'à ce que vous soyez satisfait que Bob fasse les choses correctement à l'avenir.
Neo
2018-06-14 19:26:39 UTC
view on stackexchange narkive permalink

Quelqu'un peut-il me suggérer quelle serait une bonne stratégie pour faire face à cette situation?

Document, document, document .

Chaque fois que vous devez nettoyer le désordre de Bob, documentez-le et copiez le CTO. Cela peut ne pas sembler la meilleure chose à faire mais à ce stade, je serais un peu plus préoccupé par ma réputation dans l'entreprise et en particulier l'impression que le directeur technique a de vous puisque vous semblez être celui le CTO est en colère contre.

N'oubliez pas que lorsque vous documentez ce type d'activité, faites seulement rapporter les faits. Pas besoin d'embellir, le CTO peut mettre 2 + 2 ensemble. Ce faisant, il verra rapidement qui ajoute le plus de valeur et qui fait le plus «parler».

Ce n'est pas une chose agréable à faire, mais je ne vois pas d'autre moyen efficace de traiter avec.

Et par tous les moyens CO le CTO.N'utilisez pas CCO dans ce cas.Vous voulez que BOB sache que le patron écoute.
@Mindwin: Je suppose que CO = CC et CCO = BCC?(Google suggère que ce sont les abréviations espagnoles correspondantes pour CC et BCC.)
Rien ne gagnera le CTO plus rapidement qu'une grille avec 2 colonnes et lignes montrant les étapes que vous avez recommandées et les étapes que Bob a réellement effectuées (ainsi que les résultats des actions incorrectes).
@V2Blast - En espagnol CC = CC (** Copia de Carbón **), BCC = CCO (** Copia de Carbón Oculta **).Je ne sais pas que * CO * fait référence à ... qui ressemble à une faute de frappe.
JimmyJames
2018-06-14 21:38:24 UTC
view on stackexchange narkive permalink

Maintenant, chaque fois qu'il fait face à un problème, notre CTO suggère qu'il devrait me consulter. 80 à 90% du temps, je suis en mesure de résoudre son problème et j'informe le directeur technique que je lui ai fourni la solution.

...

En l'écoutant, le CTO se fâche toujours contre moi et me réprimande à chaque fois.

Cela ne s'additionne pas vraiment et je pense que cela signifie que vous interprétez mal ce que le CTO est frustré avec vous sur. Je suis d'accord avec l'affirmation de dwizum selon laquelle "aider Bob fait partie de votre travail", mais je voudrais aller plus loin. Vous êtes effectivement le chef de file de Bob. Votre directeur technique ne veut pas simplement donner des conseils à Bob et s'en aller. Il veut que vous preniez la responsabilité de vous assurer que le travail est effectué correctement. La raison pour laquelle je suis assez certain à ce sujet est qu'il continue de diriger Bob vers vous. Si le CTO pensait que vous étiez le problème, il ne le ferait pas.

Pensez-y du point de vue du CTO. Bob entre et dit qu'il a un problème. Le CTO n'a pas le temps pour Bob. Il vous l'envoie pour vous aider. Vous lui donnez de l'aide, Bob ne comprend pas et est de retour sur écoute du CTO. Le directeur technique souhaite simplement que vous traitiez avec Bob et que vous voyiez les choses à travers. Il ne veut pas parler à Bob de ses problèmes. Il veut juste que le travail soit fait.

Je pense que vous devriez avoir une conversation franche avec le directeur technique à propos de cette situation. Fondamentalement, il y a deux chemins ici. 1. Bob est seul. Il réussit ou échoue selon ses propres mérites. 2. Vous êtes propriétaire du résultat et êtes responsable de vous assurer que ce que fait Bob est juste. Le CTO semble vouloir cette dernière option mais ne vous l'a pas clairement communiqué. Si vous et Bob êtes des pairs, c'est peut-être le bon moment pour parler d'une promotion. Si vous êtes un lead, vous devriez au moins être reconnu pour cela et vous attendre à être rémunéré. Je parie que vous êtes déjà mieux rémunéré que Bob.

Il ne faut pas se laisser glisser dans un poste de direction sans rémunération adéquate (pas forcément matérielle / monétaire).
@Mindwin Je suis tout à fait d'accord mais je fais une distinction entre un rôle de chef de file et un rôle de superviseur / gestionnaire comme je pense que la plupart des RH (du moins aux États-Unis) le font.
"Hé, CTO - J'ai remarqué que vous vous fâchez contre moi quand Bob a des problèmes. Suis-je mal compris quelque chose? Vouliez-vous que je fasse plus que lui donner des recommandations? Quelle est votre attente que je ne rencontre pas?"Aucune accusation, et ECOUTEZ la réponse.Ne discutez pas et ne débattez pas.Cette partie vient plus tard.Dans la première discussion, écoutez simplement.
«Il ne faut pas se laisser glisser dans un poste de direction sans rémunération adéquate» - et certainement sans l'autorité appropriée.Vous ne pouvez pas livrer sans l'autorisation de faire votre travail.
Tom W
2018-06-15 15:03:07 UTC
view on stackexchange narkive permalink

Lorsque vous avez passé en revue le travail de Bob, n'avez-vous pas repéré les problèmes? Vous avez effectué une révision du code, n'est-ce pas?

Lorsque le travail de Bob a été testé, les tests n'ont-ils pas identifié les échecs? Vous avez effectué des tests automatisés, n'est-ce pas?

Rien ne passe en production - ni même en test où il peut être vu par n'importe qui en dehors de l'équipe de développement - jusqu'à ce que le code soit examiné . Mettez en œuvre un processus de révision du code et respectez-le . Lorsque Bob fait quelque chose qui n'est pas ce dont vous avez discuté, vous le découvrez dans la révision du code et vous ou lui le retravaillez jusqu'à ce que ce soit acceptable.

Dites également à Bob que même si vous supervisez, vous n'êtes pas responsable de la qualité de son travail; il est. Tout programmeur doit être en mesure d'évaluer de manière critique la qualité de son travail. Vous blâmer pour quelque chose qu'il a mal fait n'est pas professionnel.

À deux reprises, deux ingénieurs ont complètement vaincu le processus de révision du code.
@Joshua "vaincre" le processus?_Pourquoi? _ Ce n'est pas censé être contradictoire.Je peux comprendre que parfois des choses doivent être précipitées en cas d'urgence, mais généralement agir de mauvaise foi comme cela me ferait sérieusement remettre en question l'avenir de quelqu'un dans une entreprise.Que leur est-il arrivé?
"vaincre le processus de révision du code" Qu'est-ce que cela signifie?
@Tom W: Lorsque vous êtes déterminé à enregistrer un code délibérément mauvais, c'est.Nous avons trouvé un cercle de programmeurs qui approuvent les révisions de code sans les avoir réellement effectuées.Le chef de file a été expulsé par "congédiement déguisé".
Will Ware
2018-06-14 23:53:02 UTC
view on stackexchange narkive permalink

Il y a déjà de bonnes idées ici que vous devriez considérer. Voici une autre pensée. Lorsque vous trouvez une solution pour Bob, au lieu de la remettre et d'aller travailler sur d'autres choses, vous pouvez vous asseoir avec Bob et faire une heure ou deux de programmation en binôme avec lui. Cela peut simplement être un moyen de s'assurer qu'il prend un bon départ, ou il se peut que vous arriviez vous-même à une meilleure compréhension du problème.

Les organisations évitent souvent la programmation en binôme parce qu'ils pensent que c'est inutile pour deux ingénieurs de travailler sur le même morceau de code. Mais il y a eu des statistiques indiquant que les économies dans la prévention des bogues l'emportent sur le coût de «perdre» le temps d'un ingénieur. Si vous pensez que vous pourriez faire cela, vous voudrez peut-être consulter la littérature sur la programmation en binôme afin de pouvoir en faire la cause auprès du CTO.

+1 Et j'irais plus loin: vous et Bob pouvez * prendre la responsabilité collective * du problème, coder la solution en utilisant la programmation par paires et soumettre la solution une fois que vous en êtes tous les deux satisfaits.
Little Girl
2018-06-15 07:02:53 UTC
view on stackexchange narkive permalink

Vous avez déjà obtenu d'excellentes réponses ici. J'ai quelques petits ajouts:

Lorsque vous enseignez ou fournissez à Bob des solutions, gardez à l'esprit que nous ne communiquons pas tous ou n'apprenons pas tous de la même manière, donc quelque chose que vous enseignez d'une manière qui vous pensez que ce serait compréhensible pourrait ne pas être compréhensible pour Bob. Un bon moyen de le savoir est de demander à Bob de répéter toutes les instructions ou informations que vous lui avez données dans ses propres mots pour vous assurer qu'il vous a bien compris.

Une autre chose qui pourrait être une bonne idée serait pour impliquer un tiers, de préférence quelqu'un qui peut être impartial ou impartial et agir en tant que médiateur ou conseiller auprès de Bob et de vous. Mieux encore serait que le tiers soit considéré comme l'égal de Bob pour rendre Bob plus à l'aise.

La dynamique du groupe serait très différente de ce que vous et Bob avez quand il n'y a que vous deux. En ce moment, vous êtes le donneur et il est le preneur ou vous êtes l'enseignant et il est l'élève - de toute façon, ce n'est pas une recette de proximité, de lien ou de confort et pourrait même causer une gêne suffisamment forte pour l'empêcher d'écouter fois pendant qu'il est occupé dans sa tête.

Dans un cadre de groupe, il y a une chance pour Bob de s'identifier avec le tiers et même de prendre quelques indices de lui ou d'elle. Cela ouvre la possibilité au tiers de définir des exemples de questions, de paraphraser ce qui a été enseigné ou même de théoriser des façons créatives d'utiliser les connaissances nouvellement acquises pour montrer comment cela peut être utile.

Mes deux cents.

Jonathan Rosenne
2018-06-16 22:14:52 UTC
view on stackexchange narkive permalink

En tant que gestionnaire de niveau C, si cela dure trop longtemps, je vous licencierai tous les deux. Tous les employés de l'entreprise doivent s'engager en tant que groupe à atteindre les objectifs de l'entreprise. Le directeur technique se soucie de la réalisation des objectifs de l'entreprise et il vous a demandé d'aider Bob, alors ce qu'il veut, c'est que vous aidiez Bob et résolvez le problème, et il s'attend à ce que vous puissiez le faire. Il ne se soucie pas de qui est à blâmer. Il est en colère parce que le problème n'a pas été résolu, et au lieu de le résoudre tous les deux, vous perdez son temps avec vos petites querelles. Cela s'applique à vous deux, alors résolvez-le entre vous en tant qu'adultes.

C'est une très mauvaise réponse.Si on me donnait cette position d'un responsable de niveau C, je n'aurais qu'à signaler que je ne peux pas réparer les capacités de Bob.


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 4.0 sous laquelle il est distribué.
Loading...