Wie geht man mit nicht helfenden Senioren um?

Ich bin Junior-Entwickler in meinem Team. Ich bin diesem Team letztes Jahr beigetreten und es ist mein erster Job. Unsere Arbeitszeiten sind von 10 bis 7.

Wenn ich etwas PR(1) mit ihnen teile. Sie nehmen sich Zeit, um sie sich anzusehen. Meistens, am letzten Tag des Sprints (2), zu Zeiten wie (17-18 Uhr) sagen sie: "Das sollte so funktionieren, das ist falsch" usw. Ich habe kein Problem damit, es zu sagen wo mein Code falsch ist, aber ich habe das Problem mit dem Timing.

Am letzten Tag des Sprints, während der wenigen letzten Arbeitsstunden des Tages, ist es erschreckend, wenn man sagt: „Das ist falsch, das ist falsch, korrigiere das“. Ich wollte sie so oft fragen: "Was hast du vorhin gemacht, geschlafen?"

Und wenn es eine Geschichte(3) gibt, von der ich keine Ahnung habe, wie das gehen soll, wenn ich mehr 4-5 Fragen stelle.... dann sagt er "Lass das. Ich mach das" statt erklärt mir alles. Das ist so unhöflich und irritierend.

Weil sie meine Senioren sind, habe ich Angst, dieses Thema während der Retrospektive oder vor Manager zu bringen. Wie soll ich damit umgehen?


1) PR = „Pull-Request“. Wo ein Entwickler Kollegen oder Senioren bittet, ihre Arbeit zu überprüfen.

2) Sprint = Die Arbeit wird so arrangiert, dass sie in einen bekannten kurzen Zeitraum passt, der als Sprint bezeichnet wird und normalerweise 1 oder 2 Wochen dauert. Das Team sollte sich idealerweise nur so viel Arbeit widmen, wie innerhalb dieses Sprints erreicht werden kann.

3) Arbeitsgegenstände werden als Benutzer-"Geschichten" präsentiert, die typischerweise nur eine kleine Menge an Funktionalität enthalten. Beispiel: „Da ich als geschäftlicher Benutzer einen Datumsbereich ausgewählt habe, sollte der Bericht nur Rechnungen für diesen Zeitraum enthalten.“

Was denkst du, würden sie bei so etwas tun? Dich feuern? Dich beschimpfen? Welcher tatsächliche Schaden könnte entstehen, wenn Sie Ihren Senioren sagen, dass ihre Pünktlichkeit Ihnen Probleme bereitet. Vielleicht gibt es Gründe, die Sie nicht kennen. Sie könnten Ihnen diese Dinge sagen. Besorgniserregender ist für mich, dass Sie es nicht in eine Retro bringen werden. Das sollten Sie unbedingt Ihrem Vorgesetzten mitteilen. Retro soll ein sicherer Raum sein.
Da du von Sprints sprichst, schätze ich, dass du Scrum machst. Gehört ein Code-Review zu Ihrer Definition von Done? Wenn ja, warum erfolgt dies am Ende des Sprints? Bleibt das Ticket bis dahin „in Bearbeitung“?
Sie könnten in Erwägung ziehen, sie zu fragen, ob sie einen Blick auf Ihre Pull-Requests werfen könnten, das mache ich, wenn es wichtig ist.
Gibt es eine vereinbarte Definition of Done? Haben User Stories jeweils klare überprüfbare wann dann Akzeptanzkriterien vorgegeben?
Sie haben Recht, das Verhalten anderer nicht im Nachhinein anzusprechen. Es könnte dazu führen, dass sie defensiv werden und einen „Schuldsturm“ auslösen, der Sie in eine viel verletzlichere Position bringt. Es ist viel besser, sich diesen Personen einzeln (nicht in einem formellen Meeting) in einem Kontext mit geringem Druck zu nähern und zu versuchen, ihre Bedürfnisse einzuschätzen und ihnen zu sagen, was Sie brauchen.
Wenn Sie es in der Retro zur Sprache bringen (was meiner Meinung nach der richtige Ort ist, um dies zu diskutieren), stellen Sie sicher, dass Sie es tun, ohne jemandem die Schuld zu geben. PR-Feedback zu erhalten, wenn es im aktuellen Sprint zu spät ist, etwas dagegen zu unternehmen, klingt nach etwas, das auch für andere ein Problem sein könnte.

Antworten (2)

Weil sie meine Senioren sind, habe ich Angst, dieses Thema während der Retrospektive oder vor Manager zu bringen. wie soll ich damit umgehen?

Sie sollten keine Angst haben. Tatsächlich ist die Retrospektive genau der richtige Ort, um diese Dinge aus früheren Sprints zur Sprache zu bringen. Allerdings sollten Sie es auch professionell erziehen. Eine Formulierung, die mir in den Sinn kommt:

Beim letzten Sprint erhielt ich nur bis zum letzten Tag des Sprints und nur wenige Stunden vor dem Ende des Sprints Feedback zu meinem Fortschritt und meinem Code. Dadurch hatte ich wenig bis gar keine Zeit, die gewünschten Änderungen vorzunehmen.

Halten Sie es einfach und bleiben Sie bei den Fakten. Außerdem müssen Sie nicht mit dem Finger zeigen oder bestimmte Kollegen erwähnen, es sei denn, Sie werden dazu aufgefordert. Ihr Manager oder Scrum Master sollte sich jetzt der Situation bewusst sein und damit umgehen können.

Nun, in Bezug auf aufbrausende Mitarbeiter, denen es an Geduld und Lehrfähigkeiten mangelt, gibt es nur wenige Dinge, die Sie tun können, um sie zu ändern . Sie können jedoch entscheiden, ob Sie sich durch ihre unverblümte Antwort beleidigt fühlen oder nicht (ich schlage vor, Sie tun es nicht).

Alternativ sollten Sie inzwischen wissen, welcher Kollege geduldiger oder freundlicher zu Ihnen ist. Dies ist auch eine großartige Gelegenheit, Ihre Fähigkeiten zur Selbstständigkeit und zum Googeln/Recherchieren zu verbessern: Versuchen Sie zu googeln und denken Sie über mögliche Lösungen nach, bevor Sie Kollegen fragen.

Vielleicht tun Sie dies nicht und deshalb zögern sie, Ihnen zu helfen oder alle Ihre Fragen zu beantworten. Wenn Sie ihnen zeigen, dass Sie sich Mühe geben, bevor Sie sie fragen (z. B. indem Sie die möglichen Lösungen oder Aspekte aufzeigen, die Sie recherchiert haben), erhalten Sie sicherlich besseres Feedback (heh, sogar im gesamten SE-Netzwerk ermutigen wir die Benutzer, sich etwas Mühe mit ihren Fragen zu geben, und diejenigen, die normalerweise keinen so guten Empfang haben).

Abschließend möchte ich sagen, dass Sie als Junior noch Dinge zu lernen haben und jeden Tag mehr und mehr autark sein werden (oder zumindest sollten Sie das tun, wenn Sie Ihre Fähigkeiten üben), also ist es in Ordnung, dass Sie fragen wenn Sie sich vorher etwas Mühe geben.

Das Klären Ihrer Zweifel / Überprüfen Ihres Codes am Ende der Arbeitszeit kann nur ein Zeichen dafür sein, dass sie überfordert sind, und das passiert häufig. Auf der anderen Seite kann Sie das nicht daran hindern, die Arbeit zu erledigen, also ist der einzige Ausweg ein offenes Gespräch mit ihnen. Wenn das fehlschlägt, kommt das Management ins Spiel.