漫畫：程式設計師，你能“管理”好你的產品經理嗎？
一、第三選擇
在工作中，你面對產品經理的各種需求變動、專案經理對關鍵點的 Deadline，總會有一些衝突發生。而對於事情最終執行的開發人員來說，如果這些衝突處理的不好，可能就會變成你個人的問題。
做為最終實現功能的程式設計師，你總不會想被貼上一個 “無法按時完成任務的開發” ，這樣的標籤吧？
這些問題，其實都可以借鑑第三選擇的思想來解決。《第三選擇》是一本書，作者是 史蒂芬·柯維，我想說到該作者的另外一本書，應該更多人能知道，《高效能人士的七個習慣》。而在《第三選擇》中，他把之前的七個習慣濃縮成一件事情，可以說，第三選擇是解決所有難題的關鍵思維。
當我們面對衝突的時候，正常的思路如何解決？
- 我打敗你。
- 我認慫，你打敗我。
而站在第三選擇的思維下，你還有一個選擇：我們共同找到一個雙方都能接受的解決方案，達到共贏。
注意，這裡的第三選擇，絕對不是來自某一方的妥協，或者一人讓一步，核心思想是創造力。如何通過第三種選擇，雙方協同達成另外一個更好的結局。
例如兩個人分蘋果，一人一半？這個方案對兩個人都有虧欠，畢竟我贏了是可以得到一個完整的蘋果的。那什麼是第三選擇？我們把蘋果拿出去換點什麼，然後再來分，或者把蘋果種成蘋果樹，只要願意長線投資，最終我們一人可以收穫半棵樹的蘋果。這些都是第三選擇，只要雙方能達成共識，這是一個雙贏的局面。
二、面對產品經理的衝突
那麼我們在和產品經理合作的過程中，通常會面臨什麼衝突？
2.1 現階段，技術上無法實現的需求
不能要求所有產品經理都是技術出身，當產品經理對技術細節不那麼瞭解的時候，總會有一些異想天開的產品方案。當然有一些並不是技術無法實現，可能是現階段你的團隊實現起來會很吃力，可能會面臨一些未知的坑，而導致整個專案進度很難把控。
面對這樣的需求，你不要直接拒絕，尤其是不要立刻拒絕，說這個需求做不到，這就把對方推入了衝突的局面。你拒絕他，不做這個需求了，或者他說服你，強行要實現這個需求，這都不是我們想看到的。
那現在冷靜一下，想想第三選擇？
我想大多數產品方案，其實並不是唯一的解決方案，你總是想到一些更容易實現的方案的。
你可以問清楚對方的真實需求，給出一個你可以做到的方案，而不是直接拒絕對方的方案。
2.2 需求複雜度和開發時間不匹配
當你面對一個過於複雜的需求的時候，可能因為各種原因，給予你實現功能的時間並不寬裕。
這個時候怎麼辦？自己加班加點完成嗎，大家都是程式設計師，加班寫出來的程式碼具體質量如何我想你也應該心裡有點數。你因為加班寫出了質量不好的程式碼，於是上線之後的 Bug 增多，還需要花時間處理，並且新週期新需求也立刻緊跟上來，發現質量不好的程式碼擴充套件性差，想重構時間上又不允許，只能打補丁，越幹越慢，越幹越爛，Bug 越來越多，於是你壓力越來越大，被抱怨的越來越多。
現在欠下的技術債務，之後總是要償還的，否則長此以往，只能是惡性迴圈。
這個時候直接答應或者拒絕，又會陷入衝突的境地。想想第三選擇，你不要直接說 “不”。你應該先了解清楚，他為什麼要這麼做這個需求？出發點在哪裡？目的是什麼？當你瞭解清楚產品經理對這個需求的真實意圖的時候，你可以從自己技術的角度，給出一個自己能接受的方案，或者和對方討論出一個性價比更好的方案。
能討論出一個大家都接受的方案，固然是好的，但是如果依然很需求複雜，時間和複雜度依然不匹配，怎麼辦？
可以選擇拆分需求。你可以說，這個需求我仔細分析了一下，需要做 A、B、C 工作，以現在分配的時間來說，我只能做到勉強實現 A、B，並且 B 並不保證質量，你看你這個功能，我們能不能拆分成兩期來實現，調整一下需求，這樣我能保證程式碼質量，第一期先保證基本功能，上線讓使用者來驗證需求，第二期再根據使用者的反饋調整細節。
相信我，產品經理也是有各種壓力的，他也需要保證進度在推進，在一個完成和完美的選擇中，我想這不難選擇。
這裡的訣竅是：當我不能完全滿足你的時候，我可以選擇有條件的滿足你。
這樣的好處在於，你把選擇權留給他了，這一部分壓力是你們共同在承擔。如果誰對於這樣的延長的週期有異議，你的產品經理也會幫你說話，說自己需求設計的很細，所以我們決定按兩期來做，這樣也顯得他對需求細節的把控很有力。
2.3 需求變動太頻繁
作為開發，有時候自己寫程式碼的時候，可能寫著寫著發現最初的方案或者選型不合適了，就會主動去調整程式碼、重構程式碼。而產品經理在設計需求的時候，也會有這樣的問題。可能是開始沒有考慮的那麼細，可能因為來自第三方的壓力等等問題，種種原因吧，最終導致需求需要調整，而產品方案的調整，在開發週期內，他是沒法自己獨自調整的，工作壓力一定會轉嫁到實現需求的開發身上。
首先我想說，需求變動是一定會發生的，所以擁抱變化。
本身在需求排期的時候，開發者就應該預留出一些時間來應對這些變化，可這也架不住產品太頻繁的變動，甚至太過分的明天要封板了，今天還在改需求。
這樣的情況，你需要做的是儘量和他捆綁壓力，既然對方把壓力給了你，你要想辦法把這個壓力還回去，讓對方和你一同來分擔這個壓力。
我通常的做法是：
1、先用快捷的方法實現並上線，後續再要時間償還債務
我想很多功能，總是有一些粗暴而不優雅的方式來實現，而這些都是技術債務，之後是需要時間來償還技術債務。
要讓產品經理認領這些技術債務，並且必須立刻給予時間來償還這些債務。
最簡單的一個選擇是，我可以加班加點以一個比較粗暴的方式完成這個需求，但是面臨的問題是後續可能效率會有問題、擴充套件會有問題等等。這事後，下個週期我需要額外多出一個星期的時間來優化這一段程式碼，這就是對技術債務的立即償還。
2、拆分變動
和之前的思路一樣，將變動在現有的基礎上最小化，以最精簡的方式去完成這些變動。
如果沒法精簡，想辦法拆分成二期來實現。
3、增加變動成本，給予對方壓力
雖然所有需求上的變動，最終影響的是開發人員，但是並不是說其他人就沒什麼事情可做了。想辦法增加產品經理的變動成本，讓他來共同承擔壓力。
例如：
- 增加了這個功能，UI 也需要變動，那你能不能和設計師溝通我們這一期就不要扣太多 UI 細節。— 減少溝通成本
- 這個需求的變動影響了原本的開發安排，你看能不能將另外一個需求（不那麼重要）延期。— 置換不重要，但是需要花時間做的事情
- 這個需求如果遇到這樣的情況，是不是沒有辦法得到處理？— 提醒他完善需求，避免再次改動
- 這個需求還有一些 “資料” 需要處理，你看能不能手工幫我處理一下。— 給他找點事兒做，有點損，不推薦
寫在最後
在工作和生活中，不要把所有事情的解決方案都放在：不（第一選擇，要贏）或者 是（第二選擇，認慫）上，如果只存在兩種選擇，很容易就進入一種推拉的環境中，實際上是可以考慮考慮第三選擇 。
第三選擇並不是某一方的妥協，他的核心思想是創造力，找到新的出路，讓雙方協同找到一個大家都能接受的新方案。
說了這麼多，其實都是《第三選擇》的思想，推薦閱讀。
今天在公眾號後臺回覆成長『成長』，將會得到我整理的一些學習資料，也能回覆『加群』，一起學習進步。
推薦閱讀：