【編者按】本文作者劉飛，前錘子科技産品經理。
我在哈工大讀書，學的是計算機，寫了六年代碼，畢業後做的卻是産品。
所謂對程式員和産品經理之間的調侃，主要原因無非就在兩方經常有沖突出現，而沖突出現顯然是因為雙方一邊是需求提供方，一邊是需求實作方。沖突的類型也簡單，就是大家提到的這麼幾種。同時寫過代碼，又做過産品的我，實際上仍然沒有很好的通用法則，能解決所有沖突。
不過做過産品總監一職後，的确了解完全不同了。産品工作和研發工作都是我的管理範疇之内，看事情的角度就完全不一樣。
其實從整體的工作配合上來看，出現問題是難免的，關鍵是如何預防、如何解決。
......
很多固執的程式員會把改需求當成錯事。
實際上，在網際網路産品這個領域内，改需求肯定會是家常便飯。
我沒有做過統計，但我接觸到的已經成立一年的公司，幾乎都經曆過大改版，也就是代碼全部重寫。這對研發團隊來說自然很痛苦，但卻是不可避免的。
網際網路的需求更替是頻繁的，一方面是大環境随時在發生變化，去年你還在刷微網誌，今年已經是朋友圈了。另一方面，需求擷取的管道也是多樣的，産品經理可能會有新的發現和新的判斷，未必都是之前沒想清楚。
當然，如果需求都是老闆從什麼《易經》中得到感悟、從雲卷雲舒花開花落裡得到啟示，讓你手忙腳亂給他改來改去，那也沒意思了。
既然改需求是經常會出現的，那就要求還是得做好更改需求的準備。有這麼幾種方法：
讓一些産品中很可能會用得到的各種控件、功能子產品做成可複用性很強的代碼，在産品增加類似功能，或者修改原有類似功能時，将會大有裨益。
可擴充性則是各種接口、資料庫以及底層結構不要寫死，盡量用可擴充的方式寫。比如現在有五個分類，不要寫死就五個，要寫成 n 個分類，目前是五個。嗯，這是常識了，但有的程式員還是會比較随意，寫代碼沒有遠見。
其他的代碼特性，如果有利于降低産品的更改和優化成本，也要加深關注。
每個功能的實作方法都有很多，怎麼選擇并不是隻看當下的成本如何，而是要關注未來産品的整體規劃。
可能目前要完成功能 a，有 1、2、3 多種方案，方案 1 成本最小。但未來要完成 a、b、c、d 很多功能，方案 3 更有利于整體成本最小。那就要選方案 3 未雨綢缪。
多跟産品團隊交流，了解未來産品要做成的樣子、哪些功能會是必須的、哪些功能是可能會有的，多從長遠來看。
首先，不要把研發時間就當作完成時間。研發功能隻是一部分，測試、改 bug 以及處理意外情況的時間都要預留出來。
有兩種情況要多預留出修整的時間。
一種是研發團隊自己對功能沒有把握，可能是全新的功能，可能是比較難做的功能，可能出現許多 bug 和功能實作糟糕的情況，那就要多預留出時間。
另一種是産品團隊表示對功能也有疑慮，比如在提供需求時表示這個功能很有可能要調整，或者對功能本身信心不足，那也要多留時間做調整。
研發團隊通常會缺少對需求的了解，尤其會出現這種情況的就是外包團隊。我聽說過太多花了幾十萬請外包團隊，結果開發的結果特别不滿意，不能拿來用。合同又已經簽好，還得給錢，就是賠了夫人又折兵。
有的技術團隊和産品團隊都坐在同一間辦公室了，居然都經常缺乏溝通。技術團隊不知道目前做的功能是給誰做的、是提供什麼功能、滿足使用者什麼價值的。
這些不是很高深的理論，也不需要深入學習，隻需要通過産品經理做些了解，就能少挖一些坑，也就不會輕易返工。
另外，如果是在開發之前就意識到做出來的功能會跟産品經理想象的不同，那就必須及時提出來，千萬不要等開發完成，大家都覺得不靠譜，再重做，那樣不管對誰來說成本都太大了。
程式員最應忌諱的就是說『這個做不了，說了你也不懂』、『這個太難，懶得跟你解釋』。産品經理聽完肯定會覺得是推卸責任。
這樣一步一步往下解釋，把所有理由說明白，别沒有耐心，隻要産品經理是講理的，他會了解你。
他聽懂了你的解釋，也會有利于他找出另外可接受的一種解決方案。
這樣問題就解決了。
産品經理要在不斷的疊代和更改需求的風險中被程式員認可乃至尊重，我覺得最重要的還是『講道理』。切忌說出『我不管，反正得做完』或者『老闆就這麼定的，我也沒辦法』這樣的操蛋話。
對自己的産品都沒有大緻規劃，是産品經理的大忌，也是出現問題的主要原因。
這些都要認真去考慮并且規劃。
當然，長遠的産品規劃在很多情況下（市場變化、團隊更替、産品轉向）确實用途不大，但越短期的規劃，對研發團隊越有幫助。
把這些規劃想明白，并傳達給研發團隊，讓他們在現在的代碼裡就給未來的功能留下空間，是最好的避免代碼重寫的方法。
這要求産品經理做到兩點：
具體并不是說，要按照大公司的 prd 去完成。而是說，不要缺東西。對于需求文檔來說，頁面邏輯、頁面布局、功能邏輯和每個功能的使用細節，都要存在。并不隻是畫個互動圖就叫需求文檔了。
你給了研發 5 個頁面，結果研發做着做着，來問你，好像缺了個頁面。你補完一個，研發做了一會兒發現又缺了一個...最後七零八碎的 10 個頁面拼湊出來，發現根本不好用，是以又推倒重來。
如果研發經常來問你某個地方該怎麼做時，你就要反思是不是需求文檔寫得不夠好了。
第二，要說明每個需求背後的原因。
這個在上面表達過，程式員明白了需求背後的原因，會選擇更合理的方案去完成。
千萬别提『你别管為什麼了』，而是不管他問不問這個功能為什麼要做成這樣，都要告訴他為什麼。
『産品經理到底需不需要懂技術』是我被問到的關于産品經理的問題中的 top 5。
這個問題我的回答是：要按照需求，了解基礎知識，并不需要知道實作細節。
以上是我的一些了解。希望對大家能有所幫助。