Wie man mit einem Kollegen umgeht, der mich für den Fehler verantwortlich macht, der seine Schuld war

Ich bin relativ neu in einem Job, habe mich aber als der „Typ“ etabliert, wenn es um einen bestimmten Webdienst geht, den wir verwenden. Unsere eigene Website integriert sich in den Dienst. Ich arbeite nicht wirklich auf der Seite, nur mit dem Service.

Heute hatten wir so etwas wie ein Show-Stopp-Problem, das dazu führte, dass Benutzer der Website den Dienst nicht nutzen konnten. Natürlich wurde ich zu Hilfe gerufen, aber einer der Website-Entwickler wurde mir persönlich gegenüber schnippisch, unterstellte mir, dass ich meine Arbeit nicht mache, und beschuldigte mich schlechter Kommunikation. Später in einer Telefonkonferenz mit mindestens 8 anderen Personen rief er mich passiv-aggressiv an, weil ich das Problem nicht gelöst hatte.

Nach einem langen Tag, an dem ich bis spät in die Nacht gearbeitet und von zu Hause aus gearbeitet hatte, stellte ich schließlich fest, dass die Ursache des Problems nicht im Dienst lag, sondern im Code auf der Website und insbesondere im Code, den der schnippische Entwickler geschrieben hatte.

TL;DR: Der Typ, der mit dem Finger auf mich zeigte, war tatsächlich die Ursache des Problems

Ich bin im Allgemeinen eine lockere Person und habe keinen Grund, diesen Typen abzumahnen; Ich hoffe jedoch auf einige Vorschläge, wie ich ihm taktvoll ausdrücken kann, dass ich es vorziehen würde, wenn er sich zu 100% absolut sicher wäre, dass es nicht sein Code ist, bevor er wieder diesen Ton mit mir anschlägt.

Kommentare sind nicht für längere Diskussionen gedacht; Diese Konversation wurde in den Chat verschoben .

Antworten (11)

Senden Sie einfach eine E-Mail an alle Beteiligten und sagen Sie, dass Sie den Fehler nach Feierabend gefunden (und behoben) haben. "Es ist so und so in AB." Vielleicht mit einem Link zu etwas. Erwähne keine Person.

Das sollte genug sein. Sie müssen auf niemanden mit dem Finger zeigen.

Die anderen werden sich das ansehen und bald herausfinden, wer für diesen Fehler verantwortlich war/ist , und das nächste Mal werden sie es sich zweimal überlegen, bevor sie sich mit Ihnen anlegen.

