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

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

以我自己為例吧，作為產(chǎn)品經(jīng)理，我在做事情的時候會考慮：

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

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

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

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

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

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

根據(jù)作者現(xiàn)有的工作經(jīng)驗，非研發(fā)出身PM可嘗試用以下方法加強與研發(fā)人員的溝通。

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

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

本文由 @joanna726（微信公眾號：zhaona_pm） 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。