你見過或者撰寫過認為最優秀的產品需求文檔是？

01-21

是否有相對成熟規範的文檔，可以拿出來分享分享互相學習學習。

沒有最優秀的文檔，只有最合適的文檔。不同的公司和團隊差異都挺大的，大家需要的文檔也都不一樣。

產品需求文檔的核心作用：溝通（傳遞信息）與記錄（吵架依據）。

溝通層面：

1、大公司和小公司的差異；對於大公司而言經常產品在這一棟樓，設計和技術在另外一棟樓，每周見面的次數也很有限，每換一個項目就可能換一批技術同學。這個時候你的文檔就必須得寫得清晰詳實了，盡量不要漏掉任何一個環節，溝通的事主要靠文檔，輔以郵件、IM和開會了，文檔生成的時間可能比較長。對於小公司而言經常設計在你對面，技術在你左右，你打個嗝他們都會聽到，這個時候就沒必要費那麼多的時間去寫文檔了，文檔寫清楚最核心的東西就可以了，兩三天足以搞定，溝通主要靠文檔和吼一嗓子。畢竟，大家都不願意看幾十頁幾百頁的東西，會吐很久的~

2、每個人的差異：同學A開發時從來不看文檔，喜歡自己YY，他說每次看到一堆字和圖就想吐，那麼，你只能跟同學A多聊聊了，不停的給他說這個功能是怎麼回事，那個功能是怎麼回事，一直說到他能重複為止，文檔寫得再好都是扯淡。同學B看文檔從來不看文字部分，只看圖，那麼針對他寫的文檔或文檔中針對他的那一部分就得多用圖了，把文字精簡一下放到圖裡，這樣他真的就會看了。同學C是個好隊友，每次文檔都會認真看完，做事比較嚴謹，那麼針對他你就得認認真真得寫清楚了，可別漏掉什麼東西，不然他會不停的抱怨。

記錄層面：

我艹，你這做的什麼東西？文檔里寫得清清楚楚的，是你這樣做的嗎？趕緊給我改！

當然，記錄比吵架更重要。

需求文檔不是目的，只是一種手段，如果描述得足夠清楚，直接用原型都可以，其實開發也不是很喜歡看文檔的，尤其是寫得不清楚的文檔，理解成本高。

第一，國標中有完整的軟體項目過程文檔模板，這個是比較權威的版本，各個單位一般在此基礎上進行修改和剪裁；

第二，不贊同蘿蔔白菜各有所愛的說法，從CMM3開始算是有了項目管理到CMM5，對文檔的要求逐步嚴謹和提高，可以去看看CMM5對質量管理的要求和文檔質量，也可以看看日企是怎麼搞文檔的；

第三，搞一個好文檔比搞一個Demo要難得多。

需求文檔是寫給研發看的，並且有備案價值。要評價好壞，自然該由研發人員評價。

說實話，我自己寫完的文檔，自己都不想再看一遍，實在枯燥，雖有圖片，也有大量的規則注釋。

曾經已將需求文檔中的需求寫的盡善盡美，在研發過程中不修改需求文檔為追求目標。但始終沒有達到，唯一比較接近的是一個抽獎的小應用，還修改了一點規則。

合作過很多研發，基本上不看需求文檔，就看看原型，然後就是隨時的溝通。

最感動的是一位.net的同事，文檔看的相當仔細，有批註，有記錄，還根據文檔自己列了一個超級複雜和專業的表格來解釋數據關係。特別認真，唯一的一個

產品文檔就是留在功能不符的時候pk用，再有就是給記性不好的同學說這塊啥邏輯補漏用的。並且巨長無比。個人感覺開發同學會掃一下，然後按原型做，及你給的簡要產品需求概述開發。

我的經驗是，原型盡量一致與你要的需求，核心功能點要寫清，重要邏輯寫清且和開放確認

不管是開發，還是測試，都是你的MRD的用戶~~

想想他們的需求是什麼~~

產品文檔沒有好壞，只有合不合適。

在一群聰明人的團隊里，和一群傻逼的團隊里，文檔天差地別

蘿蔔青菜各有所愛，沒有好的，只有合適的。即使說標準規範，哪裡又有標準和規範呢，各家有各家的要求。

對小公司而言，開發、設計就坐你旁邊，壓根沒必要為了寫文檔而寫文檔的，PRD需求文檔最主要的目的，即是為了說清楚功能，具體的需求能在Demo原型上面說清楚明白，開發看起來也舒服，幾十頁全是文字的word，換誰看都夠嗆的。

大公司我沒待過，可能確實有這個必要，人員多了，溝通沒那麼方便！

我覺得只要能夠儘可能準確的傳達產品理念、思路、流程的文檔都是優秀的文檔，沒有必要刻意標準化PRD，即使是有標準的也只能是一個描述產品的思路而已。

產品需求文檔可以看作是產品經理與其它項目相關人員溝通的一種渠道和方式，所以只要用盡量合理的方式，傳達產品的信息，思路，流程都OK，在某些情況下，高保真的原型，Demo也可以替換其作用。

寫完後，交給開發同學審閱（如果對方看的話），提出修改意見，然後再改。

（坦白說，我自己沒寫過優秀的，也沒見過）