Wie teilt man einem Kollegen mit, dass er einen massiven Programmierfehler eingeschleust hat?

Wir sind ein kleines Team von Entwicklern, die innerhalb einer eigenen Abteilung an einem IT-Projekt arbeiten. Keine Hierarchie zwischen uns in dieser Abteilung, aber ein gemeinsames Ziel: unsere Hauptanwendung zum Laufen zu bringen. Wir arbeiten alle am selben Code.

Ich bin sehr detailorientiert und achte sehr auf Standards, Clean-Code und architektonische Belange insgesamt.

Jetzt hat einer der erfahreneren Entwickler den Code so gepatcht, dass offensichtliche Fehler entstehen. Außerdem entsprechen seine Codeänderungen nicht einem bestimmten Qualitätsstandard. Im Grunde führt er aufgrund einer sorglosen Einstellung viele Fehler ein, oder zumindest aus einem Grund, den ich im Moment nicht nachvollziehen kann.

Der Abteilungsleiter kümmert sich nicht um Sauberkeit und operative Details. Er möchte, dass die Haupt-App läuft und wir ihr neue Funktionen hinzufügen können. Er möchte implizit, dass wir uns um diese Details kümmern. Ich denke, dass Qualitätsstandards und Wartbarkeit des Codes wichtig sind, er hat diese Tatsache akzeptiert, aber nichts ist in diesem Sinne formalisiert. Ziemlich viel "tu was du musst, es muss funktionieren ist mir egal wie"-Territorium.

Ich habe nicht die hierarchische Befugnis, den Kollegen zu „korrigieren“. Da er jedoch Fehler produziert, möchte ich ihn durch bloßen freundlichen Einfluss dazu bringen, diese Fehler zu vermeiden. Ich verstecke diese Fehler zufällig vor dem Manager und versuche sie zuerst mit dem Kollegen zu lösen. Er scheint gutwillig zu sein, sieht aber nicht so aus, als würde er lernen. Ich hatte auch in der Vergangenheit verbale Auseinandersetzungen mit ihm, weil er dachte, ich würde mich zu sehr in "seine Angelegenheiten" einmischen. Aber meistens verstehen wir uns recht freundschaftlich und respektieren uns gegenseitig. Ich könnte als Heiliger-als-du-Typ wahrgenommen werden, was nicht hilft. Trotzdem nehme ich diesen Mantel, weil ich das Bedürfnis danach habe.

Wie gehen Sie vor, um einem solchen Kollegen höflich, aber effizient zu helfen, unsere Codequalität zu verbessern? Das ist vor allem eine Kommunikationsfrage.

„Ich habe nicht die hierarchische Befugnis, den Kollegen zu ‚korrigieren‘.“ Ich verstehe nicht. Warum braucht man Autorität in einer Hierarchie, um einen Kollegen zu korrigieren?
Tipp: Sagen Sie ihm nicht, dass er einen massiven Fehler eingeführt hat – sagen Sie ihm, dass er einen Fehler eingeführt hat, zeigen Sie, was er tut, und lassen Sie ihn sein eigenes Adjektiv darauf anwenden. Das Wichtigste ist zunächst, dass es behoben wird. Fragen Sie danach, ob das Team als Ganzes besser testen sollte, bevor es Änderungen festschreibt ...
Danke euch beiden; Es geht wirklich darum, Respekt für mich zu zeigen und gleichzeitig die Botschaft weiterzugeben. Hierarchie oder Autorität hilft, die Botschaft durchzusetzen. Aber man kann auch darauf verzichten, denke ich. Dafür suchte ich nach Kommunikationshinweisen. Ich mag den Vorschlag zu zeigen, es ist subtiler.
Diese Frage sieht gruselig aus, als hätte ich sie geschrieben ...
Wie erwarten Sie, dass der Manager sieht, dass die Codequalität wichtig ist, wenn Sie Fehler vor ihm verbergen?
Zumindest persönlich würde ich es lieber sofort hören, wenn ich ein großes Problem in einem Commit hätte, bevor es größere Probleme verursacht. Da "ich" den Code gemacht habe, werde ich höchstwahrscheinlich auch schnell wissen, wie ich ihn beheben kann. Haben Sie keine Code-Reviews, in denen dies vermerkt werden könnte, bevor es mit Staging/Produktion zusammengeführt wird?
"Ich könnte als Heiliger-als-du-Typ wahrgenommen werden, was nicht hilft." - Ich nehme Sie sicherlich so wahr. Diese Frage wirkt sehr aggressiv und prätentiös. Wenn es nicht so beabsichtigt war, solltest du vielleicht an deinen Kommunikationsfähigkeiten arbeiten. Wenn Sie einen solchen Ruf bekommen, werden Ihre Kollegen Sie wahrscheinlich jedes Mal ignorieren, wenn Sie eine Korrektur vorschlagen.
@amphibient das gleiche hier, ich schaue normalerweise nicht, wer OP ist, ich musste es diesmal tun ...

