Envoyez simplement un e-mail à toutes les personnes impliquées en disant que, après les heures de bureau, vous avez trouvé (et corrigé) le bogue. "Il en est ainsi en AB." Peut-être avec un lien vers quelque chose. Ne mentionnez personne.

Cela devrait suffire. Vous n'êtes pas obligé de pointer du doigt qui que ce soit.

Les autres examineront la question et bientôt ils découvriront qui était / est responsable de ce bogue , et la prochaine fois, ils y réfléchiront à deux fois avant de vous déranger.

Évitez le jeu du blâme

Il y aura toujours des problèmes, des erreurs se produisent, des circonstances surviennent qui font que le service X n'est plus satisfait du service Y.

Ce dont tout le monde a besoin se concentrer, c'est résoudre le problème sans se laisser entraîner dans le jeu du blâme. Laisser l'expert en la matière examiner et diagnostiquer le problème et régler les choses à partir de là.

Le problème n'est pas (officiellement) avec quelqu'un d'autre - c'est un problème avec le service Y qui a son propre expert en la matière pour résoudre le problème.

Après cela, il y a des "leçons apprises" pour essayer de comprendre ce qui a causé le problème.

Pas "qui". C'est l'élément clé ici. Si les gens veulent prendre le blâme, c'est la chose honorable à faire.

Dans ce cas, ne ripostez pas, ne vous laissez pas entraîner dans le jeu du blâme, soyez reconnaissant que le problème a été identifié et résolu.

Certaines personnes ont tendance à rejeter agressivement le blâme sur les autres afin de détourner l'attention d'elles-mêmes. Puisque 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 e-mail, décrivez quel était le problème, comment vous avez atteint la cause principale, quelle a été la solution éventuelle et comment il peut être évité à l'avenir. Incluez toutes les parties prenantes dans ce mail.

À la fin de ce mail, écrivez quelque chose sur ces lignes,

XYZ,

Pouvez-vous s'il vous plaît ajouter ces étapes dans la documentation appropriée ou dans le document sur les procédures standard d'exploitation pour ce morceau de code?

De cette façon, vous «ne pointez pas du doigt» lui, mais vous l'appelez explicitement qu'il est le propriétaire de ce morceau de code et donc responsable de celui-ci. L'appel est important car tout le monde (en particulier la haute direction) n'ouvrira aucun lien de base de code pour voir à qui il appartenait.

Un peu dur, mais il le mérite.

J'ai construit ma carrière en ne jouant pas au jeu du blâme, mais la vérité est que les humains écoutent la voix la plus forte. Cependant, si vous vous impliquez dans la défense de vous-même, il vous ramènera à son niveau et vous battra avec l'expérience.

Si vous pouvez en trouver un, vous avez besoin d'un champion. Idéalement, cela devrait être votre manager, mais parfois, c'est un autre développeur très respecté. Ils iront au bâton pour que vous fassiez taire le bruyant. Tout ce que vous avez à faire est d'avoir une discussion privée avec eux sur les faits (pas le blâme) de ce que vous avez fait pour résoudre le problème et comment ils aimeraient que vous procédiez pour que, la prochaine fois que quelque chose ne va pas avec le service, le problème. peuvent être trouvés et corrigés plus rapidement. Cela peut impliquer d'écrire un petit utilitaire de test qui teste le service directement (sans utiliser le code des autres développeurs), ou une journalisation ou quelque chose, de sorte que le problème «nous contre eux» peut être très rapidement déterminé. S'ils savent qui était réellement en faute, ils peuvent effacer votre nom sans que vous soyez en conflit direct avec le plus fort.

Je me suis toujours plié en quatre pour éviter de mettre les autres développeurs sur la défense. 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 faites au service et ce que vous obtenez afin que je puisse tester le service correctement"? Si le développeur prend la peine de vous donner des traces des appels et des réponses réels, demandez-lui ce qu'il s'attendait à récupérer. Cependant, la plupart du temps, le développeur ne vous montrera que son code. Dans ce cas, vous pouvez parfois repérer le problème. Même si vous le faites, ne les appelez toujours pas. Ils doivent trouver le problème eux-mêmes. Demandez-leur d'exécuter le code via un débogueur et de demander innocemment ce qu'une certaine variable contient à une certaine ligne de code. Je pourrais continuer, mais vous voyez l'idée.