Ich würde dies auch tun, vorausgesetzt, dies war ein einmaliger Vorfall. Wenn es Teil eines Musters ist, kann eine defensive Eskalation gerechtfertigt sein. Im Moment würde ich nur die Notizen darüber bereithalten, was passiert ist, damit ich, wenn dies ein paar Mal passiert, einen ziemlich vernichtenden Bericht darüber erstellen kann, wie viel Zeit Sie damit verbringen, diesen Kerl aufzuräumen.
Stimmen Sie dem zu. Seien Sie der Typ, der scheißegal wird, und lassen Sie andere die Schuld spielen, wenn sie wollen – senden Sie eine neutrale E-Mail, in der Sie erklären, wo das Problem lag, und diejenigen, die das System kennen, können herausfinden, wer es verursacht hat, Sie brauchen es nicht darauf hinzuweisen
Stimmte auch. Aus meiner eigenen Erfahrung ist der Typ, der mehr daran interessiert ist, einen Schuldigen zu finden, als das Problem zu lösen, normalerweise der Schuldige. Vorausgesetzt, Ihre Manager sind keine Dummköpfe, wissen sie bereits, wer es vermasselt hat.
„Weil die anderen sich darum kümmern werden“ hängt davon ab, dass sich viele Menschen, vor allem in höheren Positionen, nicht mit gelösten Themen befassen.
In der Wirtschaft gibt es ein Sprichwort: „Beherrsche den Fehler“. Auch wenn es eigentlich nicht deins war, hast du dir Mühe gegeben, es zu lösen, also solltest du unbedingt die zusätzliche Zeit und Mühe haben, die du investiert hast, um es zu beheben. Sie müssen nicht mit dem Finger auf diesen Typen zeigen, weil er den Fehler überhaupt gemacht hat - geben Sie einfach die Tatsache zu, dass Sie sich darum gekümmert haben.
Ich stimme @DonQuiKong zu. Andere können sich die Mühe machen oder auch nicht, sich damit zu beschäftigen. Aber es hört sich so an, als würde die Erwähnung, wo der Fehler war, wahrscheinlich klarstellen, dass er etwas getan hat, nicht Sie. Aber ich stimme auch den anderen Kommentaren zu, dass das Management/die Interessengruppen mehr von der Tatsache beeindruckt sein werden, dass Sie die zusätzliche Zeit investiert haben, um das Problem zu beheben, als davon, wessen Fehler es war.
Um das Bedürfnis nach Rache zu stillen, würde ich ein "Entschuldigung für den ganzen Überfall, der Grund, warum es so lange gedauert hat, ist, dass der Fehler nicht in dem Code war, an dem ich arbeite, aber es stellte sich heraus, dass er in diesem anderen Teil war, einschieben ".
Gute Frage, und diese Antwort ist genau richtig. Möchte nur ein paar Cent dazu geben. Wenn Menschen so aggressiv werden, deutet dies meiner Erfahrung nach normalerweise darauf hin, dass sie schuld sind. Alle Leute, die dies miterlebt haben, wissen also, dass dies eine starke Möglichkeit ist, also wäre es angemessen und jeder, eine Mitteilung darüber zu senden, was die Grundursache war, wie das behoben wurde und wie es in Zukunft verhindert wird, ohne auf seinen Kopf zu zielen die richtigen Schlussfolgerungen ziehen und ihre Wahrnehmungen entsprechend anpassen würden.
All dies war super hilfreich, vielen Dank an alle, die sich eingemischt haben. Ich glaube, ich war ein wenig aufgewühlt über den Vorfall, also sind ein paar besonnene Antworten genau das, was ich brauchte. Ich habe genau das getan, was in dieser Antwort vorgeschlagen wurde (was sich in vielen anderen Antworten widerspiegelt, es tut mir leid, dass ich nur eine als "richtig" genehmigen kann): Ich habe eine E-Mail mit einem Link zu meiner Pull-Anfrage gesendet, also sind die Beweise da für alle sichtbar. Ich fühle mich gut, wenn ich nicht mit dem Finger auf andere zeige und andere, wenn sie möchten, herausfinden lässt, wo das eigentliche Problem liegt. Danke nochmal.
@Džuris Wenn CV verwendet wird, würde ich mit "[...] arbeiten an; es wurde in Revision Nr. 9987 eingeführt" abschließen.
Sie können es nicht durchgehen lassen, ohne darauf hinzuweisen, dass es nicht Ihr Code war, sondern sein Code. Wenn Sie dies tun, ohne mit dem Finger auf die Verantwortlichen zu zeigen, hinterlassen die Leute einen schlechten Eindruck von Ihnen. Mein Kommentar wäre anders ausgefallen, wenn der andere Typ Ihre Fähigkeiten nicht in Frage gestellt hätte.
Niemand wird darauf eingehen. Jemand wird damit beauftragt, es zu reparieren, aber das war's. Dem Manager ist es egal, woher es stammt, und er würde wahrscheinlich sogar denken, dass Sie dafür verantwortlich sind. Selbst wenn er technisch gesund ist, wird es ihm egal sein, wer das Problem verursacht hat, nur dass es gelöst ist. Das Beste, was Sie tun können, ist zu versuchen, den Verantwortlichen deutlich zu machen, ohne jedoch explizit seinen Namen zu nennen. Eine andere Möglichkeit besteht darin, auf das Verhalten der Person als zentrales Thema einzugehen und dann darauf hinzuweisen, wie sie dich für etwas verantwortlich gemacht hat, tatsächlich aber die Ursache dafür war.
Trotzdem würde ich ein ruhiges Wort mit dem Kollegen führen und ihn wissen lassen, dass es nicht cool ist, mit dem Finger auf mich zu zeigen und mich vor dem Team zu dissen, und dass er beim nächsten Mal mit einem ernsthaften Problem rechnen muss.
Was ich tun würde, ist, "es wurde in Version Nr. 123 der Website eingeführt" aufzunehmen und diesen Text mit der Webschnittstelle der Quellcodeverwaltung zu verknüpfen, die eindeutig angibt, wer dies begangen hat. Wenn Sie ein solches Webinterface haben, natürlich.
@DonQuiKong Sie werden dies auf jeden Fall untersuchen, wenn es sich um einen Show-Stopper-Defekt handelt. Die Wirtschaft wird wahrscheinlich zumindest einen Bericht anfordern.
@PieterB Sie können sagen, dass es nicht Ihr Code war, ohne ausdrücklich darauf hinzuweisen, wessen Code es war. Josefs Vorschlag ist, wie ich das persönlich machen würde (d.h. notieren und verlinken Sie im Bugtracker, welche Revision welchen Codes das Problem verursacht hat. - Außerdem ist dies sowieso nur eine gute Praxis für Dokumentationszwecke, selbst wenn es Code gewesen wäre Du hast selbst geschrieben.)
Wenn diese Person (oder jemand anderes) sich in einem Meeting wieder so verhält, können Sie einfach sagen, dass Sie alle auf den neuesten Stand bringen, sobald Sie das Problem gefunden und behoben haben. Das bedeutet natürlich, dass Sie eventuell begangene Fehler öffentlich eingestehen müssen, aber das sollte kein Problem sein.
Um es auch den faulsten Empfängern wirklich klar zu machen, fügen Sie etwas hinzu wie "dieser Fehler wurde in Commit r456 eingeführt, der <relevantes Diff-Snippet> bewirkte". Der Typ, der die falschen Anschuldigungen erhebt, wird wissen, dass es sein Code im Diff ist, und jeder andere, der tiefer graben möchte, kann leicht das Versionskontrollsystem überprüfen und sehen, wer diesen Commit gemacht hat.

