個產(chǎn)品實戰(zhàn)方法，讓程序員對你刮目相看！在許多段子里，產(chǎn)品經(jīng)理和程序員都是相愛相殺的生死冤家，而在真實工作中，對于許多初入職場的產(chǎn)品新人，的確也會面臨如何與開發(fā)相處的困惑。常常是你提需求他說實現(xiàn)不了，你評審他質(zhì)疑為什么這樣設計，上線出了問題他說是你方案沒考慮到……莫非產(chǎn)品經(jīng)理和程序員真的就不能和諧相處么？

你好，我是當過7年武警國防生，工作3年躲過6輪裁員，現(xiàn)在大廠做產(chǎn)品的小雨。

回顧自己4年產(chǎn)品生涯最驕傲的事就是基本跟每個深度合作的開發(fā)都協(xié)作得高效又開心。其實最初我跟開發(fā)也是沖突頻頻，直到在實踐中摸索出3招，才跟開發(fā)處成了兄弟?，F(xiàn)在開發(fā)們不僅不砍我需求，還會主動提優(yōu)化建議甚至自閉環(huán)優(yōu)化上線，遇到緊急需求也都是無條件協(xié)作。那么我是如何做到的呢？今日就把這3招教給你。

一、產(chǎn)品方案要靠譜

一個值得被開發(fā)信任的產(chǎn)品經(jīng)理，最重要的特點就是專業(yè)度高。

你要確保自己出品的每份PRD都屬精品。需求背景調(diào)研廣泛、數(shù)據(jù)充分，方案框架流程清楚、規(guī)律自洽，需求詳情細節(jié)詳實、邊界明確。這里我不做具體介紹，你可以多參考優(yōu)秀的PRD范本。

除了PRD寫得好，體現(xiàn)專業(yè)度還有一個要點是：每個產(chǎn)品決策都要有依據(jù)。不管是基于用戶場景分析、競品調(diào)研，還是依靠數(shù)據(jù)洞察，要能在開發(fā)提出質(zhì)疑前就先把關鍵問題解答清晰。

那么靠譜的產(chǎn)品方案為什么能讓開發(fā)立即對你刮目相看呢？

第一，更簡單拿到符合預期的結果，有助于他們述職和晉升；其次，他們不用考慮太多產(chǎn)品規(guī)律，根據(jù)方案設計技術實現(xiàn)即可，節(jié)省時間精力；第三，能最大限度避開由于考慮不周造成的線上問題，他們背鍋踩坑的風險更低。

舉個我自己的例子，我熟悉許多產(chǎn)品經(jīng)理PRD都寫得很簡潔，背景一筆帶過，需求協(xié)作原型圖做簡潔描述，缺乏規(guī)律細節(jié)，有時候甚至消失“一句話需求”。因此他們在評審時常常會被開發(fā)打斷確認規(guī)律，有時雙方甚至在會上撕逼。

而我的PRD，從具體的背景調(diào)研，到清楚的流程圖、用例圖，再到各種邊界場景的展現(xiàn)交互規(guī)律一應俱全。

甚至在對于優(yōu)待湊單引導欄這種簡單規(guī)律的描述之后，我都會列上case表格，窮舉各種可能的場景和處理方式。

開發(fā)依據(jù)我的PRD可以直接進入技術方案設計，因此我的評審會基本都特別高效，甚至不會收到提問，會后也很少有Todo。

這不僅保障了需求的質(zhì)量，還讓我能在評審完上一個需求后安心投入下一個需求而不用擔憂被打斷。

要知道沒有一個開發(fā)是不情愿與專業(yè)產(chǎn)品經(jīng)理合作的，因此要想跟開發(fā)和諧相處，最有效的方法就是讓自己變得更專業(yè)。

二、把開發(fā)當做共創(chuàng)伙伴

雖然大家都想工作得更輕松，但其實沒有人心甘情愿變成工具人。不把開發(fā)當工具人，而當做方案的共創(chuàng)伙伴，是你需要培育的理念。

詳細怎么做呢？我的建議是：方案階段預溝通+評審階段背景同步。

許多產(chǎn)品經(jīng)理為了省事，習慣完全敲定產(chǎn)品方案后直接拉需求評審。

對于簡潔的小需求這樣做無可厚非，但對于簡單的大項目，跟開發(fā)進行預溝通不僅能提前了解技術上的難點，還能通過開發(fā)視角感知上下游改動，準時引入相關方避開造成需求遺漏。

比如我以前不做預溝通，常常消失評審會上發(fā)覺還涉及其他模塊改動，但是沒拉相關產(chǎn)研，導致整個項目節(jié)奏受到影響。后來習慣預溝通后，不僅沒再消失沒拉相關方而重復評審的狀況，還能對開發(fā)成本有所預期，提前考慮砍掉某些低ROI的需求點。

還有些產(chǎn)品經(jīng)理評審時花在同步背景上的時間就少之又少，這樣做雖然看似能節(jié)省時間，卻會造成開發(fā)們一頭霧水。開發(fā)們只知道產(chǎn)品想做啥，卻不知道為啥做，不僅難以貢獻自己的想法，還簡單對需求提出挑戰(zhàn)。

