正好前兩天因為售後系統的功能需求跟後臺工程師鬧了一點小矛盾。後來自己仔細想了想還是著重在總結尋找自己的問題，順便看見這個問答寫在這裡供大家參考。

產品經理可能是一個公司最不受人喜歡的崗位，你自己想一想，運營和市場會催著你趕快實現產品需求，設計會指責你隨意修改她的設計，開發會嘲諷你看不懂程式碼還要瞎BB，也就只有老闆偶爾會向你投來關懷的眼神，因為“產品經理是一家公司最適合做CEO的人”。

其實做產品一年多以來，經手了兩個大專案設計（電商小程式、電商後臺）、十多個小需求修改（積分商城、會員體系、拉新機制），其中跟開發鬧矛盾的次數還是有的，不過也沒有到那種“肉搏”的階段，現在想來，想要避免衝突，除了有個好的心態和性格，更重要的是做事的經驗。

對產品MVP的明確定義：產品MVP指的就是可滿足的最小開發需求，其實有時候對於需求的定義不充分就會導致矛盾。這其實就是考驗著產品的規劃能力，到底是先簡單試一下，還是一次性做全？迭代應該怎麼迭代？第一版做到哪些功能？這些都需要產品事先給到明確需求。

站在開發者的角度想問題：爭吵的核心，其實來自於對立面的樹立。如果你下意識想到：我是怎麼怎麼樣想的，他是怎麼怎麼樣想的，那麼必然會引起爭吵。這時候產品應該想的問題是：他為什麼會那樣想？然後從開發的角度探討問題，進而做到反駁他們的想法：這樣做是不是需求更麻煩了？你們會不會壓力更大？是不是難以保證按時上線？尊重設計師的決定：設計師對於產品開發而言是非常重要的環節，設計師的進度會直接決定前端和後端的開發進度，所以產品與設計通常需要保持良好的合作關係。那麼產品就要尊重設計師的設計決定，同時不要在原型圖上新增顏色干擾設計師做判斷，只要是按照產品預想的功能在畫，那麼適當的調整和修改是可以接受的。讓工程師自己定時間：專案一過需求評審，就進入了漫長的開發階段，此時確保產品按時上線的KPI，就抗在了產品的腦袋上。所以當你拆分好需求做好甘特圖之後，時間的節點最好交給工程師自己來定，並非說一定按照他們的意願，而是給到足夠的彈性空間，給到自己談判的餘地。比如第一個需求做了3天，第二個需求又提出3天的時間，但是第二個需求明顯要簡單很多，那麼這時候你就可以向開發施壓了。多喝茶、多吃菜、多睡覺、多讀《資治通鑑》

產品經理的確是網際網路入行門檻最低的崗位之一，想做好了真不容易，與其說是做產品的能力，不如說是做人的能力。大家還是相親相愛吧，都是996的人，何苦要為難彼此~

如何讓程式設計師“放下刀”，說明產品經理已經提出了讓程式設計師拿起刀的需求。這時候多半程式設計師和產品經理已經產生了衝突。

如果要避免衝突，首先產品經理要和領導、市場、運營等部門對接，確定功能點。

程式設計師並非不通情理，只要時間足夠，雖然有牴觸，單不會太反抗。有衝突可能是時間不足夠，功能點又多。

在時間不夠的情況下，儘量減少非必要的改動，很多產品經理更改UI既沒有使用者操作資料支援，又沒有完備的合理性，完全是COPY其他的產品，或者是看自己心情更好。

在程式設計師將程式碼寫好之後，產品經理不要輕易改動需要，這是最大的禁忌。其實產品經理也不會輕易改動需求，大多都是領導讓改的，這時候產品經理儘量跟程式設計師站到一起儘量爭取不要改動。領導非要改的話，你要把情況委婉的告訴程式設計師，這時候刀尖就不會指向你了。

首先說一下 我現在和產品同學的關係 比較融洽 我們也溝透過型別的問題 主要有以下幾個方面來分析一下

1 術業有專攻 做事情 處理問題的角度不同 有時候可能產品一句話 程式設計師就要通宵改程式碼 各自付出的成本天差地別 所以容易產生矛盾

2 所屬不同 上方所屬職門不同 管理所屬不同 容易產生分歧 這種情況需要將自己不可控的風險向上丟擲也就是向你的上級彙報風險盡以郵件形式抄送相關人員 不要自己認為可以掌握

3 換位思考 有矛盾可以爭吵 儘量控制情緒 不要有攻擊性 容易產生工作以外的矛盾 大家都是為啦掙錢嘛 和氣生財

4 我個人認為也是最重要的 溝通之道 多溝通將問題 矛盾都以交流的方式表達出來 既加深啦對專案的理解 也加深這種跨部門的交流 以後工作的時候雙方也會更加了解對方 工作起來更方便些

