Ich hatte die Gelegenheit, unter einem Projektmanager zu arbeiten, der einen interessanten Ansatz für Projektbesitzstreitigkeiten hatte: " Wenn es Zeit ist, das Sagen zu haben, ist es besser, einen durchschnittlichen Kapitän als zwei ausgezeichnete zu haben. "

Es scheint, dass Projektverantwortung für Ihren Mitarbeiter wirklich wichtig ist. Warum behandeln Sie es nicht als Vermögenswert statt als Verbindlichkeit?

Lassen Sie Ihren Mitarbeiter als Projektbesitzer mit allen damit verbundenen Verantwortlichkeiten anerkennen. Treffen Sie sich mit Ihrem Manager und Ihrem Kollegen. Gehen Sie mit etwas in der Art von " scheint, dass Mitarbeiter X hier wirklich gerne Eigentümer wird. Um die Dinge zu vereinfachen und ihnen die richtige Eigentümererfahrung zu geben [falls erforderlich], lassen Sie sie diese übernehmen - ich werde helfen Sie begleiten und verschieben ihre Entscheidungen über Plattform, Bibliotheken, Ansätze und dergleichen. Das nächste Projekt gehört jedoch mir. Deal? "

Positive Aspekte dieses Ansatzes:

• Sie werden als Teamplayer betrachtet, der die Begeisterung anderer Teamkollegen akzeptiert und ihnen die Möglichkeit gibt, sich zu beweisen, während ein Stressfaktor beseitigt wird.
• Wenn Sie offiziell auf dem Rücksitz sitzen, werden Sie entschuldigt Konstruktionsfehler (Sie können Ansätze vorschlagen, aber die endgültige Entscheidung liegt nicht bei Ihnen)
• Wenn sowohl der Manager als auch der Mitarbeiter Ihr Eigentum für das nächste Projekt akzeptieren, haben Sie eine solide Grundlage für die Verwendung von ' Lassen Sie uns diesmal mit meinem Ansatz weitermachen, Ok? 'Argument, wenn Sie an der Reihe sind, Spezifikationen festzulegen;
• Die Implementierung einer Lösung unter der Vision Ihres Kollegen wird dies beweisen Stellen Sie sich eine andere Sichtweise vor, wie Sie mit Projektdefinitionen umgehen sollen.

Wenn er einen Vorschlag oder eine Kritik zu Ihrer Pull-Anfrage macht, erklären Sie einmal, warum Sie ihn nicht ändern werden, um ihn seinem Vorschlag anzupassen. Es sollte einfach und klar sein. Beispiel:

"Das würde den Code nicht wesentlich verbessern."

"Der Aufwand für diese Änderung ist nicht durch seinen Wert gerechtfertigt."

"Die aktuelle Methode ist einfacher."

Wenn er die Pull-Anforderung immer noch nicht akzeptiert, eskalieren Sie zur Verwaltung. Sie können dies per E-Mail tun, zum Beispiel: "Die Pull-Anfrage X war für Y-Zeit geöffnet und wartet noch auf die Genehmigung von Z. Z hat keine ausreichenden Gründe für die Ablehnung der Pull-Anfrage angegeben."

Erzwingen Sie ihn derjenige zu sein, der verzögert und sich einmischt, denn das ist es, was er tut. Weisen Sie darauf hin, dass sein Beharren auf ständigen Designänderungen oder seine Weigerung, Pull-Anfragen rechtzeitig zu genehmigen, nur weil sie nicht so ausgeführt werden, wie er es für am besten hält, Ihre Zeit verschwendet.

Beachten Sie, dass Sie einfach zum Management gehen um zu entscheiden, ob Ihr Code so wie er ist akzeptabel ist oder nicht und ob die Pull-Anfrage akzeptiert werden soll oder nicht. Entweder entspricht Ihr Code den geltenden Standards oder nicht. Wenn ja, sollte es akzeptiert werden. Wenn nicht, hat er Recht und Sie liegen falsch.

Ich würde einen Manager hinzuziehen und ihm sagen, dass die ständigen Argumente die Effizienz beeinträchtigen. Dies muss er klären.

Wenn ich es wäre, würde ich versuchen, das Projekt aufzuteilen. Der Versuch, eine Schnittstelle zu finden und jedem seinen eigenen Teil zur Verwaltung zu geben. Vielleicht können Sie das vorschlagen.

Oft ist es ein harter Kampf, einen seiner Vorschläge zu bestreiten oder einen anderen vorzuschlagen.

