PMCAFF（www.pmcaff.com）：互聯網產品社區，是百度，騰訊，阿里等產品經理的學習交流平臺。定期出品深度產品觀察，互聯產品研究首選。

外包大師（www.waibaodashi.com）：要外包，找大師。PMCAFF旗下高質量互聯網外包解決方案提供商。外包大師服務號：waibaodashi365

作者：陳峰 PMCAFF會員 挖財卓越財富產品負責人

編者按：

眾所周知程序員和產品經理之間產生矛盾大多是因為一個叫「需求文檔」的東西，那我們應該如何撰寫一份程序員真正需要的需求文檔來解決這個矛盾呢？

本文作者陳峰，曾經在金大師（黃金TD業務）負責企業應用產品線。他基于之前在金大師產品研發團隊的反思與總結，從關聯性、邏輯性、預見性、價值數據化4個角度闡述了他的觀點和思考，以下為正文，歡迎閱讀轉發。

觀點：從來不存在一份完美的需求文檔可以滿足任何程序猿的任何需求。

如果一定要一個答案，那么就是：

讓開發小伙伴認同功能價值，充滿成就感是PM最重要責任之一。實操角度看，從寬度（關聯性）、深度（邏輯性）、長度（預見性）、量度（價值數據化）4個方面出發去描述需求，文檔自然可以畫的清晰、寫的明白。

從下面3個角度分析：

1、因人而異

程序猿也需要畫像區分：

不喜歡任何文檔的程序猿。這類小伙伴記憶力強、理解力好，只要PM說一遍就可以很快理解業務邏輯，想的比PM可能都細致。

對于這類成員，PM的需求文檔力求主業務邏輯清晰，比如開通個人委托扣款的前置條件具體有哪些條件；TA系統進行補單的幾種業務邏輯情況。設計與交互上的邏輯為輔。

喜歡流程圖多過文字與原型的程序猿。這類小伙伴對于圖形有特別偏好，你給他看一堆原型跟文字描述，他會覺得不耐煩。對于這類成員，我們一定要保證流程圖的模塊完整性、邏輯準確性。原型與文檔可作為一些設計與交互邏輯的輔助參考資料。

只喜歡文檔原型且較少交流。他只想安靜的做個Coding的美男子。如果是這類，那么我們就需要準備齊全，圖、原型、文檔，缺一不可。

啥都不喜歡，只喜歡挑刺。接著往下看，當你做完文末部分就可以好好溝通了。

2、因功能而異

前端產品

通用邏輯：原型與文檔并重，功能結構圖與頁面結構圖為首，流程圖為輔。

（1）目前前端產品設計目前比較主流的方法論有：場景論、數據論、功能論、設計論。無論哪一種方法論前端產品就是給C端用戶看并且使用，所以原型跟文檔不可缺少。

（2）這里額外提一句關于原型、文檔的格式。我在剛從業1年的時候，一直糾結原型與文檔是否一并寫入在Axure。這點不重要，尊重開發團隊的習慣就好。

（3）當年我在金生寶就使用Axure＋Word，到了金大師后臺主要用Axure為主。對于一個優秀的PM，這些都是常用工具，需要做到用什么都可以。

（4）如果你有自己常備的一套Word與Axure文檔模板當然會更加高效。

后臺產品

通用邏輯：流程圖、時序圖、架構圖、數據表為主，文檔次之，原型為輔。

（1）后臺產品設計主要方法論有：業務流論、效率成本論、性能論。主要面向企業內部用戶，目的是提升企業整體效率：人的效率與錢的效率，包括獲客效率、服務效率、管理效率、信息流轉效率等，對于感性體驗沒有C端產品那么苛刻，而對于邏輯與數據會加強。

（2）通過圖、表更能便捷、快速的反映基于業務流的本質。一張圖表現的東西，可能用10個原型頁面都未必能畫清除。

復雜的2C、2B功能文檔

（1）抄家伙

（2）業務流程圖、系統交互圖、信息流圖、資金流圖為主