以上是個人愚建 如有不對之處請包涵

8年產品經理生涯，跟開發意見不一致的情況很多，但從來沒紅過臉。

01 真正理解為什麼要設定兩種崗位：“產品經理”和“程式設計師”？

筆者讀大學那會兒，沒有“產品經理”的概念，我們在大二臨近寒假時組建了一個軟體團隊，承接第一個專案時，只有開發和測試，後來專案結果可想而知，整個團隊10來號人，辛苦努力了3個月的成果沒有得到客戶的認可。當時我的心情是：shit，我平生最恨的事情，就是老孃辛苦的成果不被人所尊重，更見不得一群兄弟被客戶削。痛定思痛，我開始尋找解決方案。

《head first軟體設計》、《UCD火花集》、《人月神話》、《質量無淚》幾乎一個學期的時間，在圖書館中讀完了這四本書，又在軟體工程院長的引導下，學習了一個工具Axure，然後在大二暑假時，我又參與了第二個專案，這個專案總金額在500萬左右，當時花了很大的力氣說服領導，採用原型方式，先跟客戶透過原型方式確認需求，讓大家的想法先視覺化。然後以始為終，再進行開發。跟客戶共同努力了1個月左右，我們畫出了系統的原型頁面，我深入地理解了客戶的信訪業務，同時客戶因為參與了產品設計，因此對產品研發非常有信心，在產品開發過程中，除了進度外，幾乎沒有需求上的變更。

當時那位客戶說：小周，你將來一定能成為一個優秀的產品經理。——那是我第一次聽說產品經理。

這就是我從開發轉向產品的故事，同時也讓我真正理解了產品經理在整個產品研發中所肩負的使命：以使用者為中心進行產品設計，不讓開發浪費時間。如果以此為使命，開發人員愛我還來不及，又怎麼會向我舉刀？所以8年產品經理生涯，深度合作過的架構師、核心開發不下200號人，至今仍然是非常好的戰友。

當然有的網際網路產品經理會說，客戶專案有客戶給我撐腰，自然跟開發少爭論。但後來在我負責的公務員考試的網際網路專案中，我仍然堅持：以使用者為中心進行產品設計，親自參與過兩次公務員考試，並且跟考生群和老師群都建立了非常頻密的交流，正是因為了解使用者，所以開發願意信任我。因此，不管是網際網路專案還是客戶專案，堅持去了解使用者，減少個人主觀猜想，成為職業的產品經理人，才能獲得開發的信賴。

不管公司是否在正式架構上對產品經理、開發經理進行了明確的職責分工，任何時候你自己需要遵循並且也要讓你的開發經理也清楚這個規則：產品經理負責使用者可以感知的功能、體驗等產品設計工作的決策，開發負責實現方式決策，雙方可以互提意見，但不能越俎代庖。

進入正式的工作後，尤其是這兩年在北京擔任某知名大資料公司的產品總監後，讓我苦惱的是，開發遇到產品需求中明顯不太合理或者稍微改動下就能節省很大力氣的地方，但是卻不敢提出來，而是自己死磕，於是我在團隊裡面制定了一個新的規則：但凡找出我的需求bug者，獎勵團隊奶茶或下班後腐敗。

03 真正優秀的產品經理不應該把格局只放在產品研發層面

前兩週有一位大健康大資料產品經理找我開小灶，談及他面臨一個全新的業務時，所有公司能夠提供的資料他都拿到了，但是卻不知道如何著手自己的“反欺詐”業務。我在他電腦上看了下他從各個業務組和專案組拿到的對於系統碎片化的流程圖和功能說明，頓時明白，很多新手在理解產品設計時傾向於從“功能”本身去理解產品，這是大忌。實際上產品功能的生命週期是非常短的、業務的生命週期略長、實體的生命週期較之二者往往是更長的。“反欺詐”的關鍵是風險，而公司已經識別的“風險”有哪些？“欺詐事件”有哪些？“欺詐者”都是哪些人？對欺詐事件本身展開研究，對欺詐者進行精準分析，瞭解欺詐者內外環境，才能對欺詐行為有所預見，真正把“反欺詐”業務做好。

04 產品經理的真相

過去一年我都在思考產品經理的真相：

首先，產品經理是介於哲學家和科學家之間的使徒，既要去思考萬事萬物存在的意義和去向何方，又要用科學的手段將概念中的社會價值、商業價值轉為現實中的商品。

其次，產品研發是一個“無中生有”的過程，你可以自認為看到了未來，信心爆滿，但一定要對尚未到來的未來保持謹慎，任何你所能聽見的反對的聲音都將完善我們的思路，而非挑戰，真正挑戰的是你並未發現的問題。

最後，既然選擇了從事這樣一個讓未來到來的事業，期望你能把世界引導到一個更加充滿愛、更加釋放人們想象力和好奇心的未來。