Manchmal ist dies normal. In einigen Fällen ist es tatsächlich wertvoll. Sie sollten auch dieses Maß an Vertrauen haben. Wenn Sie eine Entscheidung treffen, sollten Sie bereit sein, diese vollständig zu sichern.

Dies scheint immer dann zu tun zu sein, wenn ich etwas nicht genau so machen möchte, wie er es tun würde, und ist normalerweise ein langer und langwieriger Prozess.

Dies kann ein Problem sein. Es darf nicht. Manchmal fällt es Entwicklern schwer, sich daran zu erinnern, dass es mehr als x Möglichkeiten gibt, ein Foo zu häuten. Sie können versuchen, dieses Problem mit Ihrem Manager zu lösen.

Angenommen, ich verwende eine Bibliothek, um eine Aufgabe auszuführen. Ich werde es ihm gegenüber rechtfertigen müssen, was für sich genommen in Ordnung ist, aber es gibt ungewöhnlich hohen Widerstand, selbst wenn ich seine Verwendung rechtfertigen kann.

Das ist eine sehr gute Sache. Eine große gute Sache. Wenn ich ein Team leite, erfordert jede neue Bibliothek eine RIESIGE Diskussion. Die Person, die die Nutzung der Bibliothek befürwortet, muss ihre Nutzung begründen. Es muss eine ernsthafte Rechtfertigung geben. Wenn Sie jeden in Ihrem Team - und jeden, der jemals Ihrem Team beitritt - dazu zwingen, diese neue Abhängigkeit zu nutzen, lohnt es sich besser. Vielleicht ist das ein schlechtes Beispiel. In den Planungsphasen ist jedoch ein gewisses Maß an "Kampf um das, was Sie wollen" zu erwarten. Wenn Sie diese Anrufstufen während der "Codierungs" -Phase tätigen, ist das schlecht für Sie. Diese sollten lange vor dem Schreiben der ersten Codezeile (für die neue Funktion) erstellt, diskutiert, entschieden usw. worden sein. Das Hinzufügen einer Abhängigkeit zur Codierungszeit ist für mich eine automatische Ablehnung einer Pull-Anforderung, gefolgt von einer Besprechung. Dann ein Versuch, beim nächsten Mal sicherzustellen, dass wir die Abhängigkeiten auslegen, bevor wir mit dem Schreiben von Code beginnen.

Im Allgemeinen habe ich nicht das Gefühl, meine eigene Autonomie bei der Entscheidungsfindung zu haben. was meiner Meinung nach gewährt werden sollte;

Sie tun es nicht und das ist in Ordnung. Es gibt kein Ich im Team. Auch hier sollten Probleme auf Implementierungsebene erläutert werden. Wenn es sich um Probleme auf Planungsebene handelt, ist es Zeit, bereit zu sein, Ihren Weg zu verteidigen.

Stattdessen fühle ich mich im Grunde genommen nur als sein Assistent.

Nun dies ist ein Problem. Möglicherweise müssen Sie beide bessere Metriken für das Bestehen / Nichtbestehen einer Pull-Anforderung definieren. Unter welchen Bedingungen ist ein Pass? Unter welchen Bedingungen ist ein Fehler? Wenn es fehlschlägt, werden umsetzbare Elemente angegeben?

Eine Regel, die ich immer verwende, lautet: Wenn jemand eine Pull-Anforderung nicht besteht, muss er umsetzbare Elemente angeben, um die Anforderung passierbar zu machen.

Fehler: Tests werden nicht bestanden, Code wird korrigiert, sodass Tests bestanden werden. Fehler: Code ist zu komplex. Reduzieren Sie die Komplexität auf ein akzeptables Maß.
Fehler: Diese Logik gehört zum Modell, nicht der Controller verschiebt sie in das Modell .
Fehler: Verwenden Sie keine Iteratoren wie x, verwenden Sie echte Variablennamen. In diesem Fall nennen Sie es "für die Eingabe in Einträgen" und nicht "für e in Einträgen".

Dann zumindest beim Betrachten In der Fehlermeldung haben Sie einen Ort, an dem Sie ein Gespräch beginnen können.

Mein Manager hat gesagt, dass er damit einverstanden ist, diese zu vermitteln, aber es fühlt sich für mich unglaublich kleinlich an.