Vermeide das Schuldzuweisungsspiel

Es wird immer Probleme geben, Fehler passieren, Umstände treten auf, die dazu führen, dass Service X mit Service Y nicht mehr zufrieden ist.

Worauf sich alle konzentrieren müssen, ist das Problem zu lösen, ohne in das Schuldzuweisungsspiel hineingezogen zu werden. Lassen Sie den Fachexperten das Problem untersuchen und diagnostizieren und die Dinge von dort aus bearbeiten.

Das Problem liegt (offiziell) nicht bei jemand anderem – es ist ein Problem bei Dienst Y, der einen eigenen Fachexperten hat, um das Problem zu lösen.

Danach gibt es eine „Lektionen gelernt“, um herauszufinden, was das Problem verursacht hat.

Nicht "wer". Das ist hier das Entscheidende. Wenn die Leute die Schuld auf sich nehmen wollen , ist das ehrenhaft.

Reagieren Sie in diesem Fall nicht, lassen Sie sich nicht in Schuldzuweisungen verwickeln, seien Sie dankbar, dass das Problem erkannt und gelöst wurde.

Schlägst du vor, das Zeigen mit dem Finger komplett zu ignorieren oder dem anderen zu sagen, dass er das bitte auch nicht tun soll?
Das ist das Problem mit dem Meme „Vermeide das Schuldspiel“. Was normalerweise passiert, ist, dass eine Person jemandem die Schuld gibt und wenn dann jemand sagt „Hey, das bin ich nicht“, kommt die erste Person zurück und sagt „Lass uns nicht in das Schuldzuweisungsspiel geraten“. Viele Leute, die Flipcharts zutiefst verleugnen, sagen nette und flauschige Dinge über Kommunikation und "gelernte Lektionen" und so, aber die Realität ist, dass Sie das Richtige tun sollten (nicht andere für Ihre Fehler verantwortlich machen) , weil es das Richtige ist ( nicht in Erwartung einer Belohnung) und es so gut du kannst aufsaugen, wenn andere sich nicht benehmen, weil Arbeit dir Geld bringt.
@ user6697063 Ich verstehe Ihren Standpunkt hier. aber die Spielschuld ist ziemlich unausgereiftes Spielplatzzeug. Es ist verlockend, Menschen die Schuld für Fehler zu geben, aber es ist erwachsen, sich auf das Problem selbst zu konzentrieren und aus dem Fehler zu lernen, der es verursacht hat. Wer auch immer das Problem verursacht hat, sollte reif genug sein, es zuzugeben (wenn auch nur vor sich selbst) und von dort aus weitermachen. MEIN aktuelles Team folgt nicht der Schuldzuweisungskultur, wir machen einfach weiter und klären die Dinge.
@Snow Du sagst, es ist ziemlich unausgereiftes Spielplatzzeug, aber wenn der Manager von OP feststellt, dass man sich auf OP nicht verlassen kann, wirkt sich das auf seine Karriere aus. Es ist im Allgemeinen eine nette Regel, aber wenn Ihre Fähigkeiten öffentlich in Frage gestellt werden, denke ich, dass es eine Art Widerstand geben muss, sonst könnte es zu einem wiederkehrenden Problem werden.
Eine andere Art, es zu gestalten, ist, was "schuld" ist, ist der Prozess . Entweder sind mehrere Personen "schuld", oder Sie haben einen Prozess, bei dem ein Fehler einer einzelnen Person ein ernsthaftes Problem in der Produktion verursachen kann, in welchem ​​​​Fall das gesamte Team "schuld" ist. Einer Person die Schuld für einen Fehler zu geben, wird sie (oder irgendjemand anderen) nicht davon abhalten, in Zukunft einen weiteren Fehler zu machen. Herauszufinden, wie der Prozess verbessert werden kann, damit die unvermeidlichen Fehler nicht zu Produktionsausfällen werden, ist jedoch sowohl ein konstruktiver Dialog als auch von geschäftlichem Wert.
@snow Mein üblicher Ansatz, wenn ich von Leuten beschuldigt werde, die die Gewohnheit haben, mit dem Finger zu zeigen, besteht darin, einfach zu sagen, wo meiner Meinung nach der Fehler liegt, sie sagen zu lassen, "lass uns nicht das Schuldzuweisungsspiel spielen", und dann mit dem Leben weitermachen. So können andere entscheiden. Das Problem, es passieren zu lassen, besteht darin, dass Sie am Ende den Ruf eines Fußabtreters unter Leuten bekommen können, die ihre Fehler weitergeben wollen, und wenn es eine kritische Masse erreicht, nehmen Leute, die nicht wissen, was passiert, an, dass eine Arbeit schlecht ist Qualität, auch wenn sie dich nicht kennen, und es wird zur Überlieferung. Normalerweise reicht eine anfängliche Herausforderung aus, um diese Spirale zu stoppen.
@DerekElkins Nach Jahren der Zusammenarbeit mit jemandem, der das immer gesagt hat, nein . Manchmal ist es die Schuld eines Menschen. Denn besonders in der Software gibt es große Designfehler, einfach nur dumme Codezeilen und ein vollständiges und völlig falsches Verständnis des von Ihnen geschriebenen Codes. Wir brauchen zwar keinerlei öffentliche Beschämung, aber sie müssen (zumindest mental) anerkennen, dass sie es vermasselt haben, und daraus lernen. Kein Prozess kann alles reparieren. Manchmal muss man einfach kompetente Leute haben, und Leute werden nicht kompetent, ohne die Verantwortung für ihre schlechten Entscheidungen zu übernehmen.
@Snow das ist schön, wenn es für dich funktioniert, aber das funktioniert nicht überall. In der Situation von OP wird er/sie öffentlich vor Leuten gerufen, die nicht zum Team gehören, und wird beschuldigt. Wenn er/sie mit einer neutral formulierten Obduktion zurückkommt, ist ein häufiges Ergebnis, dass Menschen, die nicht eng involviert sind (wie ein hochrangiger Manager), die Idee des OP durcheinander bringen, aber zumindest behoben werden.
Ich gebe dir die Schuld @Snow
Schuldzuweisungen zerstören die Moral und führen zu einer toxischen Kultur. Spielen Sie niemals mit.

