我有機會在一個項目經理的工作下工作，他對項目所有權糾紛採取了一種有趣的方法：“ 當做主的時候，最好有一個普通的船長而不是兩個優秀的船長。”

看來項目所有權對您的同事來說確實很重要。為什麼不將其視為資產而不是負債？

讓您的同事被確認為項目所有者，並承擔所有附帶的責任。與您的經理和您的同事開會。按照“ 似乎很喜歡X同事的想法”的觀點去做。因此，為簡化起見，並為他們提供適當的所有權經驗（如有必要），讓他們接受吧-我會幫助您他們遵循並遵照他們在平台，庫，方法等方面的決定。儘管如此，下一個項目還是我的。交易嗎？

當他對您的請求提出建議或批評時，請解釋一下為什麼您不會更改它以匹配他的建議。它應該簡單明了。例如：

“這不會顯著改善代碼。”

“做出更改的努力沒有價值。”

“當前方法更簡單。”

如果他仍然拒絕接受拉取請求，請升級為管理人員。您可以通過電子郵件進行操作，例如：“拉動請求X已打開Y時間，仍在等待Z的批准。Z沒有給出足夠的理由拒絕拉動請求。”

強迫他成為一個延遲和乾擾的人，因為那是他在做什麼。指出他堅持不停地進行設計變更或拒絕及時批准拉動請求只是因為他們沒有按照他認為最好的方式來完成，這浪費了您的時間。

請注意，您只是在進行管理決定您的代碼是否可以接受，以及是否應接受拉取請求。您的代碼是否符合適用的標準，或者不符合。如果是這樣，則應接受。如果不是，那麼他是對的，而你是錯的。

我會請一位經理告訴他，不斷的爭論正在削弱效率。這是他必須解決的問題。

如果是我，我將嘗試拆分項目。試圖找到一個接口，並讓每個人都有自己的職責來管理。也許你可以建議。

通常，對他的任何建議提出異議或提出不同的建議都是一場艱鉅的艱鉅戰鬥。

有時這是正常的。在某些情況下，它實際上很有價值。您也應該具有這種信心。如果您做出決定，則應該準備好一路備份。

無論何時我不想做與他做的方式完全相同的事情，這似乎都是可以實現的，通常這是一個漫長而乏味的過程。

這可能是個問題。可能不會。有時，開發人員很難記住“有很多x種方法可以為foo蒙皮”。您可以嘗試與經理解決此問題。

例如，假設我選擇使用某個庫來完成某些任務。我將不得不向他證明其合理性，這本身就可以了，但是即使我可以證明其用法合理，也存在很高的抵抗力。

那是一件非常好的事情。 巨大的好東西。當我管理團隊時，每個新圖書館都需要進行大量討論。提倡使用圖書館的人必須證明其使用的合理性。必須有一個嚴肅的理由。如果您要迫使團隊中的每個人（以及曾經加入團隊的每個人）都使用這種新的依賴關係，那就值得了。因此，也許這是一個不好的例子。但是在計劃階段可以期望達到某種程度的“為您想要的東西而戰”。如果在“編碼”階段進行這些級別的調用，那對您不利。這些應該在編寫第一行代碼（針對新功能）之前進行，討論，決定等。對我而言，在編碼時添加依賴項是對請求請求的自動拒絕，然後是會議。然後嘗試確保下次在開始編寫代碼之前先對依賴項進行佈局。

通常，我不覺得自己有決策權，我認為應該理應這樣做；

您沒有，沒關係。團隊中沒有我。同樣，如果這些是實現級別的問題，則應予以說明。如果這些是計劃級別的問題，那麼就該準備好捍衛自己的方式了。

相反，我感覺我基本上只是他的助手。

現在是一個問題。你們兩個可能需要為拉取請求通過/失敗定義更好的指標。在什麼情況下可以通過？在什麼情況下會失敗？如果失敗，是否提供可操作的項目？

我一直使用的一條規則是，如果某人未能通過拉取請求，則他們必須提供可操作的項目以使請求可以通過。

失敗：測試無法通過，請修復代碼，以便測試通過失敗：代碼過於復雜，將復雜度降低到可接受的水平
失敗：該邏輯屬於模型，而不是控制器將其移至模型。
失敗：請勿使用類似x的迭代器，而應使用實數變量名，在這種情況下，請稱其為“用於條目輸入”而不是“用於條目e”

然後至少在查看時您可以在失敗消息中發起對話。

我的經理說他可以調停這些問題，但我感到這是不可思議的瑣事。

經理的工作是管理； 讓他們。如果您的經理厭倦了處理這些請求，那麼他將使它們停止。您的經理可能非常喜歡這種監督級別。

例如，假設我選擇使用某個庫來完成某些任務。我將不得不向他證明其合理性，這本身就可以了，但是即使我可以證明其用法合理，也存在很高的抵抗力。一般來說，我不認為自己擁有決策權，相反，我覺得我基本上只是他的助手。