Die Aufgabe des Managers besteht in der Verwaltung. LASSEN SIE SIE . Wenn Ihr Manager es leid ist, diese Anfragen zu bearbeiten, lässt er sie aufhören. Ihr Manager kann dieses Maß an Kontrolle sehr wohl bevorzugen.

Angenommen, ich verwende eine Bibliothek, um eine Aufgabe auszuführen. Ich werde es ihm gegenüber rechtfertigen müssen, was für sich genommen in Ordnung ist, aber es gibt ungewöhnlich hohe Widerstände, selbst wenn ich seine Verwendung rechtfertigen kann. Im Allgemeinen habe ich nicht das Gefühl, eine eigene Entscheidungsautonomie zu haben, die meiner Meinung nach gewährt werden sollte. Stattdessen fühle ich mich im Grunde genommen nur sein Assistent.

In einem Team / Unternehmen haben Sie nicht Ihre Autonomie bei der Entscheidungsfindung. Zumindest nicht für Entscheidungen auf hoher Ebene wie die Auswahl einer neuen Technologie, einer neuen Bibliothek, die Entscheidung über die Architektur, ...

Wenn Sie in einem Team an einem Projekt arbeiten, müssen Sie sein austauschbar . Sie könnten jederzeit von einem Bus krank / angefahren werden, und ein anderer Mitarbeiter sollte in der Lage sein, von Ihrem Standort aus weiterzumachen.

Je vertrauter der Mitarbeiter mit Ihrer Arbeit ist, desto besser. Aus diesem Grund ist es wichtig, dass:

• Sie dieselben Bibliotheken von Drittanbietern wie alle anderen im Unternehmen verwenden,
• Sie Ihr Projekt genauso strukturieren wie jedes andere Projekt in der Unternehmen,
• ...

Natürlich gibt es Raum für Erkundungen. Eine neue Bibliothek von Drittanbietern, eine neue Struktur usw. können das Statu Quo verbessern, aber sie sind störend, und daher sollten ihre Vorteile ihre Kosten weitgehend ausgleichen. Dies muss eine bewusste Entscheidung seitens der Abteilung / Abteilung / Firma sein. Es ist nicht dein zu machen, obwohl du es verfechten kannst.

Wir müssen uns gegenseitig die Pull-Anfragen genehmigen, wenn ich etwas tue, das er nicht mag, Er hat die Möglichkeit, es sofort abzulehnen, bis ich es ändere, um seinen Vorschlägen zu entsprechen. Wenn ich dieses Feature durchstehen muss, muss ich mich entweder behaupten und viel Zeit damit verbringen, es zu rechtfertigen, oder ich muss es einfach in das ändern, was er vorschlägt, und mit meinem Leben weitermachen. Ein bisschen ein Stein und ein harter Ort

Wenn ich darf, denke ich, dass es hier ein Problem mit der Arbeitsmethode gibt.

Hochrangiges Design sollte vor Beginn der Arbeit besprochen werden. Es ist nur Zeitverschwendung, eine Woche lang an etwas zu arbeiten, es zur Genehmigung vorzulegen und es mit dem Grund "Warten Sie, haben Sie die Interaktion mit X in Betracht gezogen? Es wird nie funktionieren!" abzulehnen.

Dies bedeutet, dass bevor mit der Arbeit begonnen wird, Sie sich als Team auf eine allgemeine Richtung einigen müssen. Und wenn sich auf halbem Weg etwas ergibt, das eine drastische Änderung erfordert, müssen Sie sich als Team darauf einigen, wohin Sie von hier aus gehen sollen.

Hinweis: Ich habe Leute gesehen, die sich dafür ausgesprochen haben, ihre PR zu genehmigen, weil sie hatte viel Arbeit, trotz der Einwände gegen seine Qualität oder Design. Es tut weh, wenn Ihre Bemühungen abgelehnt werden. Deshalb ist es am besten, die Dinge vorher zu besprechen.

Nehmen wir also an:

• Sie Haben Sie die Genehmigung des Managements für Technologien, Bibliotheken von Drittanbietern und Projektdesign.
• Sie haben sich zuvor auf die allgemeine Richtung der Pull-Anfrage geeinigt.

Dann die Diskussion über die Die Pull-Anforderung selbst sollte sich auf Folgendes konzentrieren:

• Polieren der Randfälle,
• Bereinigen der Implementierung,
• Klären der undurchsichtigen Bits.

Sobald Sie sich in einem blauen Mond befinden, erhalten Sie möglicherweise einen Kommentar wie "Oh Mist, wir haben vergessen, Fall X zu berücksichtigen". Es passiert. Es ist ein Teamfehler.

