這里是Z哥的個人公眾號

每周五11：45 按時送達

當然了，也會時不時加個餐～

我的第「155」篇原創敬上

大家好，我是Z哥。

在互聯網行業，產品經理和程序員之間的關系很微妙。表面看上去水火不容，在一方的眼里看另外一方總是有這樣那樣的問題，相互吐槽。但現實是，大家都知道和對方在同一條船上。

產品沒做好的話，除了公司利益受損，產品經理和程序員也會各回各家各找各媽，重新找新工作去。

產品做得好的話，雙方和睦相處、其樂融融？那是不可能的，這個輩子都不可能和睦相處。矛盾會更加嚴重……（都覺得自己功不可沒）

所以Z哥就想來聊聊產品經理和程序員之間的協作問題。不管你是產品經理還是程序員，都應該找到與對方打交道的好方法。好的方法必然是尋求雙贏的，而不是一個零和博弈。

這個主題會分別從不同的兩個視角展開，今天我們先聊程序員視角，本來想兩個視角一起聊，發現內容太多，寫到一半還是拆了，先把一個視角寫了。

如果你是程序員可以看看以下這些描述是你眼中的產品經理么？

如果你是產品經理可以看看從程序員起家的Z哥給出的一些建議。

程序員吐槽產品經理最多的原因主要是以下幾個（以下內容可能會引起程序員們的極度舒適～）：

開發過程中頻繁修改需求。

驗收過程中要求做比較大的修改。

說不清楚需求的價值

替程序員評估工作量

需求整理的不夠細。

其中，頻繁修改需求是程序員們最反感的，這是毋庸置疑的。

從產品經理的角度來說，雖然無法100%在開發過程中不修改需求，但是如果前期的工作做得足夠充分，與業務方的溝通足夠到位，至少去掉“頻繁”兩個字還是很有可能的。我甚至遇到過一些產品經理，在自己對業務都是一知半解的時候就開始整需求了，這必然會導致后續頻繁的需求變更。

第二，驗收過程中要求做比較大的修改。此時往往會伴隨一句短語——“這不是我要的”。每當程序員聽到這6個字的時候，腦子里是一萬頭草泥馬奔過……

產生這個情況的原因有很多。可能是程序員理解偏差，也有可能是產品覺得功能效果不佳。但是大多數時候，產生這個情況的根本原因還是在需求評審階段的溝通不夠充分，雙方之間并沒有達成真正的共識。

但是如果要說什么時候雙方的矛盾最激烈，那還不是修改需求的時候，而是需求評審的時候。

此時，很容易看到的一個景象是“討價還價”。產品經理站在「價值」一方，程序員站在「成本」一方。當程序員們追問某個他們不認同的功能時，如果產品經理無法闡述出該功能令人信服的價值，那么必然受到吐槽。這是原因三。

原因四，有些產品經理是從程序員轉過去的，之前做過一兩年的開發工作。這個時長的經驗其實是很危險的，很容易陷入到「達克效應」的第一階段：高估自己的技術能力，低估他人的技術能力和工作難度。這會導致不管是明面上還是私底下會不自然地去評估程序員的工期是否合理，甚至會在需求評審的時候替程序員預估時間，如果高于自己的預估，便會認為他們偷懶。

最后一點。相信每個人程序員都提出過這樣的問題“這里如果……，那么要怎么處理？”。這種就是需求考慮不夠細致的體現。不過，要做好這點的確挺難的，這也是產品經理花費時間最多的地方。

聊了這么多場景，作為產品經理應該如何應對呢？

從思路上分為以下幾步。

01

先明確大方向，并與程序員達成一致。

正如前面所提到的，產品經理站在「價值」方，程序員站在「成本」方，這注定了他們是對立的。最壞的結果就是雙方互掐，就算相對好的結果也只是相互妥協做一個半吊子的功能（用系統的人不太舒服）。

但如果你的視野更大，格局更高，就會發現，如果以「投入產出比」角度來切入，雙方不但都能理解，而且很容達成共識，畢竟花最小的成本干價值最大的活，是個正常人都能理解和認可不是么。

所以，可以在日常工作中不斷的強化這個共識。一旦出現爭執，就從這個角度來做最終決定，甚至基于這慢慢地還能建立起相互的信任，程序員真正擁有了產品思維，產品經理真正懂了程序員的難處。

02

將產品經理范疇內的事情做到極致。

所謂術業有專攻，與其相互吐槽，不如多花點時間把對方吐槽的地方做到極致。

03

有時候你雖然做的很好，想的也很仔細，但是還是會出現無法說服程序員認可你方案的情況。這是因為我們每個人本身都會存在「確認偏誤」現象。

確認偏誤是指搜尋，解釋，偏愛和回想確認或支持一個人先前信念或價值觀的信息的傾向。會導致對個人信念的過度自信，并且在面對相反的證據時可以保持或加強信念。