Antworten (7)

Das Verstecken der Bugs wird Ihnen auf Dauer keinen Gefallen tun und hat Sie teilweise in diese Situation gebracht.

Es gibt ein paar Möglichkeiten, um möglicherweise nach unten zu gehen:

  1. Sagen Sie ihm einfach direkt, dass es einen Fehler gibt - Der freundliche Ansatz funktioniert möglicherweise nicht, da er bemerkt hat, dass Sie sich "in seine Angelegenheiten einmischen". Wenn Sie also sagen, dass ich wegen X einen Fehler gefunden habe, kann er ihn beheben.
  2. Versuchen Sie, Code-Reviews einzuführen – Wenn Sie die Freiheit haben, Arbeitspraktiken zu implementieren, dann schlagen Sie Ihrem Team vor, Code-Reviews bei jedem Check-in durchzuführen. Auf diese Weise können Sie diesen Check-in überprüfen und auf den Fehler in der Überprüfung hinweisen.

Beheben Sie die Fehler nicht selbst. Wenn es eine Möglichkeit gibt, Fehler zu protokollieren (haben Sie einen Fehler-Tracker), dann protokollieren Sie sie. Sie müssen wirklich versuchen, einen Manager an Bord zu holen, um ein gewisses Interesse an der Qualität des Codes zu haben. Da Sie den Code Ihrer Kollegen erkennen/reparieren müssen, hält Sie das davon ab, Ihre Aufgaben zu erledigen.

Ich kann nicht glauben, dass Nr. 1 ein ernsthafter Vorschlag ist. Der Rest ist sinnvoll. Pingen Sie mich, wenn Sie die Antwort korrigiert haben, und ich werde meine Ablehnung entfernen :)
@LightnessRacesinOrbit Es gibt ein Element der Ernsthaftigkeit. Wenn der Kollege nicht gut darauf reagiert, wenn ihm gesagt wird, dass es Fehler gibt (aus den sich einmischenden Kommentaren) und das Management sich nicht darum kümmert, müssen manchmal Dinge passieren, die das Management dazu zwingen , sich darum zu kümmern. Natürlich könnte er in einer idealen Welt Punkt 2 tun, versuchen, Punkt 3 einzuführen, und das wäre das, aber ist es die Aufgabe des OP, auf Fehler eines älteren Kollegen hinzuweisen (oder sie zu vertuschen)? Es hört sich so an, als ob dies oft vorkommt und einfach zu sagen, x oder y nicht zu tun, hat noch nicht funktioniert.
Ein Produkt absichtlich zu sabotieren, weil Sie nicht mit Ihrem Vorgesetzten zusammenarbeiten können, ist ein grobes berufliches Fehlverhalten. Sprechen Sie das Problem an. Wenn es ignoriert wird, ist das nicht Ihr Problem. Aber wenn Sie das Problem nicht ansprechen, weil Sie möchten , dass das Problem aus politischen Gründen zu den Kunden durchsickert, ist das ganz klar Ihr Problem, und als Ihr Chef hätte ich kein Problem damit, das klarzustellen, wenn ich es jemals herausfinden sollte!
Das ist ein fairer Punkt. Ich werde entsprechend bearbeiten
Es kommt alles auf die Nuancen an, wie man über den Fehler informiert. Ich mag die Code-Überprüfung, ich habe das in der Vergangenheit vergeblich an das Management herangetragen.
Wenn Sie eine Art formelle Einstellung (z. B. Codeüberprüfung) einführen können, werden Nuancen überflüssig, da die Codeüberprüfungen dies festlegen
Code-Reviews sind eine Möglichkeit, es formal zu machen, aber ich glaube, dass es das Problem nur einen Schritt zu spät verschieben kann. Es ist am besten, sich mit dem vorliegenden Problem zu befassen.

