Comment traiter avec un collègue qui m'a reproché le bug dont il était responsable

Certaines personnes ont tendance à rejeter agressivement la faute sur les autres afin de détourner l'attention d'elles-mêmes. Comme vous êtes également relativement nouveau, cela a dû être très pratique pour lui de faire ce qu'il a fait.

Voici mon conseil. Écrivez un courrier électronique, décrivez le problème, comment vous en êtes arrivé à la cause première, quelle en a été la solution éventuelle et comment on peut l'éviter à l'avenir. Incluez toutes les parties prenantes dans ce courrier.

A la fin de ce courrier, écrivez quelque chose sur ces lignes,

XYZ,

Pouvez-vous ajouter ces étapes dans la documentation appropriée ou le document de procédures opérationnelles standard pour ce code ?

De cette façon, vous ne le “pointez pas du doigt”, mais vous indiquez explicitement qu'il est le propriétaire de ce code et donc responsable de celui-ci. C'est important car tout le monde (surtout les cadres supérieurs) n'ouvrira pas les liens de la base de données pour savoir à qui appartient le code.

Un peu dur, mais il le mérite.

J'ai construit ma carrière en ne jouant pas le jeu des reproches, mais la vérité est que les humains écoutent la voix la plus forte. Cependant, si vous vous engagez dans la défense, il va vous tirer vers le bas à son niveau et vous battre avec l'expérience.

Si vous pouvez en trouver un, il vous faut un champion. Idéalement, ce devrait être votre manager, mais parfois, il s'agit d'un autre développeur très respecté. Il se battra pour vous pour faire taire le plus bruyant. Tout ce que vous avez à faire, c'est d'avoir une discussion privée avec eux sur les faits (et non sur la responsabilité) de ce que vous avez fait pour résoudre le problème et sur la façon dont ils voudraient que vous procédiez afin que, la prochaine fois que quelque chose ne va pas dans le service, le problème puisse être trouvé et résolu plus rapidement. Cela peut impliquer l'écriture d'un petit utilitaire de test qui teste le service directement (sans utiliser le code des autres développeurs), ou un enregistrement ou autre, afin que le problème “nous contre eux” puisse être déterminé très rapidement. S'ils savent qui est réellement en faute, ils peuvent vous innocenter sans que vous soyez en conflit direct avec le plus bruyant.

Je me suis toujours plié en quatre pour éviter de mettre les autres développeurs sur la défensive. J'ai dit des choses comme “J'ai du mal à reproduire le problème, pouvez-vous s'il vous plaît me faire savoir quels appels vous passez au service et ce que vous recevez en retour afin que je puisse tester le service correctement” ? Si le développeur se donne la peine de vous donner les traces des appels et des réponses, demandez-lui ce qu'il s'attend à recevoir en retour. Cependant, la plupart du temps, le développeur se contentera de vous montrer son code. Dans ce cas, vous pouvez parfois repérer le problème. Même si vous le faites, ne les appelez pas. Ils doivent trouver le problème eux-mêmes. Faites-lui exécuter le code par un débogueur, et demandez-lui innocemment ce que contient une certaine variable à une certaine ligne de code. Je pourrais continuer, mais vous comprenez l'idée.

C'est une très bonne tradition dans le secteur des TI (et dans certains autres, comme l'aviation) que lorsque quelqu'un trouve un problème, tout le monde travaille ensemble pour trouver une solution, et idéalement pour trouver la cause première afin d'améliorer les processus, mais personne n'est personnellement blâmé ou pénalisé pour avoir commis l'erreur. Le résultat est que les gens sont ouverts et honnêtes à propos de leurs erreurs, plutôt que d'essayer de les dissimuler, ce qui est dans l'intérêt de tous.

Il semble qu'il y ait des gens dans votre magasin qui n'ont pas adhéré à cette culture, et c'est quelque chose qui nécessite l'attention de la direction.

Je pense que vous devriez discuter avec votre responsable de la manière dont les problèmes sont traités, en particulier les problèmes prioritaires qui ont un impact sur l'expérience des utilisateurs.

