Wie soll ich mit dem Vorgesetzten meines Chefs ein „One on One“ angehen, wenn es Probleme mit dem Projekt gibt?

Ich würde vorschlagen, wenn Sie die Zeit vor dem "großen Treffen" haben:

1) Führen Sie eine gründliche (oder zumindest nicht zu oberflächliche) Bewertung des Codes durch, um die Blöcke in Ihrem Code, die „schlecht riechen“, richtig zu identifizieren, den Grund zu ermitteln, warum er schlecht ist, und wie er „behoben“ werden kann (bzw warum es repariert werden muss). Ihrem Chef einfach zu sagen „es ist schlecht, es stinkt“ ist ein großes NEIN, aber es ist auch schlecht zu sagen „es ist schlecht“ und nicht in der Lage zu sein, einen guten Grund dafür geltend zu machen, warum es schlecht ist.

2) Gehen Sie zu Ihrem Chef (direkter Chef) und sprechen Sie solche Bedenken bezüglich des Kodex an. Es wäre ein schwerwiegender Vertrauensbruch, wenn Sie ohne sein Wissen über ihn hinausgehen, und kann schlecht aufgenommen werden, wenn Sie nicht zuerst mit ihm darüber sprechen, um zumindest eine „Vorwarnung“ über das Problem zu geben. Wenn es sich um eine Teamentwicklung handelt und Sie dies als erster bemerkt haben, sollten Sie dies in einem Gruppentreffen ansprechen, jedoch nicht, bevor Sie mit Ihrem Chef gesprochen haben.

3) Wenn ein solches Treffen schief geht, können Sie sich an den Chef Ihres Chefs wenden und ihn über die Probleme informieren, aber tun Sie es auf eine Weise, die das vorliegende Problem anspricht, ohne in ein „Schuldspiel“ abzugleiten, geben Sie einfach Ihre Erkenntnisse darüber weiter den Code, und wenn Sie gefragt werden, bereiten Sie ein kleines Schema "Wie würden Sie es beheben" vor.

Als Sie diesem Projekt beigetreten sind oder es übernommen haben, sollten Sie diese Diskussion mit dem vorherigen Entwickler (Ihrem Chef) geführt haben. Wenn er dieses Framework nur einmal durchlaufen hat, gibt es natürlich eine Menge Refactoring zu tun. Das wird wahrscheinlich keine große Überraschung sein.

Sie haben den Vorteil, im Nachhinein zu sehen, also gehen Sie nicht davon aus, dass Ihr Chef aufgrund des aktuellen Status des Codes ein schlechter Programmierer ist. Niemand schreibt perfekten Code oder irgendetwas anderes im ersten Entwurf. Sie haben Sie angeheuert, um hereinzukommen und die Dinge auf die nächste Ebene zu bringen. Wenn Sie genügend Zeit haben, könnte Ihr Chef die Dinge wahrscheinlich aufräumen.

Auf der anderen Seite, wenn Ihr Chef Ihnen vorschlägt, den Code zu ignorieren, weil „es gut genug funktioniert“, könnten Sie ein Problem haben. Dies könnte Ihre Arbeit erschweren, wenn Sie versuchen, neue Funktionen (Einheitentests?) zu debuggen und hinzuzufügen. Nicht jeder steht auf Iterationen, sauberen Code oder das neue Klischee – Eleganz.

Finden Sie die Punktzahl heraus, bevor Sie versuchen, den Gewinner auszuwählen.

Eine äußerst zeitgemäße Antwort wurde heute in einem LinkedIn-Blog veröffentlicht, der von Steve Sinofsky geschrieben wurde, der bis vor einigen Monaten President der Windows-Division bei Microsoft war, mit dem Titel Benefitting from skip-level 1:1s - tips and pitfalls . Etwa die Hälfte davon ist für Manager, die das Meeting leiten. Überspringen Sie dies nicht: Lesen Sie es durch, damit Sie ein Gefühl dafür bekommen, welche Ziele der Vorgesetzte Ihres Vorgesetzten mit diesem 1:1-Gespräch mit Ihnen verfolgen könnte.

Die andere Hälfte des Blogbeitrags ist für Sie als einzelnen Beitragenden, der zu diesem Treffen geht, und darin steckt viel Weisheit, beginnend damit:

