在互聯網行業，產品經理和程序員之間的關係很微妙。表面看上去水火不容，在一方的眼裏看另外一方總是有這樣那樣的問題，也總是相互吐槽。
但現實是，大家都知道和對方在同一條船上。
產品沒做好的話，除了公司利益受損，產品經理和程序員也會各回各家各找各媽，重新找新工作去。
產品做得好的話，雙方和睦相處、其樂融融？那是不可能的，這個輩子都不可能和睦相處。矛盾會更加嚴重……（都覺得自己功不可沒）
所以Z哥就想來聊聊產品經理和程序員之間的協作問題。不管你是產品經理還是程序員，都應該找到與對方打交道的好方法。好的方法必然是尋求雙贏的，而不是一個零和博弈。
這個主題會分別從不同的兩個視角展開，我們先聊程序員視角。
懂程序員的產品經理是什麼樣子
如果你是程序員可以看看以下這些描述是你眼中的產品經理麼？如果你是產品經理也可以看看從程序員起家的Z哥給出的一些建議。
程序員吐槽產品經理最多的原因主要是以下幾個（以下內容可能會引起程序員們的極度舒適～）：
-
開發過程中頻繁修改需求；
-
驗收過程中要求做比較大的修改；
-
說不清楚需求的價值；
-
替程序員評估工作量；
-
需求整理的不夠細。
其中，頻繁修改需求是程序員們最反感的，這是毋庸置疑的。
從產品經理的角度來說，雖然無法100%在開發過程中不修改需求，但是如果前期的工作做得足夠充分，與業務方的溝通足夠到位，至少去掉“頻繁”兩個字還是很有可能的。
我甚至遇到過一些產品經理，在自己對業務都是一知半解的時候就開始整需求了，這必然會導致後續頻繁的需求變更。
而到了第二點，驗收過程中要求做比較大的修改。此時往往會伴隨一句短語——“這不是我要的”。每當程序員聽到這6個字的時候，腦子裏是一萬頭草泥馬奔過……
產生這個情況的原因有很多，可能是程序員理解偏差，也有可能是產品覺得功能效果不佳。但是大多數時候，產生這個情況的根本原因還是在需求評審階段的溝通不夠充分，雙方之間並沒有達成真正的共識。
但是如果要說什麼時候雙方的矛盾最激烈，那還不是修改需求的時候，而是需求評審的時候。
此時，很容易看到的一個景象是“討價還價”。產品經理站在“價值”一方，程序員站在“成本”一方。
當程序員們追問某個他們不認同的功能時，如果產品經理無法闡述出該功能令人信服的價值，那麼必然受到吐槽。這是原因三。
原因四，有些產品經理是從程序員轉過去的，之前做過一兩年的開發工作。這個時長的經驗其實是很危險的，很容易陷入到“達克效應”的第一階段：高估自己的技術能力，低估他人的技術能力和工作難度。
這會導致不管是明面上還是私底下會不自然地去評估程序員的工期是否合理，甚至會在需求評審的時候替程序員預估時間，如果高於自己的預估，便會認爲他們偷懶。
最後一點。相信每個人程序員都提出過這樣的問題“這裏如果……，那麼要怎麼處理？”，這種就是需求考慮不夠細緻的體現。不過，要做好這點的確挺難的，這也是產品經理需要花費時間最多的地方。
聊了這麼多場景，作爲產品經理應該如何應對呢？
從思路上分爲以下幾步。
1、先明確大方向，並與程序員達成一致
正如前面所提到的，產品經理站在“價值”方，程序員站在“成本”方，這注定了他們是對立的。最壞的結果就是雙方互掐，就算相對好的結果也只是相互妥協做一個半吊子的功能（但是用系統的人不太舒服）。
但如果你的視野更大，格局更高，就會發現，如果以“投入產出比”角度來切入，雙方不但都能理解，而且很容達成共識，畢竟花最小的成本幹價值最大的活，是個正常人都能理解和認可不是麼。
所以，可以在日常工作中不斷的強化這個共識。一旦出現爭執，就從這個角度來做最終決定，甚至基於這慢慢地還能建立起相互的信任，程序員真正擁有了產品思維，產品經理真正懂了程序員的難處。
2、將產品經理範疇內的事情做到極致
所謂術業有專攻，與其相互吐槽，不如多花點時間把對方吐槽的地方做到極致。
3、運用一些溝通技巧解決“確認偏誤”現象
有時候你雖然做的很好，想的也很仔細，但是還是會出現無法說服程序員認可你方案的情況。這是因爲我們每個人本身都會存在“確認偏誤”現象。
確認偏誤是指搜尋，解釋，偏愛和回想確認或支持一個人先前信念或價值觀的信息的傾向。會導致對個人信念的過度自信，並且在面對相反的證據時可以保持或加強信念。
——維基百科
所以，運用一些溝通技巧顯得至關重要。只要一件事不是單憑一個人就能完成，你就得考慮如何提高協作效率。而產品經理和程序員的協作中，溝通又是最重要的。
下面展開說說具體可以做的一些事。主要是思路中的2和3。
1）提高專業性
我觀察過一個現象，需求變更比較多的產品經理，他們的工作習慣往往是直接抄起原型工具就畫原型，或者有很多工作時間花在原型工具裏。
這樣非常容易陷入到一個思維慣性裏面去，就是過於關注交互層面的事情，而輕視了背後業務流程的設計，甚至是業務的合理性。
我認爲產品經理做事的時候一定要以User Story爲核心來展開，先構思好一個User Story，然後再把它真實發生的各種細節闡述清楚。
做這件事的過程先後分爲以下四步：
-
定義User Story；
-
定義交付標準；
-
提供低保真原型；
-
編寫Use Case。
這裏面最費時費力的就是第四環節，而且你想把User Story闡述清楚離不開一個專業的 Use Case編寫。我之前收藏了一個非常專業的Use Case模版，是從知乎上的張恂老師那看到的，你感受一下。
用例名稱：提問
層次：!（用戶目標層）
範圍：問答網站（以下簡稱系統）
主用角：註冊用戶（以下簡稱用戶）
其他干係者：...
後態：
前態：用戶已登錄。
觸發事件：用戶選擇提問。
基本流：1. 系統顯示新建問題框。
輸入問題 {
2. 用戶輸入問題陳述（字數限制？）；系統即時驗證輸入的有效性，並提示已有答案的類似問題（數量？）以免重複提問。
3. 用戶設定該問題的相關話題。
4. 可選項
用戶可補充輸入問題說明（背景、條件等詳細信息）。
5. 可選項
……
6. 用戶提交問題。
}
7. 系統驗證該問題的有效性。
8. 系統發佈該問題，並顯示該問題頁面。
擴展流：用戶放棄提問：...
https://www.zhihu.com/question/48899115/answer/113274323 張恂老師的回答
作爲產品經理的你，如果想要減少被程序員吐槽需求不夠細，或者降低開發過程中變更需求的頻次，把Use Case用心做好是必不可少的。
2）溝通方面
與程序員的溝通方面，我總結了五動作，分別是“齊、拉、捧、說、謙”，可以根據情況組合出擊。
① “齊”就是視角對齊的意思
在聊需求之前，先交代需求的背景、意義。特別在中途需求變更的時候，這點非常重要。
繼續搬出之前用過好幾次的圖。
如果視角不同，你說接下去還怎麼聊？
② “拉”是拉攏的意思
亞里士多德說過：“我們無法通過智力去影響別人，而情感卻能做到這一點。”
所以，在溝通的時候要把程序員當作自己人看待，而不是敵對。比如，可以多用“我們”，“一起”等詞語，進入一個協商的氛圍。
舉個例子：“我們一起來看下這個問題”，少用”我覺得“、”我認爲“。
③ “捧”是吹捧的意思，但並不是簡單的拍馬屁
人都是有多面性的，針對不同的情況和場景，可能會表現出不同的特質，這會影響到雙方的溝通。比如有的人在生活中很溫和，但在工作時非常嚴苛，要求很高，這就是激發了不同的特質。
類似的，爲了激活程序員的積極性，你可以在當下需要他發揮的地方吹捧一下。比如，你覺得某個程序員做的東西質量一般，小問題比較多。那麼你在和他聊的時候特地捧一句，“我知道做程序員的都或多或少有完美主義傾向，對細節很關注。我這個功能設計的細節可是想了好久呢，不過對你來說應該很容易搞定吧。”
④ “說”是說服的意思
想要讓對方從心底裏的認同你，單憑打感情牌可不行。所以需要多用數據和用戶反饋來提高你觀點的可信度。
重視數據的產品經理有可能是優秀的產品經理，但不重視數據的產品經理一定不是優秀的產品經理。因爲要看得懂數據的前提是得懂業務，並且還不能僅僅懂個皮毛。
比如，
-
你得知道哪些環節產生的數據是關鍵；
-
多個數據之間的間接關係和影響是什麼；
-
你設計的每一個功能會如何影響這些數據；
-
……
如果你心裏一直有着這些概念，程序員還會吐槽你提的需求價值低？
⑤ “讓”是謙讓的意思
俗話說，“三個臭皮匠頂一個諸葛亮”。可以給程序員留有表達他們觀點的空間。
原因有兩點：
-
大多數的產品設計背後有很多的知識是通用知識，每個人的生活經歷都能成爲經驗，而每個人的生活經歷又是不同的；
-
專業不同，哪怕站的視角相同，看到的同一個事物也會有些差別。用高端的說法叫“看到的本質不同”。基於這個本質出發，提出的觀點可能會讓你眼前一亮。
以上就是“齊、拉、捧、說、謙”五點。
最後再送給你一句話：非必要情況，一定不要用“這是老闆的要求”！重複，重複。重要的事情說三遍。
還有一些比較成熟的方法體系也能改善產品和開發之間共識達成問題。比如，在領域驅動設計範疇中Event Storming，它就非常適合在前期的需求評審環節去使用，感興趣的可以自行了解。
好了，總結一下。
上面Z哥和你分享了我對產品經理如何更好地與程序員達成共識這件事的看法。
思路上分爲三步：
-
先明確大方向，並與程序員達成一致；
-
將產品經理範疇內的事情做到極致：具體措施是以User Story爲核心，做好Use Case的編寫工作，而不是花很多時間在原型上；
-
運用一些溝通技巧解決“確認偏誤”現象：“齊、拉、捧、說、謙”五個動作，可以根據情況組合出擊。
如何做一個懂產品的程序員
下面我們來說說程序員視角。
兩個相愛相殺的崗位，想要更好的達成共識、更好的合作，自然不僅僅是一方的事情。這次Z哥先會帶你看看產品經理眼中的程序員是什麼樣子，然後給出一些我的建議。
從產品視角是怎麼看程序員的呢？我根據我自己的經歷以及與其他產品經理的交流下來看，吐槽的主要是以下幾點：
-
這個功能實現不了；
-
希望所有產品都不要改版，一次性把現在或未來要做的開發完；
-
只關心要寫多少代碼，不在乎產品體驗；
-
寫完程序從不自測，直接丟給別人測試；
-
過分追尋新技術潮流，完全不考慮對產品帶來什麼價值。
第一點，的確存在一些由於技術限制導致實現成本無限大的需求，比如手機屏幕背景色根據手機殼顏色切換……
但是，國內的技術環境不像老美那的技術味道重，大多還是商業導向的，很少企業裏需要用到高精尖的技術，所以，真正實現不了的功能微乎其微。
對於大多數的功能需求來說，無非是一個成本大小、價值高低的問題。從立場上看，程序員自然是站在“成本”一方的，但對大多數人來說，決定這個成本的主要因素往往是自己工作的難度和耗時，費時費力的功能就容易得到“實現不了”的結果。
第二點對大多數產品經理來說是他們的對立面，因爲大多數產品經理最喜歡“走一步算一步”地高頻迭代，甚至是有一個想法就開始幹。而程序員則喜歡來一個大而全的，並且內容要非常詳細的，心裏的想法是，這樣的話我一開始就可以設計一個完美架構來支撐它。
而且，內容越詳細，產品經理就越不敢亂調整需求，畢竟“證據在手”嘛：D。
第三點在大多數程序員身上都能看到。畢竟做程序員的還是理科男偏多，對需要有同理心、需要靠感受的事情的確弱了一些。
第四點的原因主要有兩個，
-
一個是對自己的代碼過度自信導致，我自己深有體會。我還記得有一次我交付一個功能，那個功能我單元測試都寫了不少，對質量很有信心，覺得就算有bug也都是比較深層的bug。結果沒想到……第一天就測出來好幾個低級的bug；
-
另一個原因是反正有測試人員在，等他們測出問題我再改不是更輕鬆。惰性使然，從個人角度的確如此。但是從團隊角度來看，徒增了不少的溝通成本。
第五點的原因也有兩個，
-
一個是行業裏的新技術迭代的確太快，怕不學新技術被淘汰；
-
另一個原因是，只有用上新技術纔能有談資，顯得自己與衆不同、有成就感。
以上就是對這五點的簡單分析，那麼如何改善呢？繼續往下看。
下面這些方法都是我親測有效的，強烈推薦你也試試。這裏的序號與前面被吐槽的五點一一對應。
1、說實現不了之前，先三思
根據先後可以做以下3個思考：
-
是覺得這個功能沒有價值不想做嗎？
-
真的實現不了？我想全了嗎？
-
這些方案裏，有成本比價值低的嗎？
第一個問題先確定必要性。我們不是說不能推需求，而是要推掉低價值、無價值的需求。當然有沒有價值不一定你說了算，但至少這才能算是拒絕的理由；
第二個問題，努力拓寬自己的邊界、舒適區。如果我們總是習慣性地從大腦的記憶中找解決方案，那麼將會永遠在舒適區止步不前；
第三個問題，拒絕需求雖然不用動之以情，但一定需要曉之以理。當你能清楚的闡述利弊、收益比，拒絕需求自然不是一件需要相互扯皮的事情。
經過了這三個問題的思考，不管最終能不能實現，相信可以很好的與產品經理達成共識。
2、明白需求本身也是成本
過度地苛求需求要細、要完整、要全面，這個本身也是在增加產品經理需要投入的時間。你的開發成本是成本，產品經理的也是。
與其等一個“XXXX最終絕對不改版”，不如從已經達成共識的部分開工，在這個過程中再與產品經理“共創”，多一起溝通打磨，此時再讓產品完善PRD等文檔，形成最終版。
3、刻意練習，多換位到用戶視角
平時多去體驗一下自家的產品以及競品，把整個過程中的感受記錄下來。比如，哪裏感到不太順手、哪裏感受到了小驚喜、哪裏感到特別煩人等等。
結果不重要，重要的是這個過程，慢慢鍛鍊自己作爲用戶的感知力。
有些程序員看起來經常把用戶體驗掛在嘴上，其實提出來的很多反而是脫離大衆習慣的“個性化”需求，就是因爲平時缺少對同行、外界的關注。
4、交付的東西是自己的“招牌”
“有人的地方就有江湖，有江湖的地方就有稱號”。如果長期報以等測出來bug再去修的心態，你在別人心中的稱號就是負面的。
輕則影響自己的口碑，影響與他人之間的協作關係；重則失去未來的晉升機會。
一個對自己的東西都不負責的人，如何負責更多的人、更大的事情呢？
在這件事上，除了多自測外，作爲過來人，我建議每一個程序員認真對待單元測試。特別是把核心、複雜的方法單元測試給做上，這對交付功能的質量的提升非常明顯。
5、不產生價值的新技術是“垃圾”
擁抱新技術是值得鼓勵的。但是單純的爲了體驗某新技術而去使用它，這不但給團隊在挖坑，也在給自己挖坑。
比如你花了不少的時間在項目裏用了某個新技術，但是對團隊沒有帶來什麼價值，你說後續公司還會繼續投入資源加大新技術的使用嗎？大概率並不會。那麼之前瞭解到的一些知識，就會隨着時間的推移而淡忘，投入的時間大多數浪費掉了。
所以，對待新技術Z哥的觀點是：對於無法在工作中找到價值點的新技術淺嘗輒止即可。相反，遇到可以產生價值的新技術，請全身心投入進去，而不是僅僅在應用層面搗騰，不去深入細節。
很多程序員對待新技術的習慣是，打一槍換一個地方，經過了幾年，發現技術實力還在原地打轉，不免有些可惜。
另外，推薦大家可以閱讀一兩本心理學、行爲學相關的書，特別是我們做程序員的。不但可以提高自己對用戶體驗的感覺，還能提高對人性的洞察力和對自我的認知。是一項不管在生活中還是工作中都非常有用的技能。
好了，總結一下。
剛纔Z哥和你分享了我對程序員如何更好地與產品經理達成共識這件事的看法。主要是以下五點建議：
-
說實現不了之前，先三思；
-
明白需求本身也是成本；
-
刻意練習，多換位到用戶視角；
-
交付的東西是自己的“招牌”；
-
不產生價值的新技術是“垃圾”。
希望對你有所幫助。
作者丨Zachary 來源丨跨界架構師（ID：Zachary_ZF） dbaplus社羣歡迎廣大技術人員投稿，投稿郵箱： [email protected]