在團隊/公司中，您沒有擁有決策的自主權；至少對於諸如選擇一項新技術，一個新庫，決定體系結構等高層決策而言……。

在團隊中開展項目時，您需要保持可替換。您隨時可能會乘公交車生病/撞車，另一個同事應該能夠挺身而出，並從您所在的地方繼續。

同事越熟悉您的工作，越好，這就是為什麼重要的原因：

• 您使用與公司中任何其他人相同的第三方庫，
• 您將項目的結構與項目中其他任何項目的結構相同公司，
• ...

當然，還有探索的空間。新的第三方圖書館，新的結構等可以改善現狀，但它們具有破壞性，因此，其收益應在很大程度上抵消其成本。這必須是部門/部門/公司的有意識的決定。儘管您可以擁護它，但這不是您的。

我們必須批准彼此的請求請求，因此，如果我做他不喜歡的事情，他可以選擇完全拒絕它，直到我更改它以滿足他的建議為止。如果我必須通過該功能，要么要么堅持自己的立場，花大量時間對其進行論證，要么我必須將其更改為他的建議，並繼續我的生活。

如果可以的話，我認為這裡存在工作方法問題。

應該在開始工作之前 討論高級設計；

p>這意味著 開始工作之前，您需要在總體方向上以團隊的形式達成共識。而且，如果中途發生了一些需要大刀闊斧的變化，那麼您需要作為一個團隊就從何處去達成一致。

注意：我見過有人爭相批准他們的PR，因為他們儘管對質量或設計有異議，但還是做了很多工作。看到您的努力遭到拒絕真是令人痛心...這就是為什麼最好事先進行討論。

所以，假設：

• 您已獲得技術，第三方庫和項目設計的管理批准，
• 您已事先就拉取請求的總體方向達成了共識。

然後在拉取請求本身應該集中在：

• 拋光邊緣情況，
• 清理實現，
• 弄清晦澀的地方。

在滿月中，您可能會收到諸如“哦，廢話，我們忘記記下案例X”之類的評論。它發生了。這是團隊錯誤。

這當然不能神奇地解決您的所有權問題。在關於拉取請求的總體方向的早期討論中，您的同事可能仍然很棘手。

通常，無論是否擁有所有權，您都需要達成共識。

em>。

因此，您的首要目標應該是了解您的同事為何會感到困難：

• 他的眼光是否有所不同？
• 他是理想主義者嗎？
• 他是個控制狂嗎？
• 他不信任你的技能嗎？
• ...

並嘗試與他解決問題。

您需要調整項目的遠景規劃，獲得他對您技能的信任，...

如果其他所有方法都失敗了，請作為最後的選擇 ^{1 sup>，您可能希望讓您的經理參與進來，並讓他劃分職責。您提到您和他具有不同的技能，因此您應該能夠將職責劃分為三個區域：他的區域，您的區域和一個公共區域。在你所在的地區，他的觀點純粹是有益的（反之亦然）。 >}

是否有更好的方法來解決此問題？

我想知道他是否認為每個決定都是二進制的：

1. 正確/正確（即我的方式）
2. 錯誤（即您的方式，不是我的方式，我不會那樣做）
ol>

我認為對決策進行分類很重要至少分為三個類別，而不是兩個類別：

1. 合格（我們都同意這很好）
2. 不可接受或不可接受（與提案相關的客觀，可識別的損害）
3. 足夠好或可以接受（例如，我不會按照您的建議那樣做，但是您所建議的內容足夠好，立即足夠並且總比沒有好）

我的代碼審查經驗之一是當我成為正式的網守（即團隊負責人或產品負責人）時，我記得我的代碼審查反饋有三個類別：

1. 這很好，可以辦理入住手續
2. 這還沒有準備好，您必須對此進行更改（我需要您您可以在辦理入住手續之前更改此內容）
3. 我明白您所做的一切，它可以正常工作；僅供參考，我不會那樣做，我會那樣做。您可以更改此設置（在簽入之前，按照我建議的方式進行操作）如果您想要但不必這樣做。

如果需要自治幫助，則必須具有第三類。

請注意，如果存在 “與提案相關的客觀，可識別的危害”，你們都應該能夠看到並同意傷害存在。如果仍然存在分歧，也許是權衡取捨，也許是您可以帶給產品經理的主題（例如，“老闆，我們應該使用並依賴第三方組件嗎？ ，或採用更多的此處未發明的政策？”。

或者附近有其他軟件開發人員？我曾經和一個經驗豐富的同齡人一起工作。我們將一對一地討論並確定我們的界面。在罕見的情況下，兩個人無法或不同意某件事，我們會邀請另一名（即第三名）開發人員參與討論（以尋求共識或多數決定）。 >