Manche Menschen neigen dazu, anderen die Schuld aggressiv zuzuschieben, um die Aufmerksamkeit von sich abzulenken. Da Sie auch relativ neu sind, muss es für ihn sehr bequem gewesen sein, das zu tun, was er getan hat.

Hier ist mein Rat. Schreiben Sie eine E-Mail, beschreiben Sie, was das Problem war, wie Sie die Ursache gefunden haben, was die eventuelle Lösung dafür war und wie es in Zukunft verhindert werden kann. Beziehen Sie alle Beteiligten in diese Mail ein.

Schreiben Sie am Ende dieser Mail etwas zu diesen Zeilen,

XYZ,

Können Sie diese Schritte bitte in die entsprechende Dokumentation oder das Standard-Operating-Procedures-Dokument für diesen Codeabschnitt einfügen?

Auf diese Weise "zeigen Sie nicht mit dem Finger" auf ihn, sondern Sie weisen ausdrücklich darauf hin, dass er der Eigentümer dieses Codestücks und somit dafür verantwortlich ist. Das Aufrufen ist wichtig, da nicht jeder (insbesondere das höhere Management) irgendwelche Codebase-Links öffnet, um zu sehen, wessen Commit es war.

Ein bisschen hart, aber er hat es verdient.

Beste Antwort bis jetzt IMO. Die Idee, nach Unterlagen zu fragen, ist ziemlich gut.
Ich mag die Idee, eine Notiz für "XYZ....." hinzuzufügen.
An den meisten Orten, an denen ich gearbeitet habe, schaut sich tatsächlich jemand den Code an, besonders wenn es tatsächliche Benutzerprobleme / Ausfälle gab. Wenn nicht, würden sie eher jemanden fragen, der es hat. Ich glaube nicht, dass ein Anruf erforderlich ist, und ich würde es auch lieber nicht tun, es sei denn, es kommt wieder und ich werde deswegen belästigt.

