需求文檔/產品文檔是每個產品經理的必經之路，優秀的產品文檔可以避免部分項目的重復溝通和編寫無效代碼，提高項目開發效率。

“這里是不是少了功能按鈕？”“這段話是什么意思？”“不行呀！你的文檔需要補充，不然怎么測試？”“口頭的需求文檔不算數，開發要見文字版文檔”。

關于產品文檔，我們總會遇到這樣的對話。那么如何避免呢，下文將仔細說到。

本文獻給0-1歲的產品經理，從需求文檔的目的、與用戶手冊的區別、需求文檔的構成的維度對需求文檔進行整體介紹，希望各位PM都可以輸出高效精簡、清晰明了的文檔。

一、目的

寫需求文檔前，首先要確定的是文檔的受眾群體和時間要求。受眾群體（誰去看）確定了文檔的框架架構和排版要求；時間要求限制了需求文檔的精細度和美觀度。

1.1 受眾群體

一般來說，需求文檔有三個受眾群體：

（1）開發團隊：包括產品團隊、UI、UX、技術和測試；這也是最常規的受眾群體，畢竟需求文檔是要闡述項目要實現的功能和實現的方法、規則。

（2）企業內部：如老板、商務團隊、運營團隊等；通常這部分群體不會在乎產品規則，他們只關心項目實現的功能和效果。

（3）其他：例如公司制度要求留檔、公司上市審計流程所需。我還見識過另一種過程：面試。如果在面試時提交的作品是需求文檔，那么請看“商用文檔”部分。

1.2 時間限制

如果只是開發團隊使用的需求文檔（以下簡稱開發用文檔），框架會比較簡單，排版也沒有非常嚴謹的要求，只需要做到邏輯閉環，場景盡善，表達清晰即可。如果是企業內部或其他用途的需求文檔（以下簡稱為商用文檔），除了開發用文檔的內容外，還需補充項目概述、需求分析等欄目，這部分將在下文“商用文檔”再詳細解釋。

在寫文檔前，PM心中必須要有期限和計劃，合理安排文檔的進度，不能在項目前期就發生延期的情況。

如果時間緊迫，首先要把關鍵的邏輯寫清楚，其他的細節可以在開發時或項目結束后補充，例如搜索功能、填寫字段的字符長度、頁面確定、關閉和返回等交互。特別是當項目團隊已有一定的合作經驗，建立了一定的工作默契時，這些細節在時間不允許情況下是可以省略，畢竟PM也有很多更值得做的事情。

但是，如果時間充?；蛘呤切碌拈_發團隊，個人還是建議需求文檔盡量精細，畢竟見過很多設計師、開發和測試吐槽需求文檔不清不楚，工作難以開展。再者，詳細的需求文檔，可以大大地減少開發團隊的理解誤區，一定程度上，既能避免無效設計和無效代碼，還能避免產品經理在投入下一個迭代工作時被開發“咨詢”過多。

二、題外話：使用手冊

有些-1到0.5歲的產品不是很清楚需求文檔和用戶手冊的區別。我曾經讓0歲的助理寫2B項目的用戶手冊，由于時間緊迫，加上他對項目還不算熟悉，我就把需求文檔的原文件發給了他，希望起幫助作用，結果最后交過來的作業卻是一個簡化版的需求文檔。

需求文檔描述的是項目的功能和產品邏輯、規則，偏向邏輯描述；而用戶手冊是描述項目的功能和使用流程，偏向操作流程說明。兩者間都需要告訴各自的讀者，功能是什么、有什么用；但出于目的不同，所以主題內容和詳細程度也會不一樣?？纯醇依锏碾娖魇褂谜f明書，就知道怎么寫使用手冊了。

三、PRD的構成

前文提及，因受眾群體不一樣，PRD可分為開發用文檔和商用文檔，除了在排版、美觀等有區別外，在內容上也有一定的區別。文終將會放上這兩個類型的文檔作為樣例給各位讀者參考。

3.1 開發用文檔

開發用的文檔只有一個宗旨：把需求說清楚說明白，大家知道要做什么功能，做到什么程度。

我個人也是寫開發用文檔比較多，慢慢形成了自己的框架規范。以后隨著經驗的積累，也會繼續優化這套方法論。

版本迭代記錄

主要是記錄一個項目各個產品版本的迭代情況，如V1.0，V1.1……V2.0……。這里強調的產品版本，主要是指產品功能的迭代。如果一個迭代只單純涉及到bug修復、交互優化、性能優化，記不記錄都可以，看個人意愿。

需要記錄的內容包括：版本號、更新日期（文檔定稿日期或者版本上線日期，個人更建議用版本上線日期）、主責產品經理、迭代的功能簡介（從業務場景出發，一句話描述一個功能模塊）。

版本修改記錄

主要是記錄單個版本（劃重點）的修改記錄。因為每個需求文檔都會經歷初稿、產品評審、技術評審、開發過程中N次細節調整、終稿這幾個過程，需要把每次修改的地方記錄下來，特別是當文檔已經對項目團隊公開后發生的修改。

需要記錄的內容包括：更新日期（每次文檔修改的日期）、產品經理（不等同該版本的主產品經理，特別是大項目有一個主產品經理，多個初中級產品經理）、修改說明（動了哪些邏輯，哪些頁面）。

版本迭代記錄是為了給以后的項目團隊使用，無論是產品還是開發，方便新成員或項目交接時快速了解項目的前世今生；版本修改記錄是給當前的開發團隊使用，方便快速了解產品又改了哪些邏輯，增加了哪些需求（溫馨提示：投入開發后真不要輕易加需求）。

