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

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

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

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

一、目的

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

1.1 受眾群體

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

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

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

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

1.2 時(shí)間限制

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

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

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

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

二、題外話：使用手冊

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

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

三、PRD的構(gòu)成

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

3.1 開發(fā)用文檔

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

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

版本迭代記錄

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

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

版本修改記錄

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

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

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

流程圖

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

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

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

全局說明

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

【舉個(gè)例子】

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

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

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

正文

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

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

【舉個(gè)例子】

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

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

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

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

3.2 商用文檔

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

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

封面

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

目錄

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

概述

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

使用人群

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

需求分析

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

系統(tǒng)字典

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

【舉個(gè)例子】

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

結(jié)語

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

另附樣例作為參考：

開發(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

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

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

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

愛盈利-運(yùn)營小咖秀(www.jza6.com) 始終堅(jiān)持研究分享移動互聯(lián)網(wǎng)App運(yùn)營推廣經(jīng)驗(yàn)、策略、全案、渠道等純干貨知識內(nèi)容；是廣大App運(yùn)營從業(yè)者的知識啟蒙、成長指導(dǎo)、進(jìn)階學(xué)習(xí)的集聚平臺；

想了解更多移動互聯(lián)網(wǎng)干貨知識，請關(guān)注微信公眾號運(yùn)營小咖秀（ID: yunyingshow）