Ich habe mir eine Karriere aufgebaut, indem ich nicht Schuldzuweisungen gemacht habe, aber die Wahrheit ist, Menschen hören auf die lauteste Stimme. Wenn Sie sich jedoch darauf einlassen, sich selbst zu verteidigen, wird er Sie auf sein Niveau herunterziehen und Sie mit Erfahrung schlagen.

Wenn du einen finden kannst, brauchst du einen Champion. Idealerweise sollte dies Ihr Manager sein, aber manchmal ist es ein anderer angesehener Entwickler. Sie werden für dich schlagen, um den Lauten zum Schweigen zu bringen. Alles, was Sie tun müssen, ist ein privates Gespräch mit ihnen über die Fakten (nicht die Schuld) darüber, was Sie getan haben, um das Problem zu lösen, und wie sie möchten, dass Sie vorgehen, damit beim nächsten Mal etwas mit dem Dienst nicht stimmt schneller gefunden und behoben werden. Das kann das Schreiben eines kleinen Testprogramms beinhalten, das den Dienst direkt testet (ohne den Code anderer Entwickler zu verwenden), oder etwas Protokollieren oder so etwas, sodass das Problem „wir gegen sie“ sehr schnell festgestellt werden kann. Wenn sie wissen, wer tatsächlich schuld war, können sie Ihren Namen reinwaschen, ohne dass Sie direkt mit dem Lauten in Konflikt geraten.

