我想過這個問題，程序員對話產品經理，存在先天上的優勢——編程工作的技能值非常高，大部分人無法通過短暫的學習就能獲得，這是讓程序員們非常自豪的事。而且這種優越感也擴展到了由研發轉過來的產品經理身上。馬化騰說過“我認為所有的產品經理都應該具備技術背景”。當然作為一個沒有技術背景的產品經理來說，我從內心是不愿意認同這句話的，但普遍的認識確實是：產品經理難以從事研發，但研發可以輕松地轉為產品經理。（這又引出了一個比較大的、一直在爭論中的話題“產品經理到底需不需要懂技術”）

扯遠了，說到和程序員的溝通，確實要區分一下PM和研發不同的思維習慣。

以我自己為例吧，作為產品經理，我在做事情的時候會考慮：

1. 這個是不是真正需要的？
2. 有沒有更好的、性價比更高的替代方案？
3. 怎么做體驗更好？
4. 怎么才能少給后續的運營挖坑？
5. 技術的實現難度有多大？

而程序員在做事情時會思考：

1. 這個怎么實現？
2. 怎樣才能降低開發難度？
3. 會不會對之前的系統造成負面影響？
4. 是不是可擴展和易維護？

雖然PM也會考慮（可能大部分時間是自以為考慮）技術研發的成本，但畢竟不是自己做的工作，所以這方面的思考難免淺顯和主觀。其實，作者在跟公司的程序員GG、MM們溝通時（補充：他們人真的挺不錯~工作不忙的時候大家每天中午玩狼人殺），也著過急，吵過架。但冷靜下來想，真的是因為缺乏對編程的了解和對程序員的理解，才會造成這些問題。所以作者要在這些負面的事件中承擔主要責任。

我估計和我本人一樣，大多情況下，非研發出身的PM在和研發溝通時，困擾的問題有兩個：

1. “看起來很簡單啊，為什么告訴我不能做？”（“看起來很簡單啊，為什么工期這么長”）
2. “本來已經溝通好的需求，為什么寫代碼的時候又跟我商量不這么做了？”

根據作者現有的工作經驗，非研發出身PM可嘗試用以下方法加強與研發人員的溝通。

1. 把握好需求評審的流程，一定要把涉及到的所有研發人員都拉過來，并且有重點的對產品需求進行講解。大方面的事情要盡量在會上溝通好，細節性的工作可以會下單獨溝通。
2. 一定要改變觀念，程序員是與你合作的同事，并非是你的下屬，產品經理是個職位并非頭銜。有些剛入行的產品人員還有“以我為大”的觀念，這種想法是很幼稚的。
3. 如果你不了解技術，切莫有太多的“我認為這個很簡單啊”的想法，當你對實現難度、工期沒有概念時，要虛心請教架構師或主程序員。如果他們能為你普及些技術概念，說明你遇到好同事了。
4. 每個人都有偷懶的想法，程序員們也是。如果你發現確實是因想單純減少工作量而提出修改需求或質疑需求。一定要運用兩個法寶來說服他們：用場景感染，用數據立足。增強體驗的需求在研發眼里，屬于可做可不做（“有那么重要嗎？在我看來只是增加工作量的”），這時候就要搬出用戶場景，就是給研發講故事，這個做了用戶是什么感受，沒有的話用戶又是什么感受。數據就不用說了，因為程序員本來就是一種理性思維的動物，如果有數據支撐你的觀點，那再好不過。PM雖在技能方面不是最精專的，但一定要有全局觀點，當你提前考慮到了別人的質疑，才能有備而戰。
5. 相信你的研發同事和你目標一致，相信程序員們從內心是非常想做好這些工作的，就像他們會信任你，相信你做的需求并努力實現它。同理心，真的是溝通中的三字金言。

我問過北京的同行，和研發有沖突時你該怎么做，他回復了一句“沒有什么問題是一頓擼串解決不了的！”

本文由 @joanna726（微信公眾號：zhaona_pm） 原創發布于人人都是產品經理。未經許可，禁止轉載。