Dans ce cas, vous avez deux systèmes qui communiquent entre eux et soudain la communication cesse de fonctionner. Lorsque la communication échoue, il est important que les deux parties examinent les deux systèmes. Chacun se concentre sur votre service, ce qui l'amène à ne pas enquêter sur les choses de son côté. La plus grande perte de temps dans la résolution d'un problème est d'essayer de trouver ce qui ne va pas avec une partie de celui-ci qui fonctionne en fait comme il se doit.

Ce sont cependant des expériences d'apprentissage. Je parie que vous savez maintenant parfaitement comment dépanner votre service. Essayez de mettre en place un plan de dépannage basé sur votre expérience, et faites l'une des premières démarches pour vous assurer que c'est bien votre service qui est défaillant (“Le service fonctionne-t-il en étant appelé depuis une autre page ?”, “Le service est-il partiellement ou entièrement défaillant ?) Vous êtes LE gars du service web, vous pouvez avoir un peu confiance en votre travail.

Essayez de laisser tomber le fait que c'est en fait son code qui a échoué. Essayer de lui faire comprendre cela est un peu mesquin. Il n'aurait pas dû se concentrer autant sur vous dès le début. Voyez cela comme un problème général au sein de l'entreprise, avec le dépannage d'un problème et traitez-le comme tel avec votre responsable. Vous ne savez pas non plus si c'était vraiment son code, il aurait pu aussi le copier à partir d'une autre section écrite par un collègue.

Je pense que la suggestion de parler avec votre manager est bonne. Votre manager doit savoir que vous avez été injustement blâmé.

Mais en plus de cela, vous êtes testé. Votre instinct initial est bon ; vous devez réagir, sinon la situation va empirer. Je lui enverrais directement un e-mail pour lui faire savoir que le problème était dans son code, et que pour cette fois, vous n'en avez parlé qu'à votre manager, à qui vous deviez en parler pour vous protéger. Et enfin, je lui disais que s'il recommençait, vous rendriez tout cela public.

Je suis un peu en retard sur la question, mais en plus des conseils très judicieux donnés par Edgar dans sa réponse, il y a une deuxième partie à cela.

Si vous envoyez une communication indiquant que vous avez trouvé le problème et que vous notez où il a été résolu, alors les autres développeurs sauront probablement où se trouve le problème (c'est bien), mais la direction ne le saura probablement pas.

Faire comme ça signifie que vous avez rendu service à ce type - il vous a appelé publiquement, vous avez trouvé le problème, vous l'avez résolu et vous ne l'avez pas laissé tomber avec la direction. En établissant ainsi une relation de confiance avec vos collègues, vous vous mettrez en bonne position à long terme.

Légère remarque - cela dépend évidemment un peu de la nature de la faute que vous trouvez dans leur travail. Si ce que vous trouvez est si manifestement erroné qu'il indique une incompétence de leur part, vous pouvez en parler discrètement à votre supérieur hiérarchique - il voudra le savoir et vous établissez également une relation de confiance avec lui.

Je vous suggère d'y réfléchir avant de répondre aux aspects personnels de la situation. Si vous avez réglé le problème et remis les choses en marche, vous êtes toujours “l'homme”. Après vous être reposé, il vous sera plus facile d'être aimable.

Bien que le problème principal ait déjà été longuement abordé dans d'autres awswers - l'autre gars qui vous harcèle - j'aimerais vous montrer une autre perspective.

La correction a été faite dans le code que l'autre gars possédait, mais le plus souvent le service aurait pu éviter un problème plus important en étant plus conservateur dans le traitement des demandes des clients. Est-ce qu'il valide les entrées ? Signale t-il des erreurs d'exécution ? Y a-t-il un environnement de test (cela s'applique également aux consommateurs) ? Parfois, un problème dans le service n'attendait que d'être résolu, donc je dirais que ce n'est pas parce qu'une correction a été faite à un endroit que cela signifie que c'est toute l'histoire. De plus, pour des problèmes comme celui-ci, il n'y a pas que le code. Il y a aussi un processus.