獻給-1歲的產品經理，從需求文檔的目的、與用戶手冊的區別
更新時間：2023-10-29 11:23:07作者：佚名
需求文檔/產品文檔是每位產品總監的必經之路，優秀的產品文檔可以防止部份項目的重復溝通和編撰無效代碼，提升項目開發效率。
“這里是不是少了功能按鍵？”“這段話是哪些意思？”“不行呀！你的文檔須要補充，不然如何測試？”“口頭的需求文檔不算數，開發要見文字版文檔”。
關于產品文檔，我們總會碰到這樣的對話。這么怎樣防止呢，下文將仔細說到。
本文送給0-1歲的產品總監，從需求文檔的目的、與用戶指南的區別、需求文檔的構成的維度對需求文檔進行整體介紹，希望諸位PM都可以輸出高效精簡、清晰明了的文檔。
一、目的
寫需求文檔前，首先要確定的是文檔的受眾群體和時間要求。受眾群體（誰去看）確定了文檔的框架構架和排版要求；時間要求限制了需求文檔的精細度和美觀度。
1.1受眾群體
通常來說，需求文檔有三個受眾群體：
（1）開發團隊：包括產品團隊、UI、UX、技術和測試；這也是最常規的受眾群體，雖然需求文檔是要探討項目要實現的功能和實現的方式、規則。
（2）企業內部：如老總、商務團隊、運營團隊等；一般這部份群體不會在意產品規則，她們只關心項目實現的功能和療效。
（3）其他：比如公司制度要求留檔、公司上市審計流程所需。我還見識過另一種過程：筆試。假如在筆試時遞交的作品是需求文檔，這么請看“商用文檔”部分。
1.2時間限制
假如只是開發團隊使用的需求文檔（以下簡稱開發用文檔），框架會比較簡單，排版也沒有特別嚴謹的要求，只須要做到邏輯閉環優秀產品設計，場景盡善，抒發清晰即可。假如是企業內部或其他用途的需求文檔（以下簡稱為商用文檔），不僅開發用文檔的內容外，還需補充項目概述、需求剖析等欄目，這部份將在下文“商用文檔”再詳盡解釋。
在寫文檔前，PM心里必需要有時限和計劃，合理安排文檔的進度，不能在項目前期就發生延后的情況。
假如時間急迫，首先要把關鍵的邏輯寫清楚，其他的細節可以在開發時或項目結束后補充，比如搜索功能、填寫數組的字符寬度、頁面確定、關閉和返回等交互。非常是當項目團隊已有一定的合作經驗，構建了一定的工作默契時，這種細節在時間不容許情況下是可以省略，雖然PM也有好多更值得做的事情。
然而，假若時間充沛或則是新的開發團隊，個人還是建議需求文檔盡量精細，雖然見過好多設計師、開發和測試吐槽需求文檔不清不楚，工作未能舉辦。此外，詳盡的需求文檔，可以大大地降低開發團隊的理解誤區，一定程度上，既能防止無效設計和無效代碼，能夠防止產品總監在投入下一個迭代工作時被開發“咨詢”過多。
二、題外話：使用指南
有些-1到0.5歲的產品不是很清楚需求文檔和用戶指南的區別。我當初讓0歲的助理寫2B項目的用戶指南，因為時間急迫，加上他對項目還不算熟悉，我就把需求文檔的原文件發給了他，希望起幫助作用，結果最后交過來的作業卻是一個簡化版的需求文檔。
需求文檔描述的是項目的功能和產品邏輯、規則，偏向邏輯描述；而用戶指南是描述項目的功能和使用流程，偏向操作流程說明。二者間都須要告訴各自的讀者，功能是哪些、有哪些用；但出于目的不同，所以主題內容和詳盡程度也會不一樣。瞧瞧家里的家電使用說明書，就曉得如何寫使用指南了。
三、PRD的構成
前文提到，因受眾群體不一樣，PRD可分為開發用文檔和商用文檔，不僅在排版、美觀等有區別外，在內容上也有一定的區別。文終將會放上這兩個類型的文檔作為樣例給諸位讀者參考。
3.1開發用文檔
開發用的文檔只有一個宗旨：把需求說清楚說明白優秀產品設計，你們曉得要做哪些功能，做到哪些程度。
我個人也是寫開發用文檔比較多，漸漸產生了自己的框架規范。之后隨著經驗的積累，也會繼續優化這套方式論。
版本迭代記錄
主要是記錄一個項目各個產品版本的迭代情況，如V1.0，V1.1……V2.0……。這兒指出的產品版本，主要是指產品功能的迭代。假如一個迭代只單純涉及到bug修補、交互優化、性能優化，記不記錄都可以，看個人意愿。
須要記錄的內容包括：版本號、更新日期（文檔初稿日期或則版本上線日期，個人更建議用版本上線日期）、主責產品總監、迭代的功能簡介（從業務場景出發，一句話描述一個功能模塊）。
版本更改記錄
主要是記錄單個版本（劃重點）的更改記錄。由于每位需求文檔就會經歷定稿、產品評審、技術評審、開發過程中N次細節調整、終稿這幾個過程，須要把每次更改的地方記錄出來，非常是當文檔早已對項目團隊公開后發生的更改。
須要記錄的內容包括：更新日期（每次文檔更改的日期）、產品總監（不等同該版本的主產品總監，非常是大項目有一個主產品總監，多個中學級產品總監）、修改說明（動了什么邏輯，什么頁面）。
版本迭代記錄是為了給予后的項目團隊使用，無論是產品還是開發，便捷新成員或項目交接時快速了解項目的前世此生；版本更改記錄是給當前的開發團隊使用，便捷快速了解產品又改了什么邏輯，降低了什么需求（溫情提示：投入開發后真不要輕易加需求）。
流程圖
通常寫在文檔里的流程圖包括兩種：業務流程圖和邏輯流程圖，都是“非必填項”，視實際情況判定是否須要用流程圖進行說明。由于在開發用文檔內，任何元素都是為了幫助產品總監清晰說明需求，假如業務很簡單，能用線框圖或則文字即可說明清楚，這么就沒必要吃力氣去弄一個流程圖了。
業務流程圖：通常單個任務模塊從0-1的時侯須要使用，幫助開發理解任務的每一個環節。一般會涉及到多個角色協作。反例見文末開發用需求文檔。
邏輯流程圖：單個任務或則單個環節涉及多重邏輯判定時使用，幫助開發梳理ifelse后的操作行為。假如單純用文字描述這些邏輯判定，開發還沒繞暈，產品自己可能就先繞暈了。
全局說明
在同一個系統內，在多個場景或則頁面內需要使用到相同的組件或則交互，把這類組件/交互的需求說明歸納到全局說明內，在正文內出現時做相關引用即可。
【舉個反例】
列表的排序規則，假如多個頁面的列表排序規則都是一樣，則在全局說明內新增一個版塊對其進行詳盡說明，而在正文的相關頁面標明“排序規則請參照全局說明XXXX”即可。
又如系統管理后臺，編輯頁面的保存/取消功能，直接在全局說明內說明，點擊保存/取消時會出現XXX提示，確認后系統的執行結果；雖然在實際頁面中，保存/取消屬于不同的內容編輯頁面，但其交互幾乎都是一致的，就沒有必要在多個頁面重復說明。假如遇見特例，與全局說明內的需求不一樣，在對應的頁面再另行說明。
構建全局說明藍籌股，除了能在寫需求文檔是節約重復勞動的時間，并且在更改需求文檔過程中也能省掉好多冗長的事，就如Axure中“母版”一樣方便，改一處即把相關的地方都完成更改。
正文
就是每位頁面的需求細節，包括線框圖/高保真，邏輯說明和交互說明。
關于交互說明，通常大公司就會有專職的交互設計師并撰寫交互文檔，其他公司一般由產品總監和UI設計師一起承當交互設計。但無論是否有專職的交互設計師，我覺得作為一名產品總監，在需求文檔內也要明晰強調部份交互說明，提供一個大方向給設計師工作，非常是對于系統的空白頁或類空白頁。
【舉個反例】
前段時間在處理一個小功能：在非電話客服工作時間內，用戶點擊電話客服按鍵時，需彈出提示并引導用戶在線留言。
以下是第一版和第二版設計的療效：最終使用的是第二版。
因為當時需求內沒有詳盡說明交互意圖，UI設計師被線框圖欺騙，出了第一版本；我看了設計后不太滿意，與UI設計師溝通看法后，最終更改為第二版并投入開發。
兩個版本的信息內容是一樣的，但因為信息優缺相反，因而這兩個提示的功能也不一致。第一版注重于告訴用戶“當前客服不在線”；第二版注重于引導用戶在線留言。產品是要為用戶提供解決方案，而不是把問題拋回給用戶。
3.2商用文檔
相對于開發用文檔，商用文檔幾乎是面面俱到，盡善盡美，能擺到桌面上的需求文檔，以下列舉了兩者的框架對比。
寫商用文檔無形中也會給產品總監降低特別大的工作量，因而可按公司要求和個人習慣結合去選擇即可。
封面
每一份商業化文檔，就會要求有一個封面，簡單列舉系統名稱、文檔名稱、文檔設計者（企業或則個人）、定稿時間即可。
目錄
目錄的細度，須要細致到哪級標題，按需設置即可。
概述
包括項目背景、項目介紹，用一兩段話簡略說明。
使用人群
給誰看就列明誰，如系統開發團隊，相關行業設計師等。
需求剖析
主要寫項目前期舉辦的督查和剖析而得出的推論，包括產品定位——項目核心用戶群、市場競爭優勢，和用戶故事——用5W1H方式表明解決的痛點。
系統字典
對系統或則文檔內的一些專業用詞進行解釋，或對同一事物進行命名規范。系統字典除了是一個項目內使用，甚至每位部門或每間公司都可以用相關概念，非常當團隊剛才成立時，使用系統字典概念才能解決好多溝通上的誤解。
【舉個事例】
就如上文的“全局說明”，這兒用“全局”代指整個系統的概念。但實際，更多的公司/團隊用“全域”來指代整個系統。但因為公司是旅集會業，“全域”一詞是行業內的專有術語，而且也是公司的業務術語，假如用“全域”來表示整個系統，在溝通時往往會造成誤會，為此公司內部都習慣使用“全局”來指代整個項目系統。
結語
以上便是從大框架層面介紹優秀的產品文檔須要囊括的內容，后續將在系列（二）中，從需求文檔——正文的角度介紹本人寫產品文檔的小方法和tips。整個系列均屬作者本人的看法，歡迎交流。
另附樣例作為參考：
開發用文檔：
商用文檔：（提取碼：rqff）
（備注：商用文檔為“當年”自學改行產品時的作業，相對孱弱，你們瞧瞧框架即可，何必較真哈）
相關文章
為您推薦
加載中...