Ich habe mich immer nach hinten gebeugt, um andere Entwickler nicht in die Defensive zu drängen. Ich habe Dinge gesagt wie „Ich habe Probleme, das Problem zu duplizieren, können Sie mir bitte mitteilen, welche Anrufe Sie an den Dienst tätigen und was Sie zurückbekommen, damit ich den Dienst richtig testen kann“? Wenn sich der Entwickler die Mühe macht, Ihnen Protokollaufzeichnungen der tatsächlichen Anrufe und Antworten zu geben, fragen Sie, was er als Antwort erwartet. Meistens zeigt Ihnen der Entwickler jedoch nur seinen Code. In diesem Fall können Sie das Problem manchmal erkennen. Selbst wenn du es tust, rufe sie trotzdem nicht heraus. Sie müssen das Problem selbst finden. Lassen Sie sie den Code durch einen Debugger laufen lassen und unschuldig fragen, was eine bestimmte Variable in einer bestimmten Codezeile enthält. Ich könnte weitermachen, aber Sie bekommen die Idee.

Beste Beratung hier. Der Umgang mit Code ist ähnlich wie der Umgang mit Problemen mit Beiträgen hier auf SE; Wenn Sie zulassen, dass die Dinge personalisiert werden, hört jeder auf, dem anderen zuzuhören.

Es ist eine sehr schöne Tradition in der IT-Branche (und in einigen anderen, wie der Luftfahrt), dass, wenn jemand ein Problem findet, alle zusammenarbeiten, um eine Lösung zu finden und idealerweise die Grundursache zu finden, damit Prozesse verbessert werden können, aber nein- man bekommt persönliche Schuld oder erleidet Strafen für das Begehen des Fehlers. Das Ergebnis ist, dass die Menschen offen und ehrlich mit ihren Fehlern umgehen, anstatt zu versuchen, sie zu vertuschen, was allen zugute kommt.

Es sieht so aus, als ob es in Ihrem Geschäft Leute gibt, die sich dieser Kultur nicht verschrieben haben, und das ist etwas, das die Aufmerksamkeit des Managements erfordert.

OP sagt, es gab einen Anruf mit 8 Personen, bei dem 2 oder mehr Entwickler anwesend waren. Eines der besprochenen Themen war schlechte Kommunikation. Und das alles, während die Produktion stillstand. Erst am Abend war OP in der Lage, das Problem effektiv zu analysieren. Schuldzuweisungen sind nicht das schwerwiegendste Problem dieser "Kultur".

Ich glaube, Sie sollten mit Ihrem Vorgesetzten darüber sprechen, wie Probleme gehandhabt werden, insbesondere vorrangige Probleme, die sich auf die Benutzererfahrung auswirken.

In diesem Fall kommunizieren 2 Systeme miteinander und plötzlich funktioniert die Kommunikation nicht mehr. Wenn die Kommunikation fehlschlägt, ist es wichtig, dass beide Parteien beide Systeme betrachten. Alle konzentrieren sich auf Ihren Service, was dazu führt, dass sie die Dinge nicht auf ihrer Seite untersuchen. Die größte Zeitverschwendung bei der Lösung eines Problems besteht darin, herauszufinden, was an einem Teil davon falsch ist, der eigentlich so läuft, wie er sollte .

Dies sind jedoch Lernerfahrungen. Ich wette, Sie wissen jetzt genau, wie Sie Fehler bei Ihrem Dienst beheben können. Versuchen Sie, basierend auf Ihrer Erfahrung einen Fehlerbehebungsplan aufzustellen, und machen Sie einen der ersten Schritte, um sicherzustellen, dass es tatsächlich Ihr Dienst ist, der fehlschlägt ("Funktioniert der Dienst, wenn er von einer anderen Seite aufgerufen wird?", "Fällt der Dienst teilweise aus oder vollständig?"). Sie sind DER Webservice-Typ, Sie können ein wenig Vertrauen in Ihre Arbeit haben.

