我們所有人都會遇到這種衝突。

唯一可以做的是一切都是文件

老闆是老闆並沒有錯直到他試圖將錯誤推向別人為止。退縮的最有效方法是執行以下操作。

• 記錄您在其方法中看到的缺陷
• 記錄在採用該方法時所看到的後果
• 提出一種替代方法
• 演示您的方法將如何緩解您提出的問題
• 分析每種方法的利弊
• 嚴格聲明
• 保存所有此文檔 ​​li>
• 遵循訂單。

然後，當它爆炸時，就採取這種方法。並且詢問您為什麼讓它發生，您可以回答您沒有。您記錄了建議的方法，即您被壓倒了並且成功地預測了不遵循方法的後果。

在這種情況下，您需要放開球以證明自己的觀點，但要一條紙跡，這樣就不會把責任推給您。

除了你們兩個分別擔任技術負責人和項目經理的角色外，還有一張他是您老闆的王牌。

所以您真的需要牢記這種動態-我是我不是說當你們兩個都不同意時不要提出您的理由，而是一旦您覺得自己已經提出了理由，那麼如果老闆仍然堅持他們的首選，那麼您只需要堅持下去即可。您需要對所討論的問題盡可能地保持情緒低落-從您的帖子中看來，您的老闆具有在這些討論中變得積極進取的形式，並且感覺很誘人/自然，您無法接受，因為那只會升級他的情緒反應並進一步挖掘他。如果他們的目標非常好，但是他們提出的方法是您遇到的問題，請確保反復強調您同意他們的目標，認真使用“我同意您”一詞“您可以在這裡這樣做，因為這可以消除這類討論可能發展出的對抗性氣氛。

如果您認為這樣做會對輸出質量產生嚴重的負面影響，那麼我將確保您通過CYA行動，通過電子郵件記錄您的疑慮（及相關後果），這不必是對抗性的事情或類似的事情-只需在問題仍在“討論中”的情況下將它們放在電子郵件中即可“例如：

您好，[老闆/ PM]，我在考慮我們正在討論的Widgetron 3000上的功能X，我知道您來自哪裡，我同意，如果我們可以使該功能正常工作，但我只是擔心，如果按照您的建議使用Unobtanium，可以導致磁通電容器變得不穩定？而且我們有可能導致更大的問題。如果我們改用Handwavium，那豈不是會讓我們仍然在沒有相同風險的情況下進行X功能嗎？

他們很可能不會聽這些話，如果他們下定決心，那麼他們幾乎肯定不會聽，但是他們可能會回應您，至少要否決他們，重要的是您已經有了這些顧慮，並且後果 和 ，隨後以書面形式將其解僱，並且如果將來有任何企圖怪罪您的行為，您可以指向該電子郵件鏈並表明您提出了這些後果並被否決。

如果您所進行的討論中存在混亂，這很可能導致混亂，並且您所暗示的糾結代碼已經在其中。聽起來好像您是將意大利面放在意大利面之上，並抱怨菜盤溢出。

根據項目的時間表，這可能是一個退後一步的好機會，對於你們倆重新評估總體情況。

回到核心需求，看看是否可以通過包裝所有小的臨時請求和錯誤來解決問題，並希望重新分析和重新編寫它們，並正確完成。

如果時間表不允許進行根本性的重新評估，請妥善處理最新的要求，並在可能的情況下盡其所能。然後讓錯誤在測試中出來。

然後，退後一步，看看較大的更改是否比迭代的固定修復程序更合適。

這聽起來像是您想讓一切變得平淡無奇。更好的方法是告訴他，以適當的質量水平安全地完成他想要的工作將需要什麼。

該代碼確實很難更改而不會中斷。為了處理這些極端情況，我們將需要花幾個星期在該區域周圍添加一些測試，並首先進行一些重構和清理。否則，以後修復錯誤的時間將是完全不可預測的。這樣一來，我們應該可以在一周左右的時間內實施邊緣案例，並且充滿信心。

不要撒謊或增加您的估計。盡可能準確。做一個真誠和支持的團隊成員。你不是說不您是在說：“是的，當然，我在船上。這就是我們的工作方式。”然後，他知道包括技術債務在內的實際成本，並且他可以決定是否仍然值得，以及與其他優先事項相比，它是否真正適用。

