在產品經理這個崗位上，溝通能力非常重要，尤其是注入感情的溝通更加高效。筆者總結了工作中一些溝通的方法和技巧，希望對大家有幫助。

1. 溝通是什麼

百度百科中是這樣定義溝通的：溝通是人與人之間、人與羣體之間思想與感情的傳遞和反饋的過程，以求思想達成一致和感情的通暢。我個人很認同這個定義，在實際的溝通過程中，很多時候產品經理都停留在思想的傳達。例如：我要做**需求，這個功能用不了是不是有bug，你們什麼時候可以給我體驗功能等等。這些溝通沒有很好地表達出自己的感情，而是硬生生地表達出自己想做什麼而已。

2. 注入感情的溝通

先舉工作中一個實際的例子。技術GG很辛苦地把需求做出來了，興致勃勃地讓產品經理體驗功能。過了一段時間產品經理走到技術GG的座位，對技術說：“這個功能用不了，是不是代碼有bug，麻煩你看看。”我們嘗試使用同理心，當聽到這樣的話，技術GG的心理反應是：

1. 我自測都沒問題，是不是你的環境有問題；
2. SB你會用麼
3. 肯定不關我事，你找服務器同學看下吧
或許還有很多其他不好的反應。這裏的溝通停留在表明自己思想，如果要加入感情要素，應該是怎麼的溝通方式呢，以下是參考建議。可以委婉地跟技術GG說：“這個跟我的需求有點不一樣，是不是我的使用方法有問題，我們一起來看看是什麼原因？”此時技術GG會是心理一震：“我擦，是不是有bug了”，然後雙方很友好地去跟進這個問題。這是有效的溝通，是注入了感情的溝通。
第一，結果先行，需求跟我期望的不一樣；
第二，自我反省，把問題拋出來說明可能是我的原因；
第三，合作解決，一起找原因。
接下來繼續通過實際的案例，闡述感情溝通之美。

3. 感情溝通之美

3.1 我們都是坐同一條船的

在公司裏每個小組都肩負着各自的KPI，而KPI的完成情況決定着每個人的升職加薪和年終獎。正是這種KPI制度，會讓很多很多的員工都只是關注自己的KPI，而忽略了部門的KPI。一般來說產品經理肩負着用戶在線、日活躍、收入等指標，研發則負責需求研發、提升開發效率、優化性能等等。
很多時候，趕進度加班都成爲了家常便飯，尤其是技術GG更是無限吐槽。幾個比較經典的吐槽：麻痹的，產品又改需求了，導致工作量增加；現網有bug，本來用於開發的時間被臨時佔用了，又得加班了；工作量很大，時間又短，被PM催死了。。。。
作爲產品經理，很應該去思考用戶（技術GG）的吐槽，找出痛點，然後進行優化。技術GG的爲什麼會吐槽，主要是不爽。爲什麼不爽？因爲很多時候感覺是在幫產品經理幹活，而不是在做着有興趣有意義的事情。找到用戶痛點之後，就需要出方案解決問題。我的思路是：我們都是坐同一條船的。這裏的關鍵是我們，在溝通中讓大家意識到我們一起在戰鬥。
分享一下產品經常遇到的溝通難題。

1）產品需求變更。每次變更需求都會帶來研發和PM的反感，大家都懂的。這個時候，我會站出來做幾件事情。
第一：需求變更的目的
第二：爲什麼需要變更，變更後的方案比之前的方案有什麼好處，對用戶和部門的價值是什麼
第三：變更後給技術帶來什麼難處，我們一起羅列一下，然後再評估是否在本迭代變更

這就是美：讓所有人懂你，理解你的變更，才能支持你的工作。

2）加班趕需求。每次我們都會定下***時間需要發佈版本，然後全部人都被逼去加班。好吧，這是件蛋疼的事情，怎麼讓大家打雞血，是個難題。
第一：清晰表明爲什麼要定下這個時間點。上升一個層次，從部門的KPI出發，這個版本的成功直接影響到部門的發展前景和每個人的年終獎，與我們息息相關。例如配合某遊戲做活動，趕上世界盃，衝PCU里程碑版本等等
第二：這個版本核心功能是什麼，哪些功能是可以適度削減的（一定要留有討價還價的空間）
第三：闡述領導的期望。我們做得事情領導時時刻刻都在關注。
第四：加班的不只是技術，而是整個團隊。對關鍵的核心人員做好思想工作。
第五：加班偶然請吃飯。這個非常有效，尤其是長時間加班作戰的團隊。

這就是美：提升思考層面，讓參與者感受到目前的困難和挑戰，一起去戰鬥。

3.2 希望技術寫出高效的代碼

項目迭代節奏很快，需求評審的質量直接影響到最終的產出。爲了保證需求評審的質量，我提出了需求初評環節。初評，就是初步的溝通和評審。這個環節有幾個好處
1）提前預告需求功能，讓技術GG心理有底。研發都追求簡潔的代碼和優秀的設計方案，提前知道產品規劃方向，有助於更好的制定設計方案。在溝通中需要關注技術GG的反應，希望可以寫出高效的代碼，提升產品開發效率。
2）發現技術難點，產品方案規避。產品遇到很尷尬的地方就是在需求評審上技術GG說這個功能實現不了，或者說要一個月才能做出來，評審的結果必然是產品修改需求方案，擇日再評審。遇到難題，需要明確溝通，可以把產品的煩惱拋出來，讓技術也參與到產品方案的設計。

初評中需要注意控制相關的參與人員和評審時間，因爲是初評控制好成本，討論核心問題即可。

這就是美：我中有你，你中有我，相互協助，把活幹好。

3.3 產品經理無處不在

在項目過程中，目前產品參與的會議包括：需求評審、測試用例評審、迭代計劃會，這三個會議都是必須參加的。另外還有一個技術評審會議，一般來說產品經理是不需要參加的。由於本次需求很複雜，涉及到的交互細節也很多，爲了防止技術方案中的遺漏關鍵點，這次的技術評審我主動參與了。
一般來說，是不建議產品參加技術討論的。
第一：產品聽不懂技術的討論，整個會議感覺異常無聊
第二：浪費你很多時間，說不定一個小時下來你才參與幾分鐘

我以前做過技術和項目經理，很容易融入到技術討論中。基於自身的經驗，如果要參與技術評審，產品經理需要具備以下條件：
第一：有技術背景。
第二：有移動辦公設備。技術評審不是我們的主場，產品只是協助技術團隊而已，所以參與感很低。爲了不浪費時間，所以需要有移動設備辦公，在技術需要我麼的時候，立刻提供協助即可。

重要：技術評審就像一個菜市場，產品要在這個環境下工作，適當時候提供協助。對於個人能力要求很高，如果受到外界影響很大的話，建議不要參加了。等技術需要你的時候，再電話或者來會議室參加討論即可。

這就是美：適當參與，幫助技術，無處不在的服務精神