流程圖

一般寫在文檔里的流程圖包括兩種：業務流程圖和邏輯流程圖，都是“非必填項”，視實際情況判斷是否需要用流程圖進行說明。因為在開發用文檔內，任何元素都是為了幫助產品經理清晰說明需求，如果業務很簡單，能用線框圖或者文字即可說明清楚，那么就沒必要費力氣去弄一個流程圖了。

業務流程圖：一般單個任務模塊從0-1的時候需要使用，幫助開發理解任務的每一個環節。通常會涉及到多個角色協作。例子見文末開發用需求文檔。

邏輯流程圖：單個任務或者單個環節涉及多重邏輯判斷時使用，幫助開發梳理if else后的操作行為。如果單純用文字描述這種邏輯判斷，開發還沒繞暈，產品自己可能就先繞暈了。

全局說明

在同一個系統內，在多個場景或者頁面內需要使用到相同的組件或者交互，把這類組件/交互的需求說明歸納到全局說明內，在正文內出現時做相關引用即可。

【舉個例子】

列表的排序規則，如果多個頁面的列表排序規則都是一樣，則在全局說明內新增一個版塊對其進行詳細說明，而在正文的相關頁面注明“排序規則請參照全局說明XXXX”即可。

又如系統管理后臺，編輯頁面的保存/取消功能，直接在全局說明內說明，點擊保存/取消時會出現XXX提示，確認后系統的執行結果；即使在實際頁面中，保存/取消屬于不同的內容編輯頁面，但其交互幾乎都是一致的，就沒有必要在多個頁面重復說明。如果遇到特例，與全局說明內的需求不一樣，在對應的頁面再另行說明。

建立全局說明板塊，不僅能在寫需求文檔是節省重復勞動的時間，而且在修改需求文檔過程中也能省掉很多繁瑣的事，就如Axure中“母版”一樣便捷，改一處即把相關的地方都完成修改。

正文

就是每個頁面的需求細節，包括線框圖/高保真，邏輯說明和交互說明。

關于交互說明，一般大公司才會有專職的交互設計師并撰寫交互文檔，其他公司通常由產品經理和UI設計師一起承擔交互設計。但無論是否有專職的交互設計師，我認為作為一名產品經理，在需求文檔內也要明確指出部分交互說明，提供一個大方向給設計師工作，特別是對于系統的空白頁或類空白頁。

【舉個例子】

前段時間在處理一個小功能：在非電話客服工作時間內，用戶點擊電話客服按鈕時，需彈出提示并引導用戶在線留言。

以下是第一版和第二版設計的效果：最終使用的是第二版。

由于當時需求內沒有詳細說明交互意圖，UI設計師被線框圖誤導，出了第一版本；我看了設計后不太滿意，與UI設計師溝通想法后，最終修改為第二版并投入開發。

兩個版本的信息內容是一樣的，但由于信息側重點相反，因此這兩個提示的功能也不一致。第一版側重于告訴用戶“當前客服不在線”；第二版側重于引導用戶在線留言。產品是要為用戶提供解決方案，而不是把問題拋回給用戶。

3.2 商用文檔

相對于開發用文檔，商用文檔幾乎是面面俱到，盡善盡美，能擺到桌面上的需求文檔，以下列出了二者的框架對比。

寫商用文檔無形中也會給產品經理增加非常大的工作量，因此可按公司要求和個人習慣結合去選擇即可。

封面

每一份商業化文檔，都會要求有一個封面，簡單羅列系統名稱、文檔名稱、文檔設計者（企業或者個人）、定稿時間即可。

目錄

目錄的粒度，需要細致到哪級標題，按需設置即可。

概述

包括項目背景、項目介紹，用一兩段話簡要說明。

使用人群

給誰看就列明誰，如系統開發團隊，相關行業設計師等。

需求分析

主要寫項目前期開展的調研和分析而得出的結論，包括產品定位——項目核心用戶群、市場競爭優勢，和用戶故事——用5W1H方法表明解決的痛點。

系統字典

對系統或者文檔內的一些專業用詞進行解釋，或對同一事物進行命名規范。系統字典不僅是一個項目內使用，甚至每個部門或每間公司都可以用相關概念，特別當團隊剛剛組建時，使用系統字典概念能夠解決很多溝通上的誤會。

【舉個例子】

就如上文的“全局說明”，這里用“全局”代指整個系統的概念。但實際，更多的公司/團隊用“全域”來指代整個系統。但由于公司是旅游行業，“全域”一詞是行業內的專有術語，并且也是公司的業務術語，如果用“全域”來表示整個系統，在溝通時常常會引起誤解，因此公司內部都習慣使用“全局”來指代整個項目系統。

結語

以上便是從大框架層面介紹優秀的產品文檔需要涵蓋的內容，后續將在系列（二）中，從需求文檔——正文的角度介紹本人寫產品文檔的小技巧和tips。整個系列均屬作者本人的見解，歡迎交流。

另附樣例作為參考：

開發用文檔：https://h82yzy.axshare.com/#g=1&p=%E7%89%88%E6%9C%AC%E8%AE%B0%E5%BD%95

商用文檔：（提取碼：rqff）

https://pan.baidu.com/s/12q-jRKPzqp_Qgt_2R0MJ2A

（備注：商用文檔為“當年”自學轉行產品時的作業，相對稚嫩，大家看看框架即可，不必較真哈）

本文由 @貓爪 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議