Dies löst Ihr Besitzproblem natürlich nicht auf magische Weise. Ihr Mitarbeiter ist möglicherweise während der frühen Diskussion über die allgemeine Richtung der Pull-Anforderung immer noch unlösbar.

Im Allgemeinen spielt es keine Rolle, ob jemand "Eigentümer" ist oder nicht. em>.

Ihr erstes Ziel sollte daher sein, zu verstehen, warum Ihr Mitarbeiter schwierig ist:

• hat er eine andere Vision?
• ist er Idealist?
• ist er ein Kontrollfreak?
• vertraut er nicht Ihren Fähigkeiten?
• ...

und versuchen Sie, das Problem mit ihm zu lösen.

Sie müssen sich auf die Vision auf hoher Ebene für das Projekt einstellen, sein Vertrauen in Ihre Fähigkeiten gewinnen, ...

Wenn alles andere fehlschlägt, als letzter Ausweg ^{1 sup> möchten Sie möglicherweise Ihren Manager einbeziehen und ihn die Verantwortlichkeiten aufteilen lassen. Sie haben Sie erwähnt und er hatte unterschiedliche Fähigkeiten, daher sollten Sie in der Lage sein, die Verantwortlichkeiten in drei Bereiche aufzuteilen: seinen Bereich, Ihren Bereich und einen gemeinsamen Bereich. In Ihrer Region wäre seine Meinung rein informativ (und umgekehrt).}

^{1 sup> Und ich meine zuletzt, Konfrontation macht die Leute sauer.}

Gibt es eine bessere Möglichkeit, damit umzugehen?

Ich frage mich, ob er glaubt, dass jede Entscheidung binär ist:

1. Richtig / richtig (dh mein Weg)
2. Falsch (dh dein Weg, nicht mein Weg, ich hätte es nicht so gemacht)
ol>

Ich denke, es ist wichtig, Entscheidungen zu kategorisieren in mindestens drei Eimer anstatt in zwei:

1. Einverstanden (wir sind uns beide einig, dass dies gut ist)
2. Unangenehm oder inakzeptabel (mit einem Vorschlag ist ein objektiver, identifizierbarer Schaden verbunden)
3. Gut genug oder akzeptabel (z. B. hätte ich es nicht so gemacht, wie Sie es vorschlagen, aber was Sie vorschlagen, ist gut genug, sofort angemessen und besser als nichts)

Eine meiner Erfahrungen mit Codeüberprüfungen war, als ich der formelle Gatekeeper war (dh Teamleiter oder Produktbesitzer), und ich erinnere mich, dass mein Feedback zur Codeüberprüfung drei Kategorien hatte:

1. Dies ist gut, bereit zum Einchecken
2. Dies ist noch nicht ganz fertig, Sie müssen dies ändern (ich benötige yo u um dies zu ändern) vor dem Einchecken
3. Ich sehe, was Sie getan haben, es funktioniert; Zu Ihrer Information, ich hätte es nicht so gemacht, ich hätte es anders gemacht; Sie können dies ändern (vor dem Einchecken, um es so zu machen, wie ich es vorgeschlagen habe) wenn Sie möchten, dies aber nicht müssen.

Diese dritte Kategorie ist notwendig, wenn Sie autonome Hilfe benötigen.

Beachten Sie, dass dann objektiver, identifizierbarer Schaden mit einem Vorschlag verbunden ist Sie sollten beide sehen und zustimmen können, dass Schaden besteht. Wenn es immer noch Meinungsverschiedenheiten gibt, handelt es sich möglicherweise um einen Kompromiss, und möglicherweise ist ein Thema, das Sie dem Produktmanager vorlegen könnten (z. B. "Chef, sollten wir eine Komponente eines Drittanbieters verwenden und von dieser abhängig sein" , oder eher eine hier nicht erfundene Richtlinie übernehmen? ").

Gibt es alternativ einen anderen Softwareentwickler in der Nähe? Ich habe mit einem kleinen Team erfahrener Kollegen gearbeitet. Wir haben uns persönlich unterhalten, um unsere Schnittstellen zu besprechen und zu entscheiden. In der seltenen Situation, in der sich zwei Personen auf etwas nicht einigen konnten oder nicht, haben wir einen anderen (dh einen dritten) Entwickler in die Diskussion einbezogen (um einen Konsens oder eine Entscheidung mit der Mehrheit zu finden).