維基百科

所以，運用一些溝通技巧顯得至關重要。只要一件事不是單憑一個人就能完成，你就得考慮如何提高協作效率。而產品經理和程序員的協作中，溝通又是最重要的。

下面展開說說具體可以做的一些事。主要是思路中的2和3。

01?提高專業性

我觀察過一個現象，需求變更比較多的產品經理，他們的工作習慣往往是直接抄起原型工具就畫原型，或者有很多工作時間在原型工具里。

這樣非常容易陷入到一個思維慣性里面去，就是過于關注交互層面的事情，而輕視了背后業務流程的設計，甚至是業務的合理性。

我認為產品經理做事的時候一定要以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用心做好是必不可少的。

02?溝通方面

與程序員的溝通方面，我總結了五動作，分別是「齊、拉、捧、說、謙」，可以根據情況組合出擊。

「齊」就是視角對齊的意思。在聊需求之前，先交代需求的背景、意義。特別在中途需求變更的時候，這點非常重要。

繼續搬出之前用過好幾次的圖。

如果視角不同，你說接下去還怎么聊？

「拉」是拉攏的意思。亞里士多德說過：

我們無法通過智力去影響別人，而情感卻能做到這一點。

亞里士多德

所以，在溝通的時候要把程序員當作自己人看待，而不是敵對。比如，可以多用“我們”，“一起”等詞語，進入一個協商的氛圍。舉個例子：“我們一起來看下這個問題”。少用”我覺得“、”我認為“；

「捧」是吹捧的意思，但并不是簡單的拍馬屁。

人都是有多面性的，針對不同的情況和場景，可能會表現出不同的特質，這會影響到雙方的溝通。比如有的人在生活中很溫和，但在工作時非常嚴苛，要求很高，這就是激發了不同的特質。

類似的，為了激活程序員的積極性，你可以在當下需要他發揮的地方吹捧一下。比如，你覺得某個程序員做的東西質量一般，小問題比較多。那么你在和他聊的時候特地捧一句，“我知道做程序員的都或多或少有完美主義傾向，對細節很關注。我這個功能設計的細節可是想了好久呢，不過對你來說應該很容易搞定吧。”

「說」是說服的意思。想要讓對方從心底里的認同你，單憑打感情牌可不行。所以需要多用數據和用戶反饋來提高你觀點的可信度。

重視數據的產品經理有可能是優秀的產品經理，但不重視數據的產品經理一定不是優秀的產品經理。因為要看得懂數據的前提是得懂業務，并且還不能僅僅懂個皮毛。比如，

• 你得知道哪些環節產生的數據是關鍵。

• 多個數據之間的間接關系和影響是什么。

• 你設計的每一個功能會如何影響這些數據。

• ……

心里一直有著這些概念，程序員還會吐槽你提的需求價值低？

「讓」是謙讓的意思。俗話說，“三個臭皮匠頂一個諸葛亮”。可以給程序員留有表達他們觀點的空間。

原因有兩點。

大多數的產品設計背后有很多的知識是通用知識，每個人的生活經歷都能成為經驗。而每個人的生活經歷又是不同的。

專業不同，哪怕站的視角相同，看到的同一個事物也會有些差別。用高端的說法叫“看到的本質不同”。基于這個本質出發，提出的觀點可能會讓你眼前一亮。

以上就是「齊、拉、捧、說、謙」五點。最后再送給你一句話：非必要情況，一定不要用“這是老板的要求“！，重復，重復。重要的事情說三遍。

還有一些比較成熟的方法體系也能改善產品和開發之間共識達成問題。比如，在領域驅動設計范疇中Event Storming。它就非常適合在前期的需求評審環節去使用。

感興趣的可以自行了解。

好了，總結一下。

這篇呢，Z哥和你分享了我對產品經理如何更好地與程序員達成共識這件事的看法。

思路上分為三步：

先明確大方向，并與程序員達成一致。

將產品經理范疇內的事情做到極致

運用一些溝通技巧解決「確認偏誤」現象。

關于第二點，給出的具體措施是。以User Story為核心，做好Use Case的編寫工作，而不是花很多時間在原型上。

關于第三點，總結了五個動作，分別是「齊、拉、捧、說、謙」，可以根據情況組合出擊。

希望對你有所幫助。

推薦閱讀：

• 分享幾個親測有效的高效工作技巧
  

• 平臺or職位，你怎么選？
  

原創不易，如果你覺得這篇文章還不錯，就「在看」或者「分享」一下吧。鼓勵我的創作 ：）

如果你有關于軟件架構、分布式系統、產品、運營的困惑

可以試試點擊「閱讀原文」

總結

以上是生活随笔為你收集整理的懂程序员的产品经理是什么样子？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。