Jeder macht Fehler. Auf Fehler im Code von jemandem hinzuweisen, ist wie darauf hinzuweisen, dass Sie gehustet haben. Es ist nur natürlich, egal wie gut wir uns vorbereiten, man kann es nicht zu 100% vermeiden, also sollte es kein Tabu sein.

Da jeder Fehler macht, macht es keinen Sinn, sie zu verstecken oder nicht mit den Beteiligten darüber zu sprechen, und wenn das Management von vorhandenen Fehlern wissen muss, dann sagen Sie es ihnen einfach, spielen Sie einfach kein Schuldzuweisungsspiel.

Informieren Sie Ihren Kollegen über den Fehler. Wenn Ihnen das Projekt und Ihre Integrität als Mitarbeiter wichtig sind, weisen Sie darauf hin, dass der Fehler Ihrer Meinung nach hätte vermieden werden können, indem Sie X,Y-Praktiken befolgt hätten. Sie können ihn fragen, ob er Ihnen zustimmt oder nicht, um sicherzustellen, dass Sie seine Meinung kennen über die sache.

Wir haben nach dem letzten Patch einen Fehler in A gefunden, wir müssen C, D beheben. Um zukünftige Fehler ähnlicher Art zu vermeiden, wäre es meiner Meinung nach eine gute Praxis, X, Y zu tun, stimmst du zu? Wenn nicht, was können wir Ihrer Meinung nach anders machen, um dies zu vermeiden?

Wenn es keine offiziellen Richtlinien gibt, können Sie nicht viel tun, außer zu versuchen, bessere Praktiken vorzuschlagen, aber wenn er sich absolut weigert, zuzuhören, und Sie wirklich glauben, dass er für das Projekt nicht geeignet ist, weil es ihm im Allgemeinen egal ist, wie er ist seinen Job macht, dann müssen Sie es mit Ihrem engsten Vorgesetzten besprechen und danach einfach akzeptieren, was Ihr Vorgesetzter tun oder nicht tun möchte.

Wenn Sie jedoch möchten, dass sich das Management mehr um die Codequalität kümmert, geben Sie ihm einfach Beispiele dafür, wie die Nichtbeachtung bestimmter Praktiken in der Vergangenheit zu bestimmten Fehlern führen konnte und hat, nicht nur in Ihrem Projekt, sondern auch in anderen, und erklären Sie die Auswirkungen. Menschen interessieren sich nicht für Dinge, die sie nicht verstehen. Wenn sie verstehen, warum bestimmte Praktiken befolgt werden müssen, werden sie sie eher durchsetzen.

Ich werde weiterhin Änderungen vorschlagen, auf Managementebene habe ich nicht das Gefühl, dass ich die erwarteten Ergebnisse erreichen kann. Ich habe verschiedene Methoden ausprobiert, ohne Erfolg. Das Problem sein zu lassen, ist auch nicht, wie ich Dinge tun möchte.
Verständlich. Geben Sie Ihr Bestes, wenn nichts funktioniert, müssen Sie einfach abwägen, ob Sie unter diesen Umständen arbeiten möchten oder nicht. Wir können nur versuchen, die Welt zu verändern, aber zumindest haben wir bis zu einem gewissen Grad das Privileg zu wählen, wo wir arbeiten oder zumindest nicht arbeiten.

Wenn Sie keine offene Diskussion mit dem Kollegen wünschen, können Sie seine Sachen so verwenden, dass der Fehler ausgelöst wird. Was Sie dann tun, ist

  1. Protokolliere den Fehler
  2. Machen Sie einen Testfall
  3. Beheben Sie den Fehler. Bewahren Sie den Testfall als Beweis auf
  4. Beheben Sie verwandte Probleme

Das interessiert uns im Moment nicht, Sie sollten sich auf X konzentrieren

Dies ist eine faire Kritik, die Sie möglicherweise erhalten, wenn Sie Ressourcen für ein Problem aufwenden, das noch kein Problem ist. In diesem Fall möchten Sie möglicherweise die Schritte 3 und 4 von oben fallen lassen.

Das Gespräch mit dem Kollegen ist natürlich das Beste, meine Antwort bietet eine Alternative zum Ideal.

Ich denke, Sie haben Schwierigkeiten, etwas zu sagen, weil Sie sich in das Ergebnis investiert fühlen. Und das zu Recht, denn Sie beide sind Freunde und Kollegen.

Aber ich habe auch das Gefühl, dass dies einer dieser Momente ist, in denen man es einfach loslassen muss.