Ein Sprunglevel 1:1 ist eine großartige Zeit, um Ihre Perspektiven darzulegen, was gut läuft und was nicht. Es ist ein schmaler Grat zwischen all den potenziell schlechten Nachrichten anzubieten und so zu klingen, als würden Sie Erwartungen wecken, und all den potenziell guten Nachrichten aufzupolieren und so zu klingen, als würden Sie angeben. Du musst der Richter sein.

Ich denke, das gilt für jedes Meeting. Sie müssen in der Lage sein, zu erkennen, was gut läuft und was nicht gut läuft. Sie könnten zum Beispiel sagen: „Es ist gut, für einen Manager zu arbeiten, der den Code so gut kennt wie mein Manager“ oder „Ich denke, wir haben gute Arbeit geleistet, um die erste Version des Frameworks fertigzustellen, und ich Ich hoffe, dass wir die Zeit haben, zurückzugehen und sicherzustellen, dass die Architektur des Codes [etwas Wichtigem: Skalierbarkeit, erhöhte Leistungsanforderungen usw. standhalten wird – wählen Sie anhand Ihrer Codegerüche einen Bereich aus, der Anlass zur Sorge gibt]“.

Sinofsky weist auch darauf hin, dass man bei dieser Art von Treffen niemals Schlagzeilen machen sollte. Dieses Treffen ist nie der erste Ort, an dem Sie Bedenken äußern sollten. Er schließt damit:

Nutzen Sie vor allem die Zeit, um sicherzustellen, dass Ihr Skip-Level-Manager auf neutrale und konstruktive Weise mit Ihnen und Ihrer Arbeit vertraut ist.

Ich würde hier zu viel Fingerspitzengefühl und Ehrlichkeit raten, und das muss mit einem Gespräch mit Ihrem Chef darüber beginnen, ob Sie die bestehenden Rahmenbedingungen ändern dürfen. Lassen Sie mich noch einmal erklären, dies taktvoll zu tun! Hier sind einige Ideen, die funktionieren könnten:

• Verwenden Sie nicht viele negative Begriffe, wenn Sie sich auf die vorhandene Arbeit beziehen.
• Gestalten Sie alle Ihre Vorschläge als Änderungen, die Ihnen in Zukunft Updates oder Wartung erleichtern oder die es anderen neuen Programmierern erleichtern könnten, das Projekt später aufzunehmen. Sie wären hier der Experte, da Sie der Erste sind, der das tun muss.
• Machen Sie deutlich, dass Sie ihm diese Ideen zur Genehmigung vorlegen und seine Expertenmeinung einholen.

Stellen Sie sicher, dass Sie eine Art offizielles Projekt anfordern, damit es nicht so aussieht, als würden Sie vermasseln oder bei Ihren anderen Projekten nur langsam vorankommen.

Treffen mit dem Chef Ihres Chefs - wieder Takt und Ehrlichkeit.

Ein Teil der inoffiziellen Stellenbeschreibung eines Mitarbeiters besteht darin, seinen Chef gut aussehen zu lassen. Sie sollten Ihr Bestes tun, wenn Sie es ehrlich können, aber der Chef Ihres Chefs braucht die Wahrheit, um die besten Entscheidungen zu treffen. Stellen Sie sicher, dass alles Negative, das Sie über den Code oder das Projekt sagen könnten, zuerst mit Ihrem Chef besprochen wurde, und berichten Sie basierend auf der Entscheidung Ihres Chefs. Wieder einige Dinge, die nützlich sind:

• Versuchen Sie, das zugrunde liegende Ziel des Meetings so früh wie möglich zu bestimmen. Wenn der Chef Ihres Chefs nach Schmutz über Ihren Chef sucht, müssen Sie entscheiden, ob Sie wirklich die Quelle dafür sein wollen, und entsprechend handeln.
• Wenn es sich um ein Kennenlerntreffen handelt, verweilen Sie nicht bei diesen Dingen und versuchen Sie, eine gute persönliche Verbindung herzustellen.
• Versuchen Sie, Ihren Chef so gut wie möglich aussehen zu lassen, aber stellen Sie sicher, dass Sie sich dafür nicht unter Wert verkaufen
• Versuchen Sie so zu tun, als ob Ihr Chef im Nebenzimmer zuhört.

Die Befehlskette wurde umgangen, was ein Manager viel einfacher tun kann als ein Mitarbeiter. Ich schlage vor, dass Sie (nach bestem Wissen und Gewissen) so handeln, als ob es nicht der Fall gewesen wäre, und Ihren Chef vorher einschalten (und wahrscheinlich nach) dem Treffen mit dem Chef Ihres Chefs.