產品與研發相處之道

　 

　　方才一個開發經理和兄弟專案組的產品經理懟起來了。事情大概是，兩邊對接，那邊希望我們出一個介面，而我們這邊實際上是兩個完全不同的實體概念，開發經理覺得應該提供兩個基礎介面，合成一個不科學。

　　吵得難分難解，我則狗在一邊不說話，希望他們最後能自行解決。結果還是被抓到，鍋，你說到底要咋整……

　　之前則有一對更合不來的專案經理和產品經理，來找我分別聊，「這專案經理是不是管太多了……」，「這產品經理是不是管太多了……」。矛盾日積月累，最後公開化，群裡國罵都出來了，公司只好做了調離處理。　

　　觸景生情，聊聊產品經理與研發……

 

一、產品與研發的前世今生

　　這類衝突往往爆發於，研發的leader與產品經理之間。衝突發生的概率與這個研發leader的資歷背景嚴重相關。如果你們公司招聘研發經理時，JD的職位是專案經理，那衝突的概率則更是會大大提高。

• 　　專案經理

　　雖然縮寫都是PM。但比較資深的從業人看到PM，多數首先想到的應該是專案經理。 在前行動網際網路時代，一個一般規模的軟體團隊第一負責人通常是專案經理。

　　彼時承擔畫原型，傳達需求的人員，被稱為需求分析師。產品經理這個詞還很少被提及。

　　專案經理的職責方面，可以通俗理解為專案負責人（區別於狹義的專案經理），負責對接客戶，理解需求，領導專案研發，測試，交付整套流程。（我面試過的研發專案經理，居然還有負責要賬催款要賬的 -_-|| ）。

　　因為對專案全權負責，責任重大的同時，權利也相應比較大。包含，專案預算的制定，需求的確定，人員考核等。需求分析師通常屬於專案經理領導，被專案經理考核，而且交付效果如何，專案經理是第一背鍋人，需求編寫自然要聽專案經理的。

　　可以看出早些年對軟體專案專案經理的素質要求還是很全面的。

• 　　產品經理

　　隨著網際網路（主要是行動網際網路的興起），做「產品型別的專案」的專案比做「客製化型別的專案」要前途遠大光明的多。於是，做產品類「專案」的機會大大增加，進而產品經理這個概念開始被廣泛提及，一本《人人都是產品經理》更是火遍大江南北。

　　產品經理的職責，側重於產品的設計規劃。相當於拆分了之前專案經理做需求分析部分工作的職責，產品設計的好壞，需求是否合理，是不是賣的出去，使用者是否滿意，這些型別的鍋，理論上從專案經理轉移到了產品經理頭上。

　　此時畫原型，傳達需求的人員，也會被叫做產品經理，或者產品助理。

　　但是，現實中受規模限制，頂著產品經理的Title，能實際承擔產品經理的工作，自主為產品設計，和推廣效果負責的產品經理還是很少的。

　　一二十人的軟體公司大把，本小利薄，傾全力打造的一，兩個產品，不可能你說咋做就咋做，往往老闆才是那個真正的產品經理。

 

　　由此可見，現在的產品經理，多數在之前的專案經理眼中，就是他曾經治下的需求分析員，所以公司如果設有產品經理，那就最好不要用「專案經理」的Title招研發負責人了……

 

二、為何而懟

　　大家都知道，美國在中東搞事情，是為了石油！

　　而我們作為科技行業從業者，無意義的衝突也應該儘量避免，損人也不利己。但凡衝突，總要為點兒啥，不該只憑個人好惡或非要爭個高低。工作中還是應該理性經濟一點，少動感情 :-)。

　　然鵝，據我觀察，很多懟產品的研發人員都不清楚自己懟的目的訴求，懟的毫無說服力；而產品經理也不理解自己為啥被懟，被懟的很懵逼。

• 　　需求不合理

　　當研發人員說出這句話的時候。通常代表，以研發人員的經驗，產品提出的需求，比較稀有另類。這其實可以理解為建設性意見。產品經理應該首先審視自己的需求，是否邏輯合理，是否有更好的解決方案，心態開放，不要過於堅持做自己，一路走到黑。