此技術可以真正有效。我首先在養育子女的背景下學習了它，並且在各種看似僵持的情況下都可以使用。總而言之，問問自己，要接受是什麼。答案幾乎是一無所有，而您也會驚訝於對方也願意承認。

正如我從您的描述中所看到的那樣，您的PM負責需求，而您負責實施。即使在快速的過程中（如敏捷/敏捷），也應始終記錄需求。較少的文檔，而不是更多，那是一個嚴重的危險信號。 PM應該從客戶那裡獲取需求，索要您的需求，並要求這些需求的文件化實現（單元測試，系統測試，演示等）與職能經理進行討論，他們的職責是幫助您完成工作工作。如果您的PM是職能部門，那麼這現在是人事問題，您應該與人事代表聯繫。不要將其表示為投訴，而是要解決的一個問題，以便每個人都可以恢復工作。

也就是說，從您的帖子和評論中，您似乎有多個出現紅旗，則您應該查看公司的以下政策，並用它們指導您：道德/行為準則，無威脅的工作場所，無暴力的工作場所和無騷擾的工作場所。

項目經理負責什麼，而您負責如何。關鍵是要清楚表明您所做的更改是 how 的一部分，而不是 what 的一部分。

例如PM需要功能X。您要進行更改您只需說：

為了交付X，我們需要A，B和C在適當的位置。我們必須先交付A，B和C，然後才能交付X。

請清楚X要求A，B和C。如果PM想要X，則PM得到A，B和C太。不要講太多細節。 PM不是技術人員，也不希望理解X為何依賴A，B和C。

如果X確實不依賴於A，B和C，則不要使用這種方法。

請記住，沒有人想要損壞的軟件，甚至是PM。

“我擔心他的想法會對應用程序有害，因為通過修復極端情況將導致一系列新的錯誤，並且代碼庫的質量也會受到影響。因此，我試圖改變了幾次主意，但他的立場變得越來越激進，幾乎被口頭辱罵。”

您還沒有清楚表明總理正在進入技術領域。在PM的職權範圍內，決定程序需要絕對正確地處理極端情況。確保這樣做不會導致一系列新的錯誤，這實際上是您的工作。

我認為您希望留在您的專業領域是正確的。在這種情況下，有時會有一些重疊。您仍然可以確保仍然解決您在技術方面的顧慮。儘管您可能沒有做出最終決定，但重要的是您仍然必須識別並強調（如果需要）PM通過接受或忽略某些權衡而承擔的風險。在這種情況下，您可以使用這些功能，但是有可能使將來的更改變得更加困難，它們將花費更長的時間，並且可能會有更多的錯誤。

最後，您是在提出建議總理正在做決定。希望您的責任等級與您的權限等級成比例。

我是一名高級開發人員，實際上，我同時擔任技術項目經理和團隊負責人的角色。我對您的問題的看法更多是從項目經理方面來考慮的。

在我的情況下，這是一個初級開發人員，一直在質疑和挑戰我對項目所做的決策。

有時候，我們會就功能和範圍進行激烈的討論，最終我到達了無法再處理的地步。我沒有鼓勵他貢獻自己的想法，而是在他開始之前就把他關閉了。試圖滿足我對自己的看法的願望變得越來越筋疲力盡和費時，我開始質疑他是否適合團隊。

解決方案仍然沒有發生，但是我的初級開發人員在過去幾週內已經大大改善了他的態度。

我所做的是清楚地定義他的角色和職責，並開始將他不再像一個夥伴，而更像是開發人員的PM。當他現在開始挑戰我時，我只允許他走得那麼遠，然後我說：“決定這不是您的責任。”

雖然您的處境大不相同，但我您的答案是：

在無法解決的個人問題上，您無法解決任何技術問題。

坐下來與他交談。對您說過的話或做過的事情本來可以做得更好表示歉意。我知道這很困難，但是通過您打破僵局，它也為您的同事提供了道歉的途徑。 （他可能不會，但是至少您之間的虛擬牆中的幾塊磚將被拆除）。強調您希望作為一個團隊來工作，並且您確實希望該項目能夠像他一樣成功。