Wenn Sie Ihre Freundschaft und Arbeitsatmosphäre schätzen, müssen Sie diesen Aspekt Ihres Freundes einfach akzeptieren und weitermachen.

Mit dieser Einstellung können Sie dann Ihr Problem tatsächlich lösen.

Sag es ihm einfach direkt.

In Zeiten wie diesen erinnere ich mich an etwas, das ich in der Mittelschule gelernt hatte: Ich-Botschaften.

„Ich ärgere mich, wenn du Arbeiten mit Fehlern produzierst, weil ich sie dann beheben muss. Ich wünschte wirklich, du würdest das nicht mehr tun.“

Ich fühle ... wenn du ... ich will.

Wenn das nicht funktioniert, dann würde ich meine Herangehensweise an das Problem ändern, das heißt, ich würde mich seiner Einstellung anpassen und die Vergangenheit ruhen lassen, weil man schließlich nie wirklich weiß, wer der bessere Ingenieur ist .

"I feel annoyed when you produce work with bugs because then I have to fix them. I really wish you wouldn't do this any more."Das ist eine ziemlich feindselige Formulierung. Es ruft eine „Ich gegen dich“-Mentalität hervor. Vergleichen Sie dies mit dem Vorschlag von Jonast92: We found a bug in A after the latest patch, we need to fix C,D. To avoid future bugs of similar sort I think it would be good practice to do X,Y, do you agree? If not, what do you think we can do differently to avoid this?Dies ist sehr stark eine „Wir gegen das Problem“-Denkweise.

Haben Sie obligatorische Code-Reviews ? Mein Gefühl ist, dass die Antwort auf diese Frage nein ist. Wenn ja, sollten solche Ausnahmen dort abgefangen, dokumentiert und die Änderung abgelehnt werden.

Haben Sie ein Issue-Tracking-System wie Jira? Sie sollten Ihre Ergebnisse dokumentieren, Dateiunterschiede einbeziehen und beschreiben, wie sie einen Fehler einführen. Beschreiben Sie außerdem eine Reihe von Schritten zum Reproduzieren des Fehlers, der durch die schlecht implementierte Codeänderung verursacht wurde.

Sie sollten Ihren Einwand so formell wie möglich formulieren und harte, nachweisbare Fakten verwenden, keine Meinungen. Dabei geht es nicht um „Soft Skills“, Persönlichkeit oder Meinungen. Es handelt sich um eine leicht nachweisbare Inkompetenz und Sie sollten dies als solche für Ihre Vorgesetzten sichtbar dokumentieren. Sie sollten sich für eine Vorgehensweise entscheiden. In meiner 20-jährigen Programmiererfahrung ist es meistens nutzlos, einen Kollegen wegen der Art von Einwänden zu ermahnen, die Sie haben und die ich oft hatte. Aber wenn Sie Ihren Fall nicht klar und deutlich auf eine Weise demonstrieren können, die für jemanden mit Entscheidungsmacht verständlich ist, wird er wahrscheinlich auf taube Ohren stoßen.

Wenn Ihre Vorgesetzten Ihre Beschwerden anerkennen, sollten Sie hoffentlich in der Lage sein, einen Fall vorzulegen, um obligatorische Code-Reviews als Teil des SDLC zu implementieren, was meiner Meinung nach jemand mit Ihren Neigungen begrüßen sollte.

Vielen Dank. Wir haben beides nicht; Ich betrachte sie, wie Sie sagen, als wesentlich für die Qualitätsausgabe. Ich versuche, das Tracking durchzusetzen (was normalerweise durch das Versenden von Mails mehr oder weniger gelöst wird) - aber die Codeüberprüfung interessiert mich am meisten. Wie würden Sie dies bereitstellen und die Egos verwalten? Meine Angst ist, Programmierer in ihrem Stolz zu verletzen.
Die Codeüberprüfung muss ein obligatorischer Schritt des SDLC sein, der zwischen einer in einen Feature-Branch in Ihrem VCS eingecheckten Änderung und dem Hauptbranch, von dem aus sie bereitgestellt wird, steht. Keine Änderung sollte sich in einen bereitstellbaren Zweig einschleichen können, bevor sie überprüft wurde. Es funktioniert unterschiedlich mit verschiedenen VCSs, also hängt es davon ab, was Sie verwenden
Ich verstehe, aber hier interessiert mich mehr die psychologische Seite davon. Es besteht Widerwillen zu akzeptieren, dass solche Prozesse notwendig sein können und sollten. Zum Management kann ich Ihnen sagen, es ist "zu kompliziert für das, was wir tun". Ich sehe aber die Notwendigkeit. Mein Problem ist kein technisches; es geht darum, eine Idee zu vermitteln.
Tut mir leid, im Bereich "psychologisch" kann ich keine Ratschläge geben...

