互聯網產品的需求文檔寫作，應該注意哪些事項和規範？
----------------------------------------------------------------------------------------------
需求文檔註定是給所有人看的，它就是產品的定義。
- 文檔圍觀的人包括：你的老闆（如果產品夠大，還會需要老闆的老闆），設計師，工程師，測試工程師。有時還應該包括產品前端：如運營，銷售，甚至市場部同事。
- 在通過各方的評審和簽字後，一般來說，這個文檔就是一錘定音的事。若有更改，就是需求變更了。
- 所以，在需求文檔撰寫前和撰寫中，對產品方向和用戶的把握要足夠強，從產品目的，到每個鏈接的含義，都需要準確地定義。基本上，當你開始寫文檔時，應該萬事俱備。一邊想一邊寫，那說明你還沒有想明白這個產品是怎麼回事。
- 在有些公司，需求文檔會包括產品的最終設計界面。即在文檔提交給大家圍觀前，產品界面已經確定完畢。
----------------------------------------------------------------------------------------------
需求文檔寫作的一些建議
- 格式無所謂。用WORD的多，HTML，在線文檔都成，我還見過PPT寫的！
- 產品定義部分一定要詳細描述。按功能模塊寫，跨功能的定義用流程和關係來描述。多站在用戶的角度上，去定義用戶任務，用戶流程，頁面邏輯關係等。
- 使用準確的用語，注意邊界情況。比如，一個文本框最多輸入多少個字元？是阿拉伯數字還是皆可？超過字數會怎麼樣？
- 多畫圖。把原型包括進去，或者把產品界面包括進去，不然就畫出來。否則除了你，沒多少看得懂。
一個需求文檔，一些通用部分是必須要包括進去的，我總結了一個示例。
當然， 很多時候有可能是創業公司，或是小版本快速上線，要求會寬泛得多得多。
比如現比較推崇的Agile敏捷開發，會更強短平快，削弱文檔的溝通而加強團隊的直接交流，簡化流程，快速反饋，快速迭代等等。這種情況下，需求文檔會極大簡化，咱就不在這探討了。
- 文檔信息，版本記錄，責任人等
- 項目背景，產品目的
- 文檔約定（採用的標準，通用名詞等）
- 可行性分析
- 前期調研
- 產品預期
- 對其他產品的影響
- 產品定義功能詳述（文檔主體部分）
- 功能模塊
- 用例
- 用戶流程
- 數據需求
- 業務規則流程
- 產品非功能需求
- 對性能的需求
- 安全性需求等
- 產品風險或潛在問題
要明確一下你所說的「需求文檔」是概要設計階段還是詳細設計階段。
即文檔的閱讀者是設計人員還是開發人員。
如果是後者，文檔描述的需要詳細一點，為了保證項目順利的有質量的驗收，前期需要跟技術多次評審後，明確文檔中詳細的業務流程，以及整個產品的生命周期中的所有操作過程。小到一個登陸按鈕的登陸提示，大到產品涉及的所有展示界面。盡量避免出現「等等」、「自行參照」、「自行判斷定義」這種字樣。
樓主問的是產品需求文檔，不明白為什麼有些答主把業務場景，需求金字塔和用例描述等等都寫上去了。難道開發人員在實現需求的時候還會去關心需求屬於什麼類型/用戶在什麼場景下使用嗎，測試只需要對著產品寫的用例去測試嗎。
不排除有些朋友說寫這些都是為了前期評審的時候和團隊的成員講清楚，但是這部分的內容我認為都不是產品需求文檔的範疇。需求文檔只需要讓開發和設計人員在實現階段清楚功能/需求如何去實現就可以了，至於其他的都是屬於brd,mrd的內容。
明確了prd的範疇之後，我們再來談談該怎麼寫需求文檔。不管是word版的文檔，還是直接寫在交互圖中的說明亦或是直接在原型中添加註釋的方法，要讓開發明白需求無非是說清楚以下這些內容。各內容我就不具體展開講了，用一個例子代替。
1.需求描述
先用一兩句簡單的話說清楚這個需求是什麼，入口在哪裡，對原來的板塊有什麼影響。
例：在資訊板塊增加視頻直播的入口，用戶點擊後進入我的視頻板塊。
2.頁面跳轉示意圖
3.主要交互
4.邏輯說明（包括流程圖）
5.特殊說明/分支交互
以上例子不是說有多完善，但至少是一份表達清晰，內容完整的需求文檔。
我用的需求模版結構：
目錄
1 概述
1.1 名詞定義
1.2 產品背景、產品概述和目標
1.3 人物角色及角色間的關係
1.4 使用案例
1.5 產品預期開發時間表
2 功能需求
2.1 系統用例
2.2 功能概述
2.2.1 功能總表
2.2.2 用戶狀態對應表
2.3 功能特性詳細描述
2.3.1 XXX功能
2.3.1.1 功能描述
2.3.1.2 使用角色
2.3.1.3 前置條件
2.3.1.4 業務流程
2.3.1.5 流程說明
2.3.1.6 用戶界面草圖及要素說明
2.3.1.7 業務規則
2.3.1.8 介面說明
2.3.1.9 其他需求
2.3.5 其它功能
3 非功能需求
3.1 客服需求
3.2 其它相關模塊
3.3 業務數據分析需求
3.4 安全性需求和影響
4 產品風險
5 產品運營
5.1 運營分析
5.2 運營機制
6 附件清單
抓住重點，而不是規範。這些規範你都遵守了也未必能寫出好的MRD。
產品需求文檔，英文全稱Product Requirement Document（文中簡稱PRD），這是一份詳細描述產品功能需求的說明文檔。一個產品功能從方案到上線運營，涉及到的成員可能包括：設計師、開發人員、測試人員、及運營人員，各個角色分工合作，最終實現產品的上線。由於涉及的人員和環節眾多，各角色需要有據可依，那麼PRD文檔就是這重要的紐帶。因此，寫好一份合格的PRD文檔成為產品經理入門首先應該練就的本領之一。
網路上有各種介紹PRD寫作模版的文章，這裡並不提供單一的模版，而是介紹PRD的寫作思路和原則，了解基本原則後，至於模塊的劃分和形式，因團隊而異，各位看官可以自由發揮。
基本原則之一：介紹清楚需求的來龍去脈
組織一個團隊共同來做一件事，最先要做的就是需要各方達成一致，因此介紹清楚需求背景，不僅有利於整個項目組了解項目的意義，增進參與感，也有助於PM進一步梳理清自己的思路。需求的描述大體可以分為以下三部分：
1.需求是什麼？
關鍵詞：用戶、場景、和需求。用簡潔的文字描述清楚：在什麼場景下，什麼樣的用戶，遇到什麼問題，核心需求是什麼。例如，部分被加入微信群聊的用戶，在專註工作時，頻繁被過多的群聊信息提醒打擾，用戶希望這時能關掉這部分提醒。
2.為什麼需要解決這個問題？
通常在一個大的項目組，要做的需求很多，為什麼當下要做這個？這是所有人心中的疑問。要想回答好這個問題，就需要計算好解決這個問題帶來的價值是什麼。
3.如何解決？
通過前面的分析，發現需求的確存在，並且解決很有價值，那麼接下來要做的事情就是設計出完整的解決方案。通常，解決方案有多種呈現形式：文字、流程圖、原型圖等。根據方案的複雜程度，選擇其中的一種或多種形式來表達，務必確保簡潔易懂。
基本原則之二：明確考核指標
作為新人，常犯的問題就是認為產品上線完就萬事大吉了。BUT NO！產品上線只是一個需求的開端，而並不是結束。PM需要去關注產品上線後，問題是否被解決，用戶的需求是否被滿足，方案是否是最優的？等等。好的產品都是一步一步迭代至更好。所以，PRD文檔中必須要明確上線後需要關注的指標有哪些、這些基礎數據項如何獲得、及是否需要開發統計。只有確認衡量的標準後，才能為後續評估提供依據。
最近剛開完一次客戶端的發版總結會，通俗點來說，這個會就是各個角色來吐槽自己或其他人做的不好的地方。這其中，PM被吐槽最多的就是改需求，改需求不可怕最可怕的是需求改完各端信息同步還不一致。因此，在一份PRD文檔內，務必有一個地方記錄好每次修改點，方便所有人了解每一次的變更。簡潔的模版如下：
PRD撰寫過程，其實也是產品分析和設計的過程，PRD最終呈現的內容便是產品分析和設計的結果，所以要寫好一份產品需求文檔，除了掌握以上三大原則外，核心還是需要掌握好產品各項基本功。
下面是我結合自己的經驗關於對產品經理一些常用的文檔規範進行的一些整理，如果覺得有用歡迎關注交流！
（1） 商業需求文檔（BRD）
簡介
1、 向公司中申請需要的費用，資源得到各級領導支持
2、 通常講述市場機遇、盈利方式等，簡介、明了、易懂
3、 包括：商業價值、成本估算、收益預期
4、 工具：PowerPoint、Word、Mindmanager
內容結構
1、 方案形成的背景
l 市場環境分析
l 我們要做什麼
l 要解決什麼問題
a. 這問題是迫切的問題嗎？
b. 這個問題是強烈的問題嗎？
c. 這個問題出現的頻率高不高？
l 如果要這麼做，我們的優勢在哪裡？
技術優勢、經驗優勢、資源優勢……
l 得到可行的結論
2、 方案的價值
l 我們將會得到什麼樣的好處？
非經濟類的好處（戰略優勢等）、經濟類（收入等）
l 提出你的預測
目標、對應得到的好處
3、 產品規劃
l 產品結構
l 產品路線
4、 盈利模式
5、 收益與成本評估
6、 風險與對策
l 風險的種類：政策、經濟、市場、行業、公司、技術、資本
l 應對辦法：規避、接受、降低、分擔、轉移
（2） 市場需求文檔（MRD）
簡介
1、 在獲得了公司資源的支持後，根據你的想法在產品層面的表述
2、 收集、分析、定義主要的用戶需求和產品特性
3、 包括：產品介紹、競品分析、用戶需求調研結果、產品輪廓、功能需求
5、 工具：PowerPoint、Word、Mindmanager、Visio
內容結構：
1、 文檔說明
l 公司名稱、產品名稱、文檔創建日期、創建人信息
2、 市場分析
a. 摘要（可選）
b. 現有市場存在的問題和機會
l 產品方面（例如：產品形態複雜、用戶體驗差）
l 技術方面（例如：語音壓縮技術不成熟）
l 運營方面（產業鏈偏下游、重實體、輕線上、造成瓜分線下旅行社，形成對立）
l 用戶方面（用戶需要可替代產品尚未出現，需求明顯）
l 商業模式方面（金山毒霸和360安全衛士的商業模式對比）
c. 目標市場分析（基於該機會點下的市場分析說明）
l 市場規模
l 市場特徵（現有市場表現出的典型特徵）
l 發展趨勢（未來2-5年的發展評測）
l 時間邊界（這個市場的持續時間評估）
d. 市場分析結論
這裡要得到一個比較有市場商業價值的結論
3、 用戶分析
a. 目標用戶群體劃分（找准，年齡段、收入、學歷、地區）
b. 目標用戶特徵
所謂特徵，就是在這個群體下面的共性特點與非共性特點（分析）
c. 建立虛擬用戶角色（形象化、用戶畫像）
l 常用用戶特徵（年齡、性別、出生日期、收入、職業、居住地、興趣愛好、性格特徵）
l 用戶名稱
l 用戶技能（熟練使用電腦辦公，對常用的智能手機應用諳熟於心）
l 與產品相關特徵（電子商務產品：購物習慣、年度消費預算等；
交友類：是否單身、擇偶標準；遊戲類：是否喜愛3D遊戲、是否有同類型遊戲經驗）
d. 用戶使用場景（可以與c結合,簡單的用戶表述與使用場景）
描述用戶在某個環境中完成某個了某個任務的故事（時間、地點、人物、幹了什麼事）
e. 用戶動機總結（讀懂表象）
線下的在線商品比較和查詢表象
f. 用戶目標總結（明確實質）
g. 影響用戶使用的主要因素（重要，分析）
4、 產品說明
a. 產品定位
l 產品定位：我們用什麼樣的產品滿足用戶或用戶市場
l 用戶定位：針對什麼目標群體，做什麼事，用最本質的，無修飾的語言表述
b. 產品核心目標（產品本身要達到什麼一個目標）
l 通常來說，解決核心目標的工作優先順序是最高的
l 產品任務，很多應該圍繞核心目標來開展
l 產品經理對於用戶需求與產品核心目標關係的拿捏
c. 產品結構
l 產品的市場定位，產品定位，核心目標的直接表現
l 如果能配合流程圖與簡單的主要頁面線框圖就更清楚明了
d. 產品路線圖
l 產品成長中的每個任務節點組合而成，是以任務為導向的時間節點圖
e. 產品功能性要求
具體的功能點
f. 產品非功能性需求
l 有效性需求、性能需求、擴展性需求、安全性需求、健壯性需求
l 兼容性需求、可用性需求、運營需求、用戶體驗需求
（3） 產品需求文檔（PRD）
簡介：
1、 對MRD的內容進行指標化和技術化，明確產品的功能和性能；
2、 包括：產品驗收標準、產品流程圖、產品用例、產品功能點說明、性能需求等
3、 工具：Word、Visio、Axure、Mindmanaer
內容結構：
a. 文檔說明
b. 產品說明
c. 全局功能說明
常用的表述方式：
l 按照功能的邏輯來表述（更抽象，研發喜歡）
l 按照產品結構來表述（頻道、頁面、模塊、元素的邏輯表述，相比較適合產品經理得到邏輯）
d. 局部功能詳細描述
附上我的CSDN博客關於這篇文章的地址：產品經理文檔撰寫
在快速迭代的敏捷開發模式下，要想寫一個特別完整的需求文檔不是不可以，但是會耗費特別多的時間和精力，如果是一個產品團隊的話，那就可以分模塊來寫，然後歸檔。如果只是老哥一個，那就慘了。
不過從我個人的經驗來看，以及每次與UI、技術、測試等相關人員的私下溝通來看，他們根本不會在意你的文檔寫的如何，他們需要的是他們關注的內容。產品的用戶價值是什麼？產品的內部邏輯如何？產品的細節如何從產品層面實現等
無論用什麼模板，無論用什麼規範，只要說清楚就行，在很多時候會有一些細節無法照顧到的，我特別推崇公司wiki，無論項目內成員，還是以後接手的人，都會看的清清楚楚，也節省了很多時間和提高了效率。
以上針對不怎麼大的需求，及快速迭代來看，一般為一周兩周開發，純屬經驗只談。
------------------
如果是周期較長，項目較大，這個產品說明文檔就得細心準備了。樓上各位聊的已經很詳細了，我就不多說了。
針對需求的變更，一定要不怕麻煩，如果有條件，召集所有人碰頭，如果沒有時間，也一定要發郵件，晨會上詳細說明。
因為誰也說不準什麼時候需求會應為某種特殊原因需要變更。如 領導的一句話，某個合作方變更需求，某個資源緊急撤離等等。
大的規範不同團隊都有自己的差別，核心目標是溝通清楚需求，不要有遺漏或考慮不周的，僅僅因為產品經理工作疏忽的問題到後面臨時要改要加程序員就會覺得很冤枉了。所以想要不被程序猿或者用戶打成篩子，要注意以下這些細節問題。。。
用戶角色用例
遊客，新手，管理員，編輯，審核等人員。避免遺漏少數用戶。業務流程圖，數據流程圖
數據從哪裡來，到哪裡角色哪些程序去都要考慮清楚。
比如寫了前台，就最好要寫一下哪些數據會在後台做呈現。
比如如果有了作業生成的數據，那麼這些數據要不要統計，要不要收入個人知識管理。
業務流程圖有兩種情況，一種是全新流程，另一種是現有流程的優化，後者需要先列出現有流程作為對比。詳細考察各種業務情況
如後台支持多少種資源形式的錄入，前台就要做多少種展現形式的處理，或者說明確指出哪些資源形式的錄入是不支持的。每個欄位的數據來源
不能使用後台沒有的數據，避免一個界面出現非常多的要臨時計算、跨庫查詢的數據。支持的操作系統，瀏覽器版本
要不要兼容讓人頭疼的IE8，要不要迎合高大上的apple watch。各種異常情況（重點）[1]
（1）內容呈現類- 零結果、少結果及多結果
如一段文字超出顯示框時的情況，最多顯示多少，沒有數據的情況，沒有圖片的情況，默認圖片是什麼。
用戶第一次登錄，沒有任何操作時是什麼情況。 - 內容顯示與隱藏
如不同等級會員的用戶界面的差異 - 數據過期
如活動過期，或者資源下架 - 不同狀態的呈現
如不同的會員等級，書籍促銷，從不同來源獲取的信息是否需要區分
（2）交互效果類
- Tab控制項的交互效果，懸停還是點擊，如果是懸停，是否需要0.3-0.5秒左右的延遲時間避免滑鼠無意識滑過時的誤操作
- 新標籤打開還是原本的標籤打開
（3）操作過程類
- 控制項的禁用、激活以及修改
如在提交表單過程中，提交按鈕不可用 - 增加、編輯、刪除、查找
- 用戶不可操作、操作錯誤、操作成功時的情況和提示，提示的顯示和隱藏方式
- 多部終端切換操作的情況
（4）系統環境類
- 網路慢，網路超時，無網路的情況
數據是否可用，是否需要給用戶提示，是否需要過場動畫，如果需要，過場動畫是佔據整個屏幕還是僅在頂部顯示，是否需要可以終止等待 - 不支持的設備訪問時的情況
- 是否可以離線緩存，緩存是否可以清除
- 零結果、少結果及多結果
[1]: 參考資料：阿里巴巴PPT《交互設計物輸出標準》，網易UEDC《如何建立交互設計自查表 》?
這個清單需要在日常工作中不斷反思和完善，所以我有寫在簡書中，把自己遇到的問題不斷更新上去：產品是一個細節活，各種細節自查清單
另外，更重要的是溝通。從產品需求確定之後，就要跟測試、開發詳細過一遍。如果有涉及到要調用其他團隊產生的數據的地方，也要諮詢下對方這些數據目前支不支持調用呈現。
稍微的整理了一下，無論我們做什麼事都講究方式方法，寫產品需求文檔(以下稱PRD文檔)也是如此。暫且就叫產品需求文檔五部曲吧。
1、寫前準備(信息結構圖)
2、梳理需求(產品結構圖和用戶流程圖)
3、原型設計(手繪原型,灰模原型,交互原型)
4、撰寫文檔(PRD文檔)
5、用例文檔(UML用例圖、流程圖)
1、寫前準備(信息結構圖)：
產品需求文檔的寫作(一)
在寫PRD文檔之前，我們需要先羅列出產品功能的信息內容，這一步是將想法逐漸清晰的第一步，也是幫助我們接下來規劃功能的輔助信息，同時也可以輔助服務端技術人員創建資料庫。因為這是第一步，所以我們不需要羅列的很詳細，在之後的步驟里，我們會逐步改進和完善信息內容。
例如一篇文章的信息內容主要有：文章標題、文章正文、文章作者、發布時間、所屬分類。初始的功能需求只有這些信息內容，但是在之後的功能規劃中逐漸更加細緻的考慮時，可能會增加或者刪減，因此第一步我們不用刻意的追求信息的全面。
羅列信息內容的方式有很多種，文本形式、思維導圖形式等等都可以，最主要的是能夠清晰易懂，我最常用的方法就是思維導圖，因此我稱這一步為信息結構圖。
2、梳理需求(產品結構圖和用戶流程圖)：產品需求文檔的寫作(二)
當我們對產品的信息結構了解後，我們就需要規整腦海中的產品需求，讓想法更加結構化，因此這一步是梳理產品的需求。我們首先要羅列出產品的頻道及頁面(產品結構圖)，其次再基於產品結構圖梳理出頻道及頁面中的功能，並延伸構建出用戶的操作流程(用戶流程圖)。
以上兩步是為了讓我們在撰寫產品需求文檔之前能夠對產品有一個全面的了解，類似鳥瞰式的一目了然，也方便調整完善。
3、原型設計(手繪原型,灰模原型,交互原型)：產品需求文檔的寫作(三)
當我們逐漸清晰了產品的需求後，並梳理了產品的各個頻道及頁面，那麼這一步就要開始驗證這些想法的具體界面表現和方案的可行性了。
首先我建議通過手繪的形式快速在草紙上繪製出產品的原型，推演和討論方案的可行性，當有一定的進展之後，我們再通過軟體工具進行更深入的設計。移動產品可以考慮灰模原型，網站產品可以考慮交互原型，對於這兩種原型方式，無論是移動產品還是網站產品都可以使用，具體取得於你的個人習慣和團隊要求。
對於產品經理來說，原型設計是為了幫助我們細緻的考慮方案，並論證方案的可行性，同時也是為了避免產品宣講時，抽象的語言描述導致聽眾理解困難和理解偏差。
4、撰寫文檔(PRD文檔)：產品需求文檔的寫作(四)
當我們通過以上三個大的步驟之後，我們就已經非常清晰產品的需求了，一般情況下，通過原型加描述的方式就已經完成了PRD文檔的目的(很多產品經理直接使用Axure製作PRD)。
當然也會有一些個人或團隊的要求不一樣，對PRD文檔有特定的規範標準，這類情況可能是需要存檔歸類。無論什麼樣的規範標準，PRD文檔的目的都是相近的，因此功能描述的方式也是相似的，所以在這裡我分享了三種撰寫PRD文檔的方式。
5、用例文檔(UML用例圖、流程圖)：產品需求文檔的寫作(五)
《產品需求文檔(PRD)的寫作方法》的補充文章，主要講解PRD文檔中的重要輔助文檔「用例文檔」。
寫文檔前要與各方充分溝通，而不是自己拍腦袋寫完再被其他角色拍
產品需求文檔首先要得到上游同事的認可並確保下游同事理解和技術可行。
對上游是定位、流程的概述，對下游是功能、體驗層面的需求詳述。
每個公司的需求文檔都各具特色，但能保證工作鏈正常有序的運轉就OK了。
抓大不放小，能圖不字，了解誰要看你的文檔和他的目的，並依此調整文檔邏輯、結構和內容
產品經理是個萬金油的角色.....
功能，場景，交互能說清楚，看得人能懂就行！
個人認為文檔的形式其實並不重要，重要的是看文檔的各方都能否自如的各取所需，所以要兼顧到運營、開發、測試相關同學的需要，將產品的需求、交互、基本用例和運營的要求都要描述清楚
最近新的公司剛好遇到了產品需求文檔方面的一些問題，因此我也跳出來說說產品需求或PRD文檔啥的。
現在很多產品團隊對於PRD文檔的規範有較大分歧，其實文檔本身，只是一個團隊溝通的一個中間工作產品，目的是將產品的實現思路傳達到每個人（重要的如設計、前後端開發、測試，以及運營、商務等部門，甚至是老闆），它一方面和團隊內部溝通機制有莫大的關係，另一方面和產品類別相關，總所周知產品一般分為互聯網產品和政企信息系統產品，從應用領域分又分為移動應用產品和web端產品，政企信息系統產品更模塊化功能化，產品規模都較大，因產品所處行業的關係前期需求比較容易控制，手機端和web端產品功能相似度較高，因此兩者在前期做產品需求基本一樣，為了便於團隊之間溝通，通常藉助於規範化的prd文檔描述各個功能模塊之間的關係、業務流程、信息欄位及非功能性需求，這樣的PRD文檔規格在網上搜索大把，無太大爭議。
而互聯網產品的設計原則是大道至簡，並初期擔負著試探市場及用戶的重任，產品快速的迭代發布讓PRD的規範有更大的靈活度，當我們開展一款新的產品（PRD的工作主要集中在新產品的開發階段），應該以簡為主，當前互聯網如此激烈的市場環境下，很多產品甚至只是主打一個核心功能，因此PRD文檔也有相對應的簡化，比如我們做手機app，我們一般會將UI控制在十個以內，甚至五個，界面布局、交互流程及信息欄位基本可以通過原型圖表達清楚，所以這時候原型圖即是PRD，如果原型圖也無法表達清除應該好好思考團隊之間的協作問題溝通機制了。而對於互聯網的web產品，PRD任然有其必要，考慮到web頁面較大信息量和複雜的交互，我們仍然需要藉助原型以外的流程圖和Excel、Word將更多更複雜的信息表達清楚（一般來說原型圖、流程圖和信息欄位三件東西足矣），這裡可以根據團隊默契程度自行考慮，比如曾經我公司一個產品團隊嘗試過前期只是用過web原型圖即實現了產品的快速敏捷開發和迭代。
前面提到比較多根據團隊自身情況調整PRD的規範問題，其實所謂自身情況即是團隊架構和溝通機制，部分公司是弱矩陣型（根據角色職能劃分部門，根據產品項目配置人員，人員調動可能性較大，如騰訊），可能會受制於不同部門的文化，影響溝通，PRD需要盡量詳細以避免理解衝突；部分公司產品團隊型，比如我公司以前的產品團隊結構，人員默契度較高，溝通頻繁，這時候可以簡化RD不必要的環節。
說到最後，還不得不提一下，有些童鞋仍然搞不清楚MRD（也有人稱之為brd）和PRD的關係，建議做產品前好好研究一下，兩者在產品需求環節都需要且必不可少，前者解釋為什麼做產品（行業市場、競爭環境）、怎麼做產品（功能框架）、怎麼賣（推廣運營）、怎麼賺錢（商務模式）及怎麼規劃，詳細的文檔結構也可以網上找到，這份文檔是產品的根本（個人認為重要程度比PRD高），而PRD重點在於解釋怎麼做產品（功能及分功能的需求），表現形式有很多種，比如原型、流程 也可以是任何其他的形式。
1、文檔是給人看的，看不懂就沒意義了
2、看懂的前提下，如果能簡單易懂，就更好了
3、看不懂也不要緊，保持溝通就好了
4、多寫寫，看資質，半年到一年，能寫出小成
大公司的我不知道 我的親身感受吧!:
1.文檔要清晰連貫名詞解釋什麼的都要有,就是這個文檔你拿給開發人員,在你不講解的前提下對方能理解70%(至少的),然後通過你的講解開發人員能理解95%(100%幾乎是不可能的).2.盡量做到通俗易懂!3.若有需要 需要讓步懂開發的人員也能看到你的主要目的(主要文檔目的)以一個看需求人的角度來說，任何格式，形式，真的都不重要。只需要你對人家描述得理念能被理解，並且對細節思考足夠深入，對一些邏輯的東西畫個圖，讓實施的人做起來有據可查。
簡單就好，用不著堆砌太多炫的東西，文檔和演示用PPT是不一樣的。推薦閱讀：