產品經理溝通技巧：產品經理如何和程序員打交道

在產品經理和程序員因爲思考方式、關注範圍、職能職責的差異，導致了溝通上的困難這是在很多產品研發體系下都會出現的問題。如何更好的與程序員建立起一座暢通的橋樑也是每位產品經理需要思考的問題。

　　一般情況下，產品經理和程序員溝通困難大概的原因：

　　1、得到信息不對稱

產品經理得到的信息一般集中在：商業需求、商業策略、戰略方向、產品規劃、運營數據、整體營收、目標任務等方面。產品經理往往在根據公司現階段的情況，以及市場的競爭情況，做一些產品策略或者一些產品的方案的策劃、發起、實施。

所以這個過程中，產品經理扮演的角色是翻譯：“市場需求、商業需求”，成爲：“產品需求”，所有的信息全部圍繞需求本身。爲什麼要做需求?怎麼做需求?先做什麼需求、後做什麼?基於怎麼樣一個思路去推送產品進行實施、從一個利益平衡獲得空間增長指標後達到另外一個利益平衡。

程序員不一樣，很多時候程序員得到的信息是：有一個需求，可能是小需求、產品需求、或大到項目需求，然後得到一系列需求列表，然後產品經理會讓程序員看：“需求”哪些通過code改改就可以實現，哪些是需要開發可以實現，哪些是技術或構架或因爲成本的原因不能實現。

所以在這個過程中，程序員扮演的角色是翻譯：“產品需求”，成爲：“技術語言”的評估，所有的信息全部圍繞開發需求本身。如何開發這些需求?是溝通數據庫增加字段?調用接口?開發新的接口?需要開發組件?重新構架引擎?來實現滿足或支撐這些需求?

那這個時候問題來了，很多情況下我們只是把程序員當做一個寫代碼，通過編程語言來操作計算機完成需求的工具了。

　　2、溝通語言不對稱

說到兩者溝通的語言，這肯定是困擾產品經理本身的。產品經理的語言是：“描述“、”形容“，我也見過很多產品經理，很多人的需求文檔就是漫天飛舞的文字，一整段的描述+描述，不要說程序員看不清，可能過段時間連自己都看不清楚。除了書面語言，產品經理的溝通語言也是含糊的，沒有太多的邏輯去組織，很多時候總是試圖去述說一個需求，被程序員的一個計算機術語而打斷。

程序員的語言，更偏向於技術化。很多產品經理做過技術，有技術背景，但是還有很多產品經理不懂得技術。所以在這個時候，程序員在解說或回答一個需求的時候，會把自己習以爲常的變量、函數、實現方式說出來。於是很多產品經理聽到：“Sdk、webshell、select、api、組件、插件、控件“等等的時候會雲裏霧裏，那這個時候問題來了，很多情況下我們總站在自己的立場上、自己的世界裏認爲別人也懂自己在說什麼?實際呢?大家都是聽得一半一半，溝通沒有徹底到位。

　　3、思考角度不對稱

產品經理思考的角度在於產品本身，對技術的細節、技術的性能沒有太多的發言權。很多產品經理要是的實現的業務邏輯，不管程序員是採用：c++、java、php、Python、找開源代碼改的，還是自己寫的都沒有關係。程序員只要在約定的時間裏，把約定的業務邏輯開發出來就可以，產品經理不去會考慮目前服務器的配置、程序員手上任務的配置、技術能力的情況，要的是結果。而且很情願的認爲團隊中的工程師都是世界上最好的工程師，想做什麼都可以做，對因爲技術原因而不能支持實現需求不能接受。

程序員思考的角度有點區別，我也看到不到程序員本身對產品追求完美對需求的'背景、意義去研究瞭解;但很多程序員還是停留在自己接單子任務一樣來一個做一個的境界，做好了自己玩自己的。程序員考慮程序實現的方式同樣的一個請求是get還是post，程序員考慮代碼的性能，從而採取不一樣的方案去實現需求，考慮請求併發量壓力和安全性。但是很多情況下，程序員對技術的理解會導致有一些業務需求滿足不了，不是因爲不能實現，是因爲實現了覺得是廢代碼，或者構架不完美了。

那這個時候問題來了，很多情況下到底傾斜誰的立場上思考問題?我之前也會碰到很多情況程序員就程序的角度說業務需求不合理，產品經理說程序員消極罷工、霸得蠻。

　　4、考覈標準不對稱

誰也不尿誰，哼!你能把我怎麼樣。產品經理和程序員有爲完全溝通或誤會的時候，極端情況下，有一方會罷工。這個時候主要是2個角色的各個考覈標準不一樣，所以在很多情況下顯得非常的無奈。

產品經理很可能考覈的是方案和上線的時間、產品上線後的數據;而工程師考覈的是程序的性能、很多時候產品經理催的急要的急，但程序員每天的時間有限，還是得慢慢構架慢慢開發，程序員開發時間少了，未知的執行BUG沒考慮過是要負責的。

這個時候問題又來了，產品經理天天干着急!咋辦?

以上是我結合幾年來的工作經驗總結出來的，當然這4大因素把很多共性的因素概況進來了。當然過程中還是會因爲很多產品經理或程序員本身(個性)的溝通技巧、態度、情商等因素導致的溝通不倡，影響了彼此之間的默契。

　　解決辦法

其實仔細的分析一下，產品經理和程序員打交道的過程中不管是共性的因素還是個性的因素，也不是想象中那麼困難。通過一些努力之後，我們總是會找到一些快速和程序員建立溝通橋樑的辦法。

　　我個人觀點如下：

　　1、要看到項目層面，不要只看需求本身。

上面說到的幾點不管是：“信息不對稱“、”溝通的語言不對稱“、”思考角度不對稱“還是”考覈的標準不對稱“是我們常見的幾個客觀隱私。把幾個因素抽取出來剖析，發現還是由於我們站問題的視角的高度不一致造成的。

產品經理只是看到自己得到了商業的需求，策劃了產品的需求，接下來會把很多事情拋給程序員做了，那還是站在需求方的角色中。那如果真正的是站在意識層面的項目經理的角度，這個時候看待問題的視眼會廣很多。

這個時候你就想着爲了做這個項目這個需求，程序員是不是明白了爲什麼要做?是不是對這哪些需求的優先級有了重要的認識?作爲產品經理我用怎麼樣一種表達方式程序員更明白?是不是需要把時間點等劃定?目前程序員的資源和服務器情況允許他們能做的空間是多大?怎麼樣才能拉動他們的積極性更好的完成這個項目?適當的時候，需要幫助程序員做哪些申請或讓步?

對產品經理來說，同樣張羅一件事情，同樣會了得到一個結果，但是中間的過程很可能是完全不一樣的。所以因爲思考角度僅僅從做完一個需求死磨硬泡上升到，站在項目的角度去考慮各個關節的風險點、時間點，得到的效果是完全不一樣的。

　　2、從理解程序員開始，換位思考會更好。

一直在問一個問題：“程序員是什麼一羣人?“就和問自己：”產品經理是什麼一羣人?“一樣，有點好笑、有點幼稚。從小工到專家，從CSDN到走出軟件作坊，發現很多很多非常優秀的程序員的心聲。

　　程序員是什麼樣一羣人?像切西瓜一樣一刀一刀切：

寫php的

寫Java的

寫windowsC的

寫liunxC的

寫C++的

編程水平一般的

編程水平還行的

編程水平牛逼的

編程水平大師級的

構架牛的

數據庫牛的

勤奮的

懶於思考的

不會JavaScript的