需求文檔/產(chǎn)品文檔是每個產(chǎn)品經(jīng)理的必經(jīng)之路，優(yōu)秀的產(chǎn)品文檔可以避免部分項目的重復溝通和編寫無效代碼，提高項目開發(fā)效率。

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

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

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

一、目的

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

1.1 受眾群體

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

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

（2）企業(yè)內(nèi)部：如老板、商務團隊、運營團隊等；通常這部分群體不會在乎產(chǎn)品規(guī)則，他們只關(guān)心項目實現(xiàn)的功能和效果。

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

1.2 時間限制

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

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

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

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

二、題外話：使用手冊

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

需求文檔描述的是項目的功能和產(chǎn)品邏輯、規(guī)則，偏向邏輯描述；而用戶手冊是描述項目的功能和使用流程，偏向操作流程說明。兩者間都需要告訴各自的讀者，功能是什么、有什么用；但出于目的不同，所以主題內(nèi)容和詳細程度也會不一樣。看看家里的電器使用說明書，就知道怎么寫使用手冊了。

三、PRD的構(gòu)成

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

3.1 開發(fā)用文檔

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

我個人也是寫開發(fā)用文檔比較多，慢慢形成了自己的框架規(guī)范。以后隨著經(jīng)驗的積累，也會繼續(xù)優(yōu)化這套方法論。

版本迭代記錄

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

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

版本修改記錄

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

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

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

流程圖

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

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

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

全局說明

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

【舉個例子】

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

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

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

正文

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

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

【舉個例子】

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

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

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

兩個版本的信息內(nèi)容是一樣的，但由于信息側(cè)重點相反，因此這兩個提示的功能也不一致。第一版?zhèn)戎赜诟嬖V用戶“當前客服不在線”；第二版?zhèn)戎赜谝龑в脩粼诰€留言。產(chǎn)品是要為用戶提供解決方案，而不是把問題拋回給用戶。

3.2 商用文檔

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

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

封面

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

目錄

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

概述

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

使用人群

給誰看就列明誰，如系統(tǒng)開發(fā)團隊，相關(guān)行業(yè)設(shè)計師等。

需求分析

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

系統(tǒng)字典

對系統(tǒng)或者文檔內(nèi)的一些專業(yè)用詞進行解釋，或?qū)ν皇挛镞M行命名規(guī)范。系統(tǒng)字典不僅是一個項目內(nèi)使用，甚至每個部門或每間公司都可以用相關(guān)概念，特別當團隊剛剛組建時，使用系統(tǒng)字典概念能夠解決很多溝通上的誤會。

【舉個例子】

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

結(jié)語

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

另附樣例作為參考：

開發(fā)用文檔：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

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

本文由 @貓爪 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議