（3）功能列表、頁面結構表次之

（4）原型最末

3、寬度、深度、長度、量度

如何讓需求文檔考慮更周全？我們從4個角度來說：

寬度：考慮到90%的完整性

這在開始比較困難，有以下幾個方法可以讓我們逐漸做到。

（1）重要業務關聯模塊梳理。當產品功能越多，那么新增一個功能就有可能對原有功能產生影響，這就是我們所謂的看得見的耦合。看不見的耦合是在代碼層面。所以平時一定要多關聯業務模塊有更多了解。

（2）重要業務流節點梳理。無論是前端還是后臺產品，都會有1、2條主要的業務流（人體脊柱），這些業務流中的關鍵節點類似人體的脊柱節點。在功能規劃設計的時候，提前需要考慮到。

（3）高內聚低耦合的設計理念。我非常喜歡內聚、耦合兩個詞，好的設計規劃方案可以大大減少開發小伙伴的工作量，便于功能、代碼擴展、重構。

（4）如果業務邏輯的分離不夠導致耦合，則會導致產品功能邏輯耦合在一起，進而使得代碼邏輯耦合在一起，對于擴展、重構就是件很蛋疼的事情。這個設計理念可直接評價一個PM的邏輯、抽象、規劃水平能力高低。有機會我詳細再寫一篇。

深度：100%的邏輯清晰程度

（1）產品邏輯可以簡單類比成代碼中的輸入于輸出關系。我的習慣是畫流程圖避免邏輯上的遺漏。

（2）如果文檔中出現思慮不周的情況，而技術小伙伴已開工，根據我的經驗，不要去彌補這個邏輯的漏洞輕易衍生出新的邏輯。有些漏洞是因為不重要，所以PM會遺漏，如果不重要那么就放在下個迭代進行優化。

（3）不要老搞幺蛾子變動，尤其是已經定稿的開發邏輯。一定要改變，PM自己先想清楚是否會影響到其他功能。

長度：50%的預見性

（1）從0到1，從1到10，從10到100，是產品的不同階段。PM有時像一個軍師需要運籌帷幄。根據市場情況、競爭環境、公司情況、團隊能力、產品成熟度決定什么時候做什么功能，做到什么火候，都是需要提前考慮的。

（2）這點也是直接評價一個PM水平能力高低的主要依據。當然也有一些天才，可以天馬行空設計出一些驚才絕艷的產品，在我看來，他們更有預見、洞察的能力而非胡思亂想的涂鴉之筆。

量度：100%的價值數據化

（1）功能價值數據化，讓開發小伙伴認識到他們的每一天、每一分鐘、每一秒都是在做一件有意義、有意思的事情。

（2）與團隊達成一致的愿景、使命、價值觀，不斷溝通，反復溝通。讓這些深深印刻在團隊成員心中。

（3）讓開發小伙伴更有成就感，為他們掃清前進道路上的所有障礙。與他們站在一起，體諒他們，給他們更積極的反饋。即使在高強度、高壓力的環境下，盡量為他們創造快樂、開心的工作環境。

最后再說幾點個人感悟：

• 記住，我們跟開發小伙伴是一個團隊，重要的不是需求文檔，而是如同一個戰壕的戰友，我們將后背交給對方是因為信任。

• 追求真實、互相信任，因為信任所有簡單，因為簡單所以高效。

• 如果不是這樣，再好的需求文檔又能怎么樣。

參考資料

［1］陳峰. 反思產品如何成為核心 系列31. 2017-03-19

［2］陳峰. 淺論產品文檔PRD怎么寫 系列10. 2016-06-25

［3］邱岳. 公眾號二爺鑒書

［4］張涵. 阿里1688后臺產品部主管

點擊閱讀原文，獲取5000個成熟解決方案

中高端求職 & 招聘，PMCAFF人才服務最懂你

=> alice.zhang@pmcaff.com

總結

以上是生活随笔為你收集整理的程序员到底需要什么样的需求文档?的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。