記得之前參加團建活動，是真人 CS。我們一共沒幾個產品經理，但有幾十個程式設計師。所以場面估計你也能想象出來了……並不是刺激的對戰，而是慘絕人寰的群毆。

被 BB 彈打成狗（哎，原來不就是狗嗎）的一個產品經理急中生智，大喊：『我以前也寫過程式碼！我是自己人！』

其他正在施暴的程式設計師面面相覷，表示十分感動，但仍然拒絕了他的求情，繼續按在地上打了半個小時。

……

我在哈工大讀書，學的是計算機，寫了六年程式碼，畢業後做的卻是產品。

所謂對程式設計師和產品經理之間的調侃，主要原因無非就在兩方經常有矛盾出現，而矛盾出現顯然是因為雙方一邊是需求提供方，一邊是需求實現方。矛盾的型別也簡單，就是大家提到的這麼幾種。同時寫過程式碼，又做過產品的我，實際上仍然沒有很好的通用法則，能解決所有矛盾。

不過做過產品總監一職後，的確理解完全不同了。產品工作和研發工作都是我的管理範疇之內，看事情的角度就完全不一樣。

過去做程式設計師，總覺得提供的需求更改很煩、給的需求不合理很煩、給的截止時間不合理很煩。

做產品經理的時候，也會覺得程式設計師總是推卸責任、完成得不及時或者不夠好。

其實從整體的工作配合上來看，出現問題是難免的，關鍵是如何預防、如何解決。

……

以下是一些切身體會得出的經驗性建議：

對於研發人員：

1. 做好更改需求的準備

很多固執的程式設計師會把改需求當成錯事。

改需求？你怎麼不早想清楚？

改需求？你知道我工作量多大嗎？

改需求？那我不幹了。

實際上，在網際網路產品這個領域內，改需求肯定會是家常便飯。

我沒有做過統計，但我接觸到的已經成立一年的公司，幾乎都經歷過大改版，也就是程式碼全部重寫。這對研發團隊來說自然很痛苦，但卻是不可避免的。

網際網路的需求更替是頻繁的，一方面是大環境隨時在發生變化，去年你還在刷微博，今年已經是朋友圈了。另一方面，需求獲取的渠道也是多樣的，產品經理可能會有新的發現和新的判斷，未必都是之前沒想清楚。

當然，如果需求都是老闆從什麼《易經》中得到感悟、從雲捲雲舒花開花落裡得到啟示，讓你手忙腳亂給他改來改去，那也沒意思了。

既然改需求是經常會出現的，那就要求還是得做好更改需求的準備。有這麼幾種方法：

1. 1 提高程式碼的可複用性、可擴充套件性等等

讓一些產品中很可能會用得到的各種控制元件、功能模組做成可複用性很強的程式碼，在產品增加類似功能，或者修改原有類似功能時，將會大有裨益。

可擴充套件性則是各種介面、資料庫以及底層結構不要寫死，儘量用可擴充套件的方式寫。比如現在有五個分類，不要寫死就五個，要寫成 n 個分類，目前是五個。嗯，這是常識了，但有的程式設計師還是會比較隨意，寫程式碼沒有遠見。

其他的程式碼特性，如果有利於降低產品的更改和優化成本，也要加深關注。

1. 2 根據產品規劃來做好充分準備

每個功能的實現方法都有很多，怎麼選擇並不是只看當下的成本如何，而是要關注未來產品的整體規劃。

可能目前要完成功能 A，有 1、2、3 多種方案，方案 1 成本最小。但未來要完成 A、B、C、D 很多功能，方案 3 更有利於整體成本最小。那就要選方案 3 未雨綢繆。

多跟產品團隊交流，瞭解未來產品要做成的樣子、哪些功能會是必須的、哪些功能是可能會有的，多從長遠來看。

1. 3 合理預留出修整的時間

首先，不要把研發時間就當作完成時間。研發功能只是一部分，測試、改 BUG 以及處理意外情況的時間都要預留出來。

有兩種情況要多預留出修整的時間。

一種是研發團隊自己對功能沒有把握，可能是全新的功能，可能是比較難做的功能，可能出現許多 BUG 和功能實現糟糕的情況，那就要多預留出時間。

另一種是產品團隊表示對功能也有疑慮，比如在提供需求時表示這個功能很有可能要調整，或者對功能本身信心不足，那也要多留時間做調整。

2. 理解需求，防止返工

研發團隊通常會缺少對需求的理解，尤其會出現這種情況的就是外包團隊。我聽說過太多花了幾十萬請外包團隊，結果開發的結果特別不滿意，不能拿來用。合同又已經簽好，還得給錢，就是賠了夫人又折兵。

有的技術團隊和產品團隊都坐在同一間辦公室了，居然都經常缺乏溝通。技術團隊不知道當前做的功能是給誰做的、是提供什麼功能、滿足使用者什麼價值的。

這些不是很高深的理論，也不需要深入學習，只需要通過產品經理做些瞭解，就能少挖一些坑，也就不會輕易返工。

