作者在創業型公司負責產品工作,因為沒有設置單獨的產品部門,所以被暫時安置在了技術研發部。從我被調到技術部的第一天起,老大就告訴我“你和開發永遠成不了一類人”。

用“相愛相殺”形容產品經理和程序員的關係未免有些嚴重,但PM和研發確實是兩種完全不同的生物,無論從思維方式還是工作目標上,存在一定的利益衝突,但大部分時間需要相互信任、求同存異、合作共贏。

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

扯遠了,說到和程序員的溝通,確實要區分一下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) 原創發佈於人人都是產品經理。未經許可,禁止轉載。