C'est une très belle tradition dans l'industrie informatique (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 profonde afin que les processus puissent être améliorés, mais personne n'est blâmé personnellement ou ne subit de sanctions 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 que des personnes dans votre boutique n'aient pas acheté à 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 utilisateur.

Dans ce cas, vous avez 2 systèmes communiquant entre eux et soudainement la communication cesse de fonctionner. Lorsque la communication échoue, il est important que les deux parties examinent les deux systèmes. Tout le monde met l'accent sur votre service, ce qui les amène à ne pas enquêter de leur côté. La plus grande perte de temps pour résoudre un problème consiste à essayer de découvrir ce qui ne va pas avec une partie de celui-ci qui fonctionne réellement 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 en fonction de votre expérience et effectuez l'une des premières étapes pour vous assurer que c'est bien votre service qui échoue ("Le service fonctionne-t-il en étant appelé depuis une autre page?", "Le service échoue-t-il partiellement ou entièrement?"). 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 l'appeler là-dessus est un peu mesquin. Il n'aurait pas dû se concentrer autant sur vous depuis le début. Considérez-le comme un problème général au sein de l'entreprise avec le dépannage d'un problème et gérez-le comme tel avec votre responsable. Vous ne savez pas non plus s'il s'agissait en fait de son code, il aurait également pu le copier à partir d'une autre section écrite par un collègue.

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

Mais en plus de cela, vous êtes testé. Votre instinct initial a raison; vous devez répondre, sinon la situation s'aggravera. Je lui enverrais un e-mail directement et lui ferais savoir que le problème était dans son code, et que pour cette fois, vous ne l'avez dit à personne d'autre qu'à votre manager, à qui vous deviez dire pour vous protéger. Et enfin, faites-lui savoir que s'il recommence, vous deviendrez public.

En tant que testeur de logiciels, je connais cette situation. Et aussi en tant que testeur de logiciel, pourquoi ce bogue n'a-t-il pas été détecté lors des tests? Je suppose que vous êtes un développeur?

Oui, ça craint que vous ayez été blâmé par le type qui a causé le problème. Cependant, ce n'est PAS ce dont l'entreprise va se soucier. Tout ce qu'ils veulent, c'est une résolution où plus aucun show-stop n'arrive sur le site en direct.

J'attendrais jusqu'à la prochaine conférence téléphonique si vous en avez régulièrement, et je mentionnerai que vous avez analysé la cause profonde du problème et énoncez objectivement vos conclusions. Si on vous demande qui a écrit ce code, dites de qui il s'agit, sinon ne pointez pas du doigt celui qui l'a fait. Vous devriez être plus mature / professionnel que cela et vous obtiendrez beaucoup plus de respect si vous gérez la situation de cette manière.

Pour éviter que cela ne se reproduise, interrogez comment cela a glissé via de manière non accusatoire , et travaillez avec eux pour mettre en œuvre une nouvelle étape ou un nouveau test qui aurait détecté le problème.

Enfin, signalez tout cela à votre responsable. Montrer les défauts du bouchon sont un gros problème et ses hauts supérieurs lui souffleront aussi dans le cou.

Je suis un peu en retard pour la question ici, mais à côté des conseils très judicieux dans la réponse d'Edgar, il y a une deuxième partie à ceci.

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

Faire comme ça signifie que vous avez fait un faveur - il vous a appelé publiquement, vous avez trouvé le problème, l'avez résolu et ne l'avez pas laissé tomber avec la direction. Construire une confiance comme celle-ci avec vos collègues vous sera utile à long terme.

Légère remarque - cela dépend évidemment légèrement de la nature du défaut que vous trouvez dans leur travail . Si ce que vous trouvez est tellement erroné que cela indique une incompétence de sa part, vous voudrez peut-être le signaler discrètement à votre responsable - il voudra le savoir et vous établissez également une relation de confiance avec lui.

Je vous suggère de dormir dessus avant de répondre aux aspects personnels de la situation. Si vous avez résolu le problème et que les choses fonctionnent à nouveau, vous êtes toujours «l'homme». Après s'être reposé, il sera plus facile d'être gracieux.

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 souligner un autre point de vue.

Le correctif a été fait 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 prudent dans le traitement des demandes des clients. Valide-t-il les entrées? Signale-t-il des erreurs d'exécution? Existe-t-il un environnement de test (cela s'applique également au consommateur)? Parfois, un problème dans le service n'attendait que de faire surface, alors je dirais que ce n'est pas parce qu'une correction a été effectuée à un endroit que cela signifie que c'est toute l'histoire. De plus, pour des problèmes comme celui-ci, il y a plus que du code. Il y a aussi un processus.