比如，有的產品頁面可以是提前載入快取，也可以是每次都重新整理，但要看使用者平常是在 WiFi 環境下用還是在移動資料下用，這是產品經理清楚的。產品經理在功能細節上不會想到實現層面這麼具體，所以就需要研發團隊去理解剛才說的需求，做一些判斷。

另外，如果是在開發之前就意識到做出來的功能會跟產品經理想象的不同，那就必須及時提出來，千萬不要等開發完成，大家都覺得不靠譜，再重做，那樣不管對誰來說成本都太大了。

3. 善於用資料、理論以及通俗的解釋來進行溝通

程式設計師最應忌諱的就是說『這個做不了，說了你也不懂』、『這個太難，懶得跟你解釋』。產品經理聽完肯定會覺得是推卸責任。

正確的方式是：用通俗易懂的客觀事實來解釋。

嗯，這個彈窗做不了。

為什麼現在做不了？是因為程式碼實現可能要花三個月。

為什麼這麼久？是因為需要呼叫底層驅動層面的東西。

為什麼要呼叫底層驅動的東西？是因為安卓系統原本的框架和協議就是這麼定的。

如果想看協議，我可以給你找出來。

這樣一步一步往下解釋，把所有理由說明白，別沒有耐心，只要產品經理是講理的，他會理解你。

他聽懂了你的解釋，也會有利於他找出另外可接受的一種解決方案。

哦，我懂了，這個用彈窗形式太複雜。

那我們換作跳轉到普通頁面吧。

這樣問題就解決了。

對於產品：

產品經理要在不斷的迭代和更改需求的風險中被程式設計師認可乃至尊重，我覺得最重要的還是『講道理』。切忌說出『我不管，反正得做完』或者『老闆就這麼定的，我也沒辦法』這樣的操蛋話。

1、對產品功能有規劃，並提供給研發

對自己的產品都沒有大致規劃，是產品經理的大忌，也是出現問題的主要原因。

一年後產品成熟了要給使用者解決怎樣的問題？

未來半年內產品要做成什麼樣子？

三個月內產品應該主要提供哪些功能？

這一個月的產品具體方案是做哪些？

這些都要認真去考慮並且規劃。

當然，長遠的產品規劃在很多情況下（市場變化、團隊更替、產品轉向）確實用途不大，但越短期的規劃，對研發團隊越有幫助。

正常來說，預估三個月內產品的功能還是完全可以的，除非老闆和產品經理都沒想明白產品到底該做成什麼。

把這些規劃想明白，並傳達給研發團隊，讓他們在現在的程式碼裡就給未來的功能留下空間，是最好的避免程式碼重寫的方法。

2、提供需求要足夠具體

這要求產品經理做到兩點：

第一，讓產品需求文件特別特別具體。

具體並不是說，要按照大公司的 PRD 去完成。而是說，不要缺東西。對於需求文件來說，頁面邏輯、頁面佈局、功能邏輯和每個功能的使用細節，都要存在。並不只是畫個互動圖就叫需求文件了。

你給了研發 5 個頁面，結果研發做著做著，來問你，好像缺了個頁面。你補完一個，研發做了一會兒發現又缺了一個…最後七零八碎的 10 個頁面拼湊出來，發現根本不好用，所以又推倒重來。

如果研發經常來問你某個地方該怎麼做時，你就要反思是不是需求文件寫得不夠好了。

第二，要說明每個需求背後的原因。

這個在上面表達過，程式設計師明白了需求背後的原因，會選擇更合理的方案去完成。

千萬別提『你別管為什麼了』，而是不管他問不問這個功能為什麼要做成這樣，都要告訴他為什麼。

3. 熟悉基本的研發背景和研發能力

『產品經理到底需不需要懂技術』是我被問到的關於產品經理的問題中的 TOP 5。

這個問題我的回答是：要按照需求，瞭解基礎知識，並不需要知道實現細節。

瞭解基礎知識、不需要知道細節是指產品經理應當知道最基本的一些理論。

比如做安卓作業系統，要知道安卓原生提供了哪些控制元件，這樣在設計方案時可以儘量使用它們。在程式碼實現時，呼叫一個控制元件可能只需要幾行程式碼，但自己重寫一個功能介面，可能就是成千上萬的程式碼量了。

比如是在手機網頁上的產品，要知道哪些互動是在 H5 上較容易實現的，而哪些互動是實現效果非常糟糕的。如果依照在 iOS 上的動畫效果來要求 H5，開發成本可能會是指數級上升的。

按需，是說對於產品經理，千萬不要買《iOS 入門指南》、《安卓開發手冊》或者《H5 設計例項》來學習，除了裝點下書架不會有別的意義。

因為本身開發的指南和手冊，講述的全是實現細節，對你清楚安卓的基本控制元件或者 H5 的常用互動完全沒有幫助；同時，不同的產品有不同的特性，也有不同的程式碼特點，你只需要瞭解你負責產品的技術背景即可，有的同學居然決定從 C 語言先開始看，簡直是讓人扼腕。

以上是我的一些理解。希望對大家能有所幫助。

如果此文真正減少了你與程式設計師/產品經理之間的互相傷害，請私信或留言告訴我，我會非常欣慰。