　　如果確認沒問題，產品應該向研發人員闡明設計初衷，研發能認可則皆大歡喜，如果實在談不攏，產品經理的大招就是。「我對產品的定義負責，鍋也是我背，所以只要邏輯沒有矛盾，技術可以實現，大家按我的方案來做就好。」

　　而在研發人員的角度，如前所述，如果公司設定了產品經理職位，產品的定義職責應當就不是研發人員背鍋了。本著「誰背鍋，誰負責」，責權對應的一般原則。產品對所有需求有最終決定權，未來使用者打上門來，也是打產品，不會打你的。

　　如果需求沒有邏輯上的問題，合理性由產品最終決策，研發人員頂多「友情」的提示下，「按你說的來， 那以後有問題，@你哦」。

• 　　實現不了

　　如果研發人員懟出「實現不了」時，這可以算是研發人員的大招了。但作為產品經理也不要輕言放棄，產品經理要評估下你所提需求的實際難度以及必要性，然後決定是否堅持需要實現。

　　如果決定堅持需要實現，常見的回懟策略是。「那競品XXX 和 XXX都實現了，這個功能很常見啊，不然我們PK不過他們啊」。 如果最終談不攏，那就說「要不你向研發領導反饋下，看公司有沒有其他大牛有相關經驗，或者請示下是不是需要招聘這方面的專門人才」，都是很上的了檯面的說辭。

　　而從研發人員角度出發，「實現不了」，這個措辭應當謹慎使用。這其實就是直接承認我不行（男人一般不能說不行）o(*￣︶￣*)o。所以在這麼懟之前，務必考慮清楚，「實現不了」這件事情如果放在桌面上討論時，理由是不是充分，是不是合理，會不會顯得自己太不行：-）。

• 　  實現成本高　　

　　對於實現成本較高的需求，球其實主要在產品經理這邊。相當於研發人員已經給你預警了，實現這項功能預算很高，你要想清楚要不要做，做不做你定。主要是會對產品形成一定的心理壓力。

　　此時產品無非是，慎重思考，選擇堅持或者放棄，切忌說「這個功能我覺得很簡單啊，一天搞定。」這類，YOU CAN YOU UP的引戰的話。如果堅持要做，那麼理由應當充分，以便研發搞出一個天價預算放在桌面上評審時，你能夠說服大家功能有必要做。

　　研發人員從成本角度提出疑問，應當實事求是，注意理由的充分及合理性。如果是人手一個的功能，到你這裡需要一個特別不美麗的價格，研發人員要能經受得住其他人的挑戰。

　　這裡研發人員應該堅守的底線是，複雜的功能自然對應於更長的週期，更高的預算。只要好功能而不給好價錢（資源）的行為，就是壓榨，應該嚴正抗議，據理力懟。同時要避免自我設限，稍微複雜或欠缺經驗的功能就打退堂鼓，給產品經理施加壓力。

•      這不屬於產品需求

　　產品經理應當注意，不要無意義的越界。如果不是必要的需求規格，不要寫在產品需求中，可以交給研發去自行實現，這樣會更加的其樂融融。

　　例如如果你需要一個好吃的蘋果，而顏色無所謂的話，就不必要定義我要一個「紅色」的蘋果，因為也許研發實現成藍色會更加的方便快捷。否則，研發會覺得你管的太寬。每一個明確定義的需求都應當圍繞解決原始需求，有所依據。如果研發的同學問你既然你需要一個好吃的蘋果，那為啥一定要紅色的，你應該有合理解釋，而不是……人家就是想要

　　同時研發的同學應該認識到，所有需求都可以寫入產品需求，寫入產品需求的內容，都是由產品經理背鍋。例如客戶需要一個網站，產品需求要求，後端用Java，前端用Vue+ElementUI，研發的同學可能認為這不屬於產品應該管的事情。

　　然而，如果產品經理給出的解釋是，客戶明確指令要用這樣的語言框架實現，因為客戶有自己的研發團隊，只熟悉這些相關語言技術，後期他們會接手維護，這些要求是寫在商務合同裡的。那麼顯然這是一個非常合理的產品需求，並不是多管閒事。即便他沒有合理解釋，寫到產品需求裡，你可以質疑，但如果產品經理堅持，只要給錢（認可提供相應的資源，週期），你還是要想辦法實現，畢竟他是為成本背鍋的人。