Versuchen Sie, die Tatsache loszulassen, dass es tatsächlich sein Code war, der fehlgeschlagen ist. Der Versuch, ihn darauf anzusprechen, ist ein bisschen kleinlich. Er hätte sich von Anfang an nicht so sehr auf dich konzentrieren sollen. Betrachten Sie es als allgemeines Problem innerhalb des Unternehmens mit der Behebung eines Problems und behandeln Sie es als solches mit Ihrem Vorgesetzten. Sie wissen auch nicht, ob es tatsächlich sein Code war, er könnte ihn auch aus einem anderen Abschnitt kopiert haben, der von einem Kollegen geschrieben wurde.

Ja, in einer idealen Welt würde dieser Webdienst von einer Testsuite abgedeckt, und das Ausführen dieser Suite wäre Ihre erste Anlaufstelle. Wenn alle Tests bestanden werden, handelt es sich um (a) einen Client-Fehler, (b) einen Dienstfehler, der nicht von Tests erfasst wurde, dh einen Testfehler, (c) einen Dienst, der wie vorgesehen funktioniert, aber nicht wie vom Client erwartet, dh , ein Dokumentationsfehler.
Das ist ein guter Anruf, ich muss mich nach einer Art Prüfstand für den Service umsehen. Es ist ein ziemlich beliebter und robuster Dienst, also glaube ich ehrlich gesagt nicht, dass es jemals ein Problem mit Fehlern bei ihnen gibt, eher eine Frage, ob es richtig konfiguriert ist. Unabhängig davon ist es meine Domäne, daher wäre es großartig, meine Basis für das nächste Mal abzudecken, wenn dies passiert. Aber auf der positiven Seite habe ich mehr über diese Domain gelernt, zusammen mit einer Reihe von "ABs" -Codes, die mit meiner Domain interagieren, also bin ich für die Erfahrung besser dran.
Das Kopieren von Code, den Sie nicht verstehen, ist unangemessen, auch wenn er nicht fehlerhaft ist. Und wenn es sich im selben Projekt befindet, ist es unangemessen, es zu kopieren, anstatt es aufzurufen.

Ich denke, der Vorschlag, mit Ihrem Vorgesetzten zu sprechen, ist gut. Ihr Vorgesetzter muss wissen, dass Sie zu Unrecht beschuldigt wurden.

Aber obendrein werden Sie getestet. Ihr anfänglicher Instinkt ist richtig; Du musst reagieren, sonst wird es schlimmer. Ich würde ihm direkt eine E-Mail schreiben und ihn wissen lassen, dass das Problem in seinem Code lag und dass Sie es bisher niemandem außer Ihrem Vorgesetzten gesagt haben, den Sie zu Ihrem eigenen Schutz informieren mussten. Und lassen Sie ihn schließlich wissen, dass Sie an die Öffentlichkeit gehen werden, wenn er es noch einmal tut.

Dies wird das Problem nur eskalieren, ich stimme Ihrem Rat nicht zu
Ein privater Angriff ist immer noch ein Angriff, und ja, er wird die Situation eskalieren. Korrekturmaßnahmen sollten der Befehlskette folgen.
Eher eine "angemessene Antwort". Ich hatte solche Situationen; wenn man nicht reagiert, wird es tendenziell schlimmer. Die Sache mit der Befehlskette könnte funktionieren. Vielleicht, vielleicht auch nicht. Was ich sagen kann, ist, dass ich aus persönlicher Erfahrung gesehen habe, wie es zweimal gescheitert und einmal erfolgreich war. Das Problem ist, dass während des Wartens darauf, es herauszufinden, die Dinge ein bisschen schlimmer werden können.

Als Softwaretester kenne ich diese Situation. Und als Softwaretester, warum wurde dieser Fehler beim Testen nicht aufgegriffen? Ich nehme an, Sie sind Entwickler?

Ja, es ist scheiße, dass Sie von dem Typen beschuldigt wurden, der das Problem verursacht hat. Dies ist jedoch NICHT das, worum sich das Geschäft kümmern wird. Alles, was sie wollen, ist eine Auflösung, bei der es keine Show-Stopper mehr auf die Live-Site schaffen.