一旦您解決了這個問題，就可以開始處理技術問題。這裡有一些指針：

1. 我和你，而不是我對你：論點應該沒有失敗者，只有2個獲勝者。如果您從雙方都應該贏得的態度和目標開始，那麼實際上就沒有爭執，項目/任務將會成功。
2. 一次處理一個問題 ：說“我想與您見面討論____”，然後堅持下去...不要提出其他問題。如果他向您詢問其他問題領域，只需說些類似的話：“我還不准備討論這個問題”
3. 爭取勝利：不要太著急房間裡的大象。處理較小的問題，並建立一種可以在解決任何主要問題之前就可以一起工作的模式。
4. 做好準備：“您要求我以這種方式實施此功能，我只是想向您展示我提出了費用估算，因此可能需要XXX小時才能完成現在，我確實還有其他一些想法可以實現目標，但實現起來可能更容易，成本也更低。“
5. 聽他的話：如果您只是專注於在接下來要說的內容上，或者在玩手機時...對他來說，很明顯，您沒有在聽。想像一下，你們倆都站在河的對岸，並且有一個您從未在空中漂浮過的物體。您永遠不會看到他的身邊，因為您無法越過河，所以您有自己的見識，而他有他的。但是你可以聽他描述他所看到的。您還可以通過上下行走來研究物體，以從側面獲得不同的視角。持不同意見並沒有錯，但是通過傾聽，您可以開始欣賞他的觀點。
6. 休息片刻：在您的會議中，如果某些問題仍未解決並且事情變得越來越熱烈...請稍事休息。
7. 不要只專注於消極情緒：如果您專注於百萬個為什麼他的想法行不通的原因，他會感到被破壞和一文不值。如果您從讚美您喜歡他的想法開始，他將更願意妥協。與其說“我不會因為……”之類的話，不如說成一個問題……“是的，我認為那可能行得通，但是____呢？”
8. 接受您可能未掌握所有信息的信息：PM可能知道有些事情無法向您解釋。原因可能從機密到對他的部分缺乏理解（而這令人感到羞恥）。在某些時候，您確實必須接受他的決定。
9. 寬恕：有一種說法：寬恕是您吞下的一種毒藥，希望其他人從中喪生。我妻子從15年前開始撫養孩子。但是我們去參加一場婚姻座談會，讓過去的痛苦消失了。如果發生了30多天前傷害您的事情，請嘗試放開它。
ol>

我的建議很簡單：

1）對邊緣案例的實現表示關注，並確保以清晰簡潔的方式記錄它們。

2 ）聽聽項目經理的回應。如果您認為他有誤解，請澄清一點。

3）如果項目經理仍希望在應用程序中添加邊緣案例，請將其添加到實現中。

4）刪除除非有新的或相關的信息公開，否則就這一點進行討論。

5）與討論之前一樣，繼續關注新的邊緣案例，並像以前一樣關注代碼的質量。

我不知道您是誰生產，但我確實知道開發人員通常喜歡乾淨易管理的代碼。我從您的問題中得知，處理極端情況會增加代碼庫的複雜性，這將使代碼維護更加困難，並增加項目風險。對於應用程序的最終用戶而言，這可能很重要，儘管對它們的處理會使代碼庫更加難以遵循，並且維護邊緣情況的處理可能確實是必需的。許多人會忘記該軟件何時能夠正常運行，但是他們可以告訴您該軟件沒有按照其期望的次數運行。

最後，從您的角度來看，項目經理負有最終責任。如果他為邊緣情況做出決定，那是他的責任。您有責任盡最大可能實施邊緣案例和應用程序。

必須閱讀，認為您的老闆是其中之一： https://zh.wikipedia.org/wiki/Psychopathy_in_the_workplace

這意味著您應該以自己的速度跑可以或開始一場會花費很多錢的戰鬥，即使您獲勝而他離開也不會給您帶來什麼好處。

如果您無法讓高層人士看到情況並進行糾正，您應該自己找一份新工作來糾正它。