需求來了，產品經理該怎麼溝通？
需求來源有多方面，除了使用者的、競品的、產品經理YY的、還有領導的、其它部門的，等等。大部分情況，需求的發起方是產品經理，但有時其他團隊也會提起需求。
這時候， 溝通是一件非常關鍵的事情，產品經理務必確保需求的提出方、研發、測試等干係人對需求的理解一致 ，否則，會直接影響後續一系列的工作，犯下勞民傷財的罪過。
1. 溝通模型
所謂溝通的過程，就是一個人要在資訊發出來時開始編碼，這叫做用一種方法講給別人聽。然後，經過一個渠道以後，到另外一個耳朵裡面開始解碼，即人家的話我是否聽得懂。
日常生活的溝通，人們很少出現歧義。原因是溝通訊息簡單，大家生活背景類似，而人類擅長於從上下文去解讀這類資訊。
假設A給B送禮，寒暄過後，
A：意思一下……
B：你這是什麼意思？
A：沒什麼意思，就是意思意思。
B：我是那樣的人嗎？真不夠意思。
儘管有那麼多意思，但A和B都知道對方在說什麼，如果說給外國人聽，估計就要一頭霧水。他們缺少了編碼解碼的思維背景。
實際工作中，溝通涉及到專業性，而溝通的人具有不同的思維背景，大家都傾向於從固有的認知裡去理解事情。這樣，在資訊溝通的編碼和解碼方面，就很容易出現偏差。
產品經理在溝通上要做的事情是，搞清楚需求的目的是什麼，從目的出發去理解需求方的描述是什麼，梳理需求資訊，跟需求方達成共識，最後給出解決方案。
2. 一次需求溝通經歷
筆者經歷過臨時被拉進公司一個跨國、跨部門小專案的需求溝通，就遇到了由於專業背景的不同，導致對需求理解不一致的麻煩。
一開始海外營銷的同事想升級公司的產品，增加一些功能，並採用指定的樣式，以便更好地進行營銷推廣。
他們瞭解到產品是在購買授權的程式碼基礎上二次開發的，從授權的官網有他們需要的功能和樣式，這些是可以直接從後臺安裝的，只需要做一些調整。
他們不太懂技術，屬於營銷部門，於是找了公司國內部門的營銷同事反饋這事情（這期間，海外、國內的同事在沒有研發、沒有產品人員介入情況下來來回回溝通，仍然沒有什麼進展）。
後來郵件轉到了我和一位專案經理，考慮到他們之前的溝通基本上是純文字，甚少截圖，而且，海外同事用英文寫，國內這邊理解後又用英文表達，資訊理解的一致性存在隱患。
果然，我將需求具象化後，畫了線框圖，跟他們逐一確認需求點，就發現了三個比較大的問題。
一是，存在雙方理解的不一致，純文字的表達方式，雙方都以為對方明白他們的意思；
二是，由於思維模式和專業背景的不同，需求方有時沒法將需求確切地表達清楚；
三，需求方對實現的評估往往只看到表面，不清楚內在的邏輯，導致大家對時間的評估存在分歧。
需求確認清楚後，產品經理要進一步想想需要是否合理，用各種維度去評估需求。通常，如果需求來自產品經理自己，要問問為什麼？想要的目的是啥？是意淫的需求還是有資料支撐的需求？使用者真的需要？一定要進入開發階段才能解決？現有的方案能不能變通？等等。
如果來自其他人的需求， 最直接的就是問問這種需求的目的是什麼 。因為有些時候，需求就一個，但解決方案可以多種多樣。一旦到了出解決方案這一步，意味著人力和時間的投入。
產品經理要綜合評估，尋找價效比最高的那種。這種把握很難，因為選擇就意味著放棄，你永遠不知道，當初不選擇這個而用另一個的效果是怎麼樣的。說句皮一點的話，這完全靠產品經理的自我修養了。
3. 溝通鏈條
如果把需求從提出到實現的整個流傳以產業鏈的角度看，產品經理的上游就是跟第三方對接使用者需求，下游就是跟工程師溝通產品需求了。
從使用者需求到產品需求，處於中游位置的產品經理就像一個輸入輸出裝置的處理器，上游輸入，中游處理，下游輸出。
產品需求一般以產品需求文件（PRD）展現，載體嘛，有Word的、Axure的、Confluence的，具體看公司規範。形式是次要的，關鍵是文件的內容要寫得細緻無歧義，需要考慮邏輯完備、互動跳轉、異常處理、初始狀態等等。
需求到了這一步，產品經理就要直面傳說中的程式員了。
網上經常有段子或者不著邊際的視訊，調侃產品經理和程式設計師的各種撕逼，大家當玩笑看就好了。實際工作中，產品經理和程式設計師大多相處愉快，沒那麼多狗血劇。
分工合作下，產品經理作為需求提出方，程式設計師作為需求實現方，天然存在溝通的必要。這裡，產品經理又一次面臨資訊傳遞的編碼解碼過程。
和程式設計師的需求溝通會非常頻繁，從需求評審到開發過程中的細節確認，從需求變動到技術實現的可能性，所有可能的環節都需要溝通，這部分，將在寫需求管理的時候敘述。