Soll ich Wissen mit meinem Kollegen teilen, wenn ich ihn nicht wertschätze [geschlossen]

Mein Kollege hat eine seltsame Art, auf Dinge zu antworten. Wenn er nach etwas gefragt würde, würde er sagen: " Das ist mein Job oder meine Seite der Arbeit/Codierung. Machen Sie sich darüber keine Sorgen. "

Also fragte ich mich, ob ich mein Wissen teilen sollte, denn wenn mein Kollege vorbei ist, würde er mir nicht seinen Teil des Codes sagen, sondern eine schnelle Antwort wie Kopieren und Einfügen und mich um eine vollständige Beschreibung dessen bitten, was ich tue und was das tut .

Es ist ein Zeichen dafür, dass ich mein Wissen nicht teilen oder zur Dokumentation beitragen sollte (wie mein Kollege es nicht tun würde und ich und mein PM die einzigen sind, die das tun).

Während mein Kollege sehr daran interessiert ist zu wissen, was ich tue, und seinen Weg besser verteidigen möchte (weil er denkt, dass meine beruflichen Fähigkeiten auch bei ihm liegen, z. B. ist er ein Entwickler und ein Designer).

Wie offen sollte ich mit ihm über meine Aufgabe und ihm gegenüber sein, wie er es gerne ausdrückt. " Mach dir keine Sorgen, es ist mein Problem oder mein Teil des Codes ", aber würde mich fragen, warum und wie für meinen Code selbst er keine Basis weiß.

Tägliche Stand-Ups sind nicht dazu gedacht, darüber zu diskutieren, wie Sie eine Lösung implementiert haben.
@ DarrenYoung Ich habe die Frage bearbeitet.
Sollen Sie beide dasselbe tun, oder haben Sie deutlich unterschiedliche Verantwortlichkeiten? (dh einer von Ihnen ist Programmierer und der andere Designer?)
@Erik Ja, wir sind beide unterschiedliche Leute, aber er versucht es gerne, auch wenn es ein Bluff ist. Er möchte die Illusion vermitteln, Dinge zu wissen, obwohl er ein Lernender und 6 Jahre hinter mir ist.

Antworten (2)

seine "Einstellung" von "Wenn mein Ding nicht funktioniert. Lass es und mach deine Arbeit" schlägt bei mir Alarm.

Wieso den? Es liegt in der Verantwortung Ihres Kollegen, er versteht das Problem besser als Sie, weil er daran gearbeitet hat, und möchte seine Zeit nicht damit verbringen, Ihnen zu erklären, warum Ihre Lösung möglicherweise nicht zutrifft, wenn es Besseres zu tun gibt. Das ist natürlich eine Lektüre der Situation, es ist unmöglich, Ihre Situation aus einem einzigen Beitrag zu kennen.

Das Problem hier ist nicht, dass Sie geschätzt werden, sondern die Wahrnehmung Ihres Kollegen, dass Sie versuchen, sich in Dinge einzumischen, für die er verantwortlich ist.

Es ist ein Zeichen, dass ich mein Wissen nicht teilen oder zur Dokumentation beitragen sollte (wie mein Kollege es nicht tun würde und ich und mein PM die einzigen sind, die das tun).

Sie sollten Ihr Wissen teilen, wenn Sie um Rat gefragt werden, und Sie sollten die Dokumentation aktualisieren, wenn dies gerechtfertigt ist.

In einer früheren Frage von Ihnen wurde das Problem der unterschiedlichen Erwartungen von Ihnen und Ihrem Vorgesetzten angesprochen; Vielleicht ist die Zurückhaltung Ihres Kollegen, auf Ihren Rat zu hören, eine Manifestation des gleichen Problems.

Ich stimme dem zu. SCRUM-Meetings sollen kurz sein, ich selbst mag es nicht, wenn unsere Scrum-Meetings länger als 10 Minuten werden, das stiehlt Zeit und meistens muss ich Dinge hören, die mir für meine aktuelle Entwicklung wirklich egal sind. Wenn ich ein Problem habe, erwarte ich von meinen Kollegen, dass sie bei Bedarf helfen und nicht jedes Problem, mit dem sie konfrontiert sind, in den SCRUM-Meetings ansprechen
Die Idee, dass es „die Verantwortung Ihres Kollegen“ ist, passt nicht zu den Regeln von Scrum, die alle Arbeiten in die Verantwortung des gesamten Teams legen.
@Erik Ich kenne mich mit Scrum nicht aus. Ich bin skeptisch, dass dies mit einer sehr großen Codebasis funktionieren würde, aber ich denke, es ist für kleine oder Greenfield-Projekte oder für eine sehr frühe Übernahme machbar. Wie auch immer, ich gehe davon aus, dass das Team von OP SCRUM nicht genau befolgt.
Vermutlich nicht, da das OP Verweise auf Scrum aus seiner Frage entfernt hat. Ich werde meine Ablehnung entfernen, wenn sie nicht mehr gesperrt ist: /
Ich möchte hinzufügen, dass Sie für die Ausführung von Aufgaben bezahlt werden - eine davon ist es, Wissen zu teilen, wenn Sie dazu aufgefordert werden. Es ist unprofessionell, sich zu weigern, Wissen zu teilen, nur weil Sie jemanden nicht mögen oder das Gefühl haben, dass er Sie nicht genug schätzt. Sein mögliches unprofessionelles Verhalten ist zwischen ihm und seinem Vorgesetzten, es ist niemals eine Entschuldigung dafür, sich selbst nicht professionell zu verhalten.

Indem er Informationen zurückhält, schafft Ihr Kollege ein Bus-Faktor- Problem. Dies sollten Sie mit ihnen und/oder Ihrem Vorgesetzten besprechen. Es ist jetzt vielleicht nicht Ihre Verantwortung , aber wenn er im Urlaub ist (oder kündigt), müssen Sie immer noch in der Lage sein, für ihn einzuspringen, und er macht das schwieriger.

Das geht auch umgekehrt; Sie sollten freiwillige Informationen geben und die Dokumentation so weit wie vernünftigerweise möglich auf dem neuesten Stand halten. Nicht nur, damit es Ihrem Kollegen leichter fällt, einen Fehler in Ihrem Code zu beheben, wenn Sie gehen. Auch, weil es die Wahrscheinlichkeit verringert, im Urlaub angerufen zu werden. Sie möchten sicherstellen, dass andere Personen Ihre Aufgaben übernehmen können, wenn Sie andere Dinge zu tun haben.

Jedoch . Über das, was er tut, auf dem Laufenden zu bleiben, ist etwas ganz anderes, als seine Arbeit zu kritisieren. Stellen Sie sicher, dass Sie dies nur als „Ich würde gerne wissen, was Sie tun, falls ich eines Tages für Sie einspringen muss“ angehen und nicht als „Meine Zustimmung zu Ihrer Arbeit ist wichtig“. Sprechen Sie keine Probleme an, es sei denn, sie sind potenziell ruinös, und versuchen Sie selbst dann, es respektvoll zu tun.

Schaffen sie wirklich ein Bus-Faktor-Problem? Das OP ist schließlich kein Entwickler.
@NathanCooper aus den Kommentaren scheinen sie in der gleichen Branche tätig zu sein. (Zugegeben; das OP ist nicht sehr klar, was genau vor sich geht)
Sicher. Mir ist nur nicht ganz klar, was los ist.