•      隨便加需求

　　如果因為需求錯漏，而變更的需求，作為產品經理，認錯態度要誠懇，讓研發的同學原諒你，從而避免他們把延期交付，因為你搞錯變更了需求的鍋非常講道理的甩給你:-)。

　　如果增加需求是客戶要求，無法推擋，那麼你要向外向上管理，告訴客戶或者管理者，新的需求對應新的設計，開發，測試成本。不要讓，研發的同事義務勞動（只幹活，不提供相應資源）。

　　而研發的同學要心胸開闊，人非聖賢，需求的錯漏，客戶也好，老闆也好，產品也好，難免斟酌後發現新的錯漏，或者有更緊急的事項插入，對變化要持開放的心態。當然如果，只加事兒，不加預算，那還是要用力懟的。

•      之前非要做的，結果都沒業務用

　　產品經理要理解，用心做出來的東西沒人用，確實很傷研發的心，如果是加班生產的那就更傷心:-)。如果是產品經理自己琢磨出來的，那還是低調做人，有錯就認。如果是外部或上級壓力，那就後續儘量做好對上/外，管理，與研發同一戰線，勸他們三思後行，同時，鍋可以適當甩給他們;-)。

　　研發的角度看，做的東西，就像自己的娃，希望他有個好歸宿的心情可以理解。但冷酷點說，誰都希望一次做好做對，而且浪費和試錯的成本，主要還是老闆來承擔了，上班就是出賣勞動力，只要薪水按約定付了，也沒啥好說的，不必太玻璃心。既然僱你來上班就不可能然你閒著，其他的手藝人，哪個不是，你說咋整就咋整，活兒多多益善，給錢就行:-)。

 

三、相處之道

• 只要錢到位，玻璃全乾碎

　　產品經理要有勞動有價的認知，沒有所謂簡單的功能，必然被懟 YOU CAN  YOU UP。如果你提了複雜高大上的需求，增加或者變更了計劃外的需求，那都需要研發的同學，擼起袖子，加油幹，才能將你的需求，落地為功能實現。而你就應該與研發的同學站在同一戰線，向外或向上管理，為研發的同學儘可能多背書，爭取相應的資源（時間，預算）。切忌，用「我提的功能很簡單，他們卻要一年」來拆研發的臺。 

　　研發的同學應當在力所能及的範圍內，多快好省地建設社會主義。複雜的功能，以及計劃外的變更，在配套對應資源的情況下，不應該理解為壓榨，應該理解為鍛鍊機會。永遠做簡單的增刪改查，用最基本的控制元件，需求複雜點兒就不會做，做不了，如何成長為大牛？

• 先說斷，後不亂

　　組織要注意研發與產品經理間可能出現的矛盾，要注意宣貫研發經理與產品經理的職責定位。除了招聘，入職培訓環節，在平時的一些爭議解決中，也要講職責，講流程。績效考核中，應當注意責權對應，誰背鍋，誰決策。

• 　　就這樣被你征服

　　二人互動也必然會分出強弱，征服對方，建立信任還是要憑藉實力。

　　產品經理要擺脫專案經理眼中，「就是個畫圖的戰五渣」的固有成見，要秀出你對行業，對競品的非凡理解，並一直帶領大家走在正確的道路上，使用者越來越多，評價越來越好，錢越賺越多。

　　而研發人員則可以通過強大高效的研發能力，只有想不到，沒有做不到，讓產品經理信任你的技術能力，進而信任聽取你的，成本預估，方案建議。

• 　　合作生，分則死　　

　　產品經理決定了一個產品所可能達到的最高高度，而研發則決定一個產品所能達到的實際高度。產品經理與研發的衝突會導致，產品過度設計，專案成本虛高等內耗問題。最終導致專案很難多塊好省的完成。

　　最終專案不賺錢，老闆也不可能分錢 ，兩敗俱傷。

　　So，和氣生財 ;-)