Ich würde bis zur nächsten Telefonkonferenz warten, wenn Sie sie regelmäßig haben, und erwähnen, dass Sie die Grundursache des Problems analysiert und Ihre Ergebnisse objektiv dargelegt haben. Wenn Sie gefragt werden, wer diesen Code geschrieben hat, sagen Sie, wer es war, andernfalls zeigen Sie nicht mit dem Finger auf den Typen, der ihn geschrieben hat. Sie sollten reifer/professioneller sein und Sie werden viel mehr Respekt bekommen, wenn Sie die Situation auf diese Weise handhaben.

Um zu verhindern, dass dies erneut passiert, fragen Sie nach Tests, wie dies auf nicht anklagende Weise durchgeschlüpft ist , und arbeiten Sie mit ihnen zusammen, um einen neuen Schritt oder Test zu implementieren, der das Problem aufgegriffen hätte.

Melden Sie dies schließlich Ihrem Vorgesetzten. Show-Stopper-Defekte sind eine große Sache und seine Vorgesetzten werden ihm auch im Nacken sitzen.

Ich bin etwas spät dran mit der Frage hier, aber neben den sehr fundierten Ratschlägen in Edgars Antwort gibt es noch einen zweiten Teil dazu.

Wenn Sie eine Mitteilung versenden, dass Sie das Problem gefunden haben, und notieren, wo es gelöst wurde, werden die anderen Entwickler wahrscheinlich wissen, wo das Problem liegt (das ist gut), aber das Management wahrscheinlich nicht.

Wenn Sie es so tun, haben Sie diesem Typen einen Gefallen getan – er hat Sie öffentlich angerufen, Sie haben das Problem gefunden, es behoben und ihn nicht mit dem Management in Verbindung gebracht. Ein solcher Vertrauensaufbau bei Ihren Kollegen wird Ihnen langfristig zugutekommen.

Kleine Nebenbemerkung - dies hängt offensichtlich leicht von der Art des Fehlers ab, den Sie in ihrer Arbeit finden. Wenn das, was Sie finden, so ungeheuer falsch ist, dass es auf Inkompetenz ihrerseits hinweist, sollten Sie dies vielleicht ruhig an Ihren Vorgesetzten eskalieren – sie werden es wissen wollen und Sie bauen auch Vertrauen zu ihnen auf.

Wenn Sie ihn nicht bloßstellen, werden es wahrscheinlich andere tun. Es sei denn, sie sind alle seine „Kumpel“, in diesem Fall sind Sie trotz Ihrer Unschuld Geschichte.

Ich schlage vor, Sie schlafen darüber, bevor Sie auf die persönlichen Aspekte der Situation eingehen. Wenn Sie das Problem behoben und die Dinge wieder zum Laufen gebracht haben, dann sind Sie immer noch „der Mann“. Nachdem Sie sich etwas ausgeruht haben, wird es einfacher sein, gnädig zu sein.

Während das Hauptproblem bereits in anderen awswers ausführlich angesprochen wurde - der andere Typ, der Sie belästigt - möchte ich auf eine andere Perspektive hinweisen.

Der Fix wurde in dem Code vorgenommen, den der andere Typ besaß, aber meistens hätte der Dienst ein größeres Problem verhindern können, indem er bei der Bearbeitung von Kundenanfragen konservativer vorgegangen wäre. Validiert es Eingaben? Meldet es irgendwelche Laufzeitfehler? Gibt es eine Testumgebung (gilt auch für Consumer)? Manchmal wartete ein Problem im Dienst nur darauf, aufzutauchen, also würde ich sagen, nur weil eine Fehlerbehebung an einer Stelle durchgeführt wurde, heißt das nicht, dass dies die ganze Geschichte ist. Außerdem gibt es für Probleme wie dieses mehr als nur Code. Es gibt auch einen Prozess.

Wie man mit einem Kollegen umgeht, der mich für den Fehler verantwortlich macht, der seine Schuld war
AntwortenHierDatenschutz-Bestimmungen1y, 0v