產品經理溝通技巧：產品經理如何和程式設計師打交道
在產品經理和程式設計師因為思考方式、關注範圍、職能職責的差異，導致了溝通上的困難這是在很多產品研發體系下都會出現的問題。如何更好的與程式設計師建立起一座暢通的橋樑也是每位產品經理需要思考的問題。
一般情況下，產品經理和程式設計師溝通困難大概的原因：
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的