因此我建議：無論多簡潔的需求，都要進行具體的調(diào)研，把背景和目標完善清楚。在你做到這些的基礎上，甚至可以對方案中一些拿不準的邊界規(guī)律寫上一句“以技術方案為準”。

當你花功夫這樣做，不僅能讓需求本身更靠譜，而且對開發(fā)的感受同樣有益。

首先能給開發(fā)帶來業(yè)務參加感，感受到自己寫的代碼將制造的業(yè)務價值；

其次也能讓他們在明確需求目標的前提下，以技術視角給出自己的建議，從而對項目產(chǎn)生歸屬感和成就感；

最終也是最重要的，能感受到你這個產(chǎn)品經(jīng)理賜予他們的敬重和信任。

反之，假如你不這樣做，開發(fā)就會由于感受不到項目對業(yè)務的價值和你對他的敬重，而漸漸丟失做項目的動力和跟你協(xié)作的熱忱，成為擺爛的工具人。

我熟悉個姐們，她是一個特別強勢的產(chǎn)品經(jīng)理，要求對自己的需求把握“獨裁”式的話語權。

只要開發(fā)提看法她就會擺出一副“我是產(chǎn)品還是你是產(chǎn)品的”姿勢，結果跟她合作的開發(fā)都不再主動。

有次她一個大需求遺忘寫需要上線的客戶端了，開發(fā)默認就只支持了主App端，結果微信小程序等其他幾個核心客戶端都沒上線，甚至由于沒做端控而出了線上問題。當大老板氣概洶洶找來時，開發(fā)們紛紛表示是產(chǎn)品沒提其他端需求。其實功能同步迭代各個客戶端早就應當是大家的共識，而她由于平常把開發(fā)當工具人，這次不得不自食惡果。

當你開頭跟開發(fā)一起共創(chuàng)方案，你們就不再是上下游的合作方，而是同一條船上的伙伴，彼此信任，共同前行。

三、賜予充分的理解和支持

許多人都知道職場中與人為善，處理關系的法門是具備同理心。那么產(chǎn)品經(jīng)理要如何做才能讓開發(fā)們感受到理解與支持呢？我的答案是：平常不壓迫+關鍵時刻挺身而出。

平常不壓迫的詳細表現(xiàn)包括不催排期和接受延期。

除非有不行抗力否則絕不要求倒排期，評審后不焦急催排期。給開發(fā)充分的時間做技術方案設計，并基于技術方案給出客觀的排期。

假如開發(fā)過程中消失意外狀況，比如系統(tǒng)簡單度超預期，或踩了之前留的坑造成未評估到的額外工作量。你要能樂觀參加其中明確問題，考慮是否可以把那些造成實現(xiàn)簡單度提升但重要性較低的需求點放入迭代。假如的確有必要做，則要能接受延期。明確延期后，樂觀協(xié)調(diào)測試確定新的排期，并做好各方信息同步，保證下游影響可控。

除了正常項目推動過程中不壓迫，你還要能在發(fā)生線上故障等關鍵時刻挺身而出。

線上故障的發(fā)生率和影響面與開發(fā)的績效息息相關，沒有一個開發(fā)不厭煩處理故障。而此時你作為他們的頑強后盾，應當英勇地站出來關心協(xié)調(diào)相關方協(xié)作解決問題。并在事后樂觀協(xié)作復盤，提出一些建設性看法避開后續(xù)再犯相像錯誤。

假如你能做到這些，開發(fā)們的感受如何呢？

當你停止壓迫，就不會激發(fā)開發(fā)們的抵觸心情，不僅能讓他們更主動，還能避開由于估時不準造成的加班，或者有意拉長排期導致項目延期。

當你在關鍵時刻挺身而出，他們會感受到被理解和支持，從今不再只把你當做提需求的產(chǎn)品經(jīng)理，而是榮辱與共的戰(zhàn)友。

我也是付出了一些代價才明白了這個道理。

我剛進入大廠時，由于急于求成，常常強勢地催排期，需求不滿意預期時，我甚至會拉開發(fā)老板來進行施壓。

結果有一個跟我合作的前端由于壓力太大而失眠痛哭，這件事傳到了前端組，我的口碑一度變臭，以至于從前端老板傳到了我老板這兒。于是我有了第一次被老板1v1約談批判的經(jīng)受。

這件事后我深刻反省了自己的問題，不僅不再施壓，還在許多關鍵時刻幫開發(fā)擋掉簡單踩雷的惡心需求。

而跟那個被我逼哭的前端同學，我們喝了幾頓大酒放開心扉，最終處成了能相互幫彼此背鍋的兄弟，雖然他現(xiàn)在已經(jīng)另謀高就了，但我們還時常保持著聯(lián)系。

用實際行動賜予開發(fā)們理解與支持，他們也會給你最有力的回報。

四、最終的話

產(chǎn)品經(jīng)理是一個布滿挑戰(zhàn)、細碎、心酸的職業(yè)，獨自面對職場的暴風雨是難以走遠的。

最好的成長策略是與身邊的