Dies geschieht normalerweise bei Produkten, die Ihr Unternehmen nicht warten muss, oder bei Projekten, bei denen der Projektmanager nicht über ausreichende Programmierkenntnisse verfügt. Das einzige, was Sie tun können, ist, Ihrem Projektleiter und Ihren Teamkollegen die Probleme zu melden, mit denen Sie konfrontiert sind, dieses Projekt aufrechtzuerhalten, ohne die Qualitätsstandards einzuhalten, und Zahlen vorzulegen. Wenn der Kunde diesen Geldverlust akzeptiert, ist es höchstwahrscheinlich, dass sich niemand darum kümmert, sondern nur die Person, die der Hölle gegenübersteht. Wenn es sich um ein geschlossenes Budgetprojekt oder ein Projekt handelt, das Sie normalerweise pflegen, wird Ihr Unternehmen Sie hören. Am einfachsten ist es, den Fehler zu finden und ihm zu helfen, bis er genug gelernt hat, um die Probleme selbst zu lösen.

Ich habe Code-Reviews in einigen Teams ausprobiert, aber sie sind eine Belastung, die eine kontinuierliche Unterstützung durch das Management erfordert. Schwer einzukaufen. Und nicht unfehlbar.

Was für uns funktionierte, war, dass jeder Entwickler dokumentierte Unit-Tests erstellen musste. Auf diese Weise haben sie ihre Fehler normalerweise vor der Bereitstellung für Benutzerakzeptanztests erkannt.

Bei größeren komplexen Projekten ließen wir Teams von 2 oder mehr Analysten die Unit-Tests für die Codierungsteams aus dem Design/den Anforderungen erstellen. Sie würden diese Tests für das gesamte Team durchführen. Das eliminierte die Unit-Test-Anforderung nicht, fügte aber die Ebene hinzu, die erforderlich ist, um sicherzustellen, dass alle Aktivitäten des Entwicklungsteams als Ganzes zusammengehalten werden.

Dokumentierte Unit-Tests zu einem Teil des Prozesses zu machen, um Code für jede Person im Team festzuschreiben, stellte sicher, dass der Sitz der Hosenentwickler die richtige Disziplin anwandte, ohne irgendjemanden herauszugreifen.

Fehler für das Team gingen mit dieser Disziplin um 80 % oder mehr zurück. Der Aufwand für den On-Call-Support ging so weit zurück, dass wir nach einer neuen Bereitstellung fast nie angerufen wurden.

Die Komplexität/Formalität des Testplans wurde basierend auf dem Ausmaß der Auswirkungen angepasst ... oft nur einen Absatz lang für kleine Änderungen ... aber erwartete Ergebnisse und tatsächliche Ergebnisse mussten dokumentiert werden (Screenshots usw.).

Nach dem Erfolg, dies mehrere Jahre lang in unserem Team durchzusetzen, führte das QA-Team diese Anforderung in der gesamten IT-Abteilung ein (sie taten dies unabhängig, als die QA in unserem Unternehmen reifte).

Gelegentlich führten wir Code-Reviews bei neuen Teamkollegen oder bei der Arbeit mit neuen Technologien durch. Aber das klingt nicht nach deinem Problem.

Bei einer neuen Anwendung, die wir erstellten, begannen wir damit, die Einheitentestpläne zu dokumentieren und zu speichern, damit sie wiederverwendet werden konnten. Dazu haben wir Team Track verwendet. Es war nicht ganz das beste Werkzeug, aber es war besser als eine Bibliothek mit Word-Dokumenten. Dadurch konnten wir auswählen, welche Funktionen getestet werden mussten, und wir konnten die Pläne bearbeiten, um unsere Änderungen zu dokumentieren. Dann könnten wir alle dazugehörigen Testszenarien durchspielen und Erfolg oder Misserfolg dokumentieren.

Wie teilt man einem Kollegen mit, dass er einen massiven Programmierfehler eingeschleust hat?
AntwortenHierDatenschutz-Bestimmungen1y, 0v