需求文檔的重要性，相信大多數(shù)產(chǎn)品經(jīng)理都有所感知了，一份好的需求文檔，更是能提高效率，減少重復(fù)溝通所花費的時間。那么，好的需求文檔，到底長啥樣？

去年入職新公司后，研發(fā)團隊人員均不在base地，且都是通過外協(xié)的形式進行項目開發(fā)（問就是初創(chuàng)團隊的難），這對導(dǎo)致了產(chǎn)研團隊溝通成本很高。另一方面，對于產(chǎn)品工作的最后一公里、產(chǎn)品經(jīng)理的重要交付物——需求文檔的要求也極其的高，因為異地協(xié)作溝通成本高的問題，一份好的需求文檔可以有效降低重復(fù)溝通的時間，以便有更多的時間去摸魚（bushi）。

那么，就讓我來聊一聊需求文檔（prd/產(chǎn)品需求規(guī)格書）的結(jié)構(gòu)和一些需要注意的點。

一、好的需求文檔，到底長啥樣？

在說我的結(jié)論之前，我們先來看看市面上的文檔管理工具所提供的需求文檔的模板格式，下圖分為飛書、語雀和云效：

以這三家為例，我們來看看對應(yīng)的需求文檔的結(jié)構(gòu)：

• 飛書：版本信息、變更日志、文檔說明（名詞解釋）、需求背景（產(chǎn)品/數(shù)據(jù)現(xiàn)狀、用戶調(diào)研、競品分析）、需求范圍、功能詳細(xì)說明（產(chǎn)品流程圖、交互原型圖、功能說明）、非功能需求、埋點、項目規(guī)劃、附錄。
• 語雀：變更記錄、背景介紹（業(yè)務(wù)背景、業(yè)務(wù)場景）、產(chǎn)品概述（產(chǎn)品定位、服務(wù)對象、產(chǎn)品邏輯、信息架構(gòu)、角色術(shù)語）、需求說明（需求列表、需求明細(xì)、非功能需求）、人員&排期。
• 云效：基本信息（項目成員）、需求背景、產(chǎn)品目標(biāo)、衡量指標(biāo)、產(chǎn)品需求、功能及界面設(shè)計、問題、暫不支持、附錄。

是不是很相似？

互聯(lián)網(wǎng)隨著這些年的發(fā)展，需求文檔也慢慢的標(biāo)準(zhǔn)化，只需在對應(yīng)的模板稍許改造就能得出符合自己團隊的模板。在前司中，因在線文檔管理工具使用的是語雀，其中不乏有同事直接使用語雀的需求文檔模板。

而我的需求文檔，隨著工作這幾年的迭代和與不同團隊的適配，自認(rèn)為還是比較好的模板（叉腰），讓我們來看下文檔結(jié)構(gòu)，如下圖：

其中我認(rèn)為版本記錄、需求說明、名詞解釋、需求列表、詳細(xì)需求說明和問題為需求文檔的必要性內(nèi)容，而暫不支持、性能需求、數(shù)據(jù)需求及其他均為選擇性內(nèi)容。

1. 版本記錄

版本記錄是需求文檔非常重要的一部分，因為很多需求都是會產(chǎn)生變更的，特別是在一些比較大的需求上…這就導(dǎo)致了版本記錄的必要性，這樣在用戶（研發(fā)/測試/自己…）閱讀文檔時就能大體上知道這個需求的迭代情況。

版本記錄包含日期、版本號、修訂人和修訂描述，其中需格外注意的是修訂描述。在修訂描述中需求描述修訂原因和具體內(nèi)容，當(dāng)然修訂原因也可單獨拆分出一個字段進行管理，原因需說明該版本的‘增刪改’情況。具體內(nèi)容則需說明修改的‘場景+結(jié)果’，例如后臺管理端新增用戶時剔除手機號的必填校驗，則可將具體內(nèi)容描述為用戶在管理端「用戶管理」中新增/修改用戶時，提交時去除手機號的必填校驗。

言簡意賅的內(nèi)容描述，可以降低理解成本。

2. 需求說明

需求說明包含需求來源、需求背景和需求目標(biāo)。

需求來源主要記錄需求的所屬項目、需求提出人和主要的負(fù)責(zé)人（需求負(fù)責(zé)人/研發(fā)負(fù)責(zé)人/測試負(fù)責(zé)人…）。在一個公司中有多個項目在開發(fā)屬于正?，F(xiàn)象，因此需記錄需求的所屬項目；需求提出人則可以是老板、對應(yīng)的業(yè)務(wù)同事或者是自己，若后續(xù)需求提出人出現(xiàn)離崗交接時，也可跟進對應(yīng)的提出人；主要負(fù)責(zé)人則按照公司規(guī)模進行實際填寫，我前司人員較多，還會涉及到系統(tǒng)支持、排版等相關(guān)人員。

需求背景主要描述需求產(chǎn)生的背景，即為什么要做這個需求。需求背景的書寫切不可流于形式，深入的理解需求背景可以更好的理解當(dāng)前公司的戰(zhàn)略方向，因為每一個需求都是公司戰(zhàn)略執(zhí)行層的具體表現(xiàn)。

需求目標(biāo)則是描述需求實現(xiàn)的目標(biāo)，即要做什么。需求目標(biāo)可大可小，小至功能目標(biāo)，大至業(yè)務(wù)目標(biāo)，需把握好需求目標(biāo)的尺度。

3. 名詞解釋

名詞解釋主要解釋該需求的專業(yè)名詞，讓用戶更好的理解需求。例如在票據(jù)行業(yè)中的背書、貼現(xiàn)、前手等專有名詞，是有必要在對應(yīng)的需求中進行闡述說明的。

4. 需求列表

需求列表（feature list）記錄了需求的具體需求，即怎么做。對于歷史項目/需求的更新，需求列表則尤為重要，在需求列表中描述本次需求的變更點，可以讓研發(fā)/測試更好理解本次的需求內(nèi)容，起到了‘總’的概覽作用。

5. 詳細(xì)需求說明

詳細(xì)需求說明需包含UML圖、原型圖和詳細(xì)邏輯說明。UML圖在正常的需求中起碼要包含活動圖/時序圖+狀態(tài)機圖（UML這么畫請看這篇文章），一個邏輯清晰的圖可以勝過千言萬語；原型圖和詳細(xì)邏輯說明相輔相成，構(gòu)成了需求文檔篇幅最大的部分，是對「怎么做」的更加詳細(xì)的描述，詳細(xì)到頁面如何跳轉(zhuǎn)、按鈕的交互邏輯、字段的展示邏輯等。

6. 問題

問題主要記錄需求評審過程中參會人員提出了相關(guān)問題，其中若未能當(dāng)場給出解答的部分，則需對問題和結(jié)論進行記錄。

7. 暫不支持

暫不支持記錄當(dāng)前需求無法實現(xiàn)的部分。正常情況下，需求評審之前應(yīng)對需求的可實現(xiàn)方案進行初步溝通，即和研發(fā)通通氣，這樣可以避免評審過程針對不可實現(xiàn)的打斷問題。

8. 性能需求

性能需求包含并發(fā)量、響應(yīng)速度等一系列系統(tǒng)性能相關(guān)的需求。性能需求相關(guān)的內(nèi)容偏向于技術(shù)層面，我在當(dāng)前基本不寫（寫了也沒啥用）。

9. 數(shù)據(jù)需求

數(shù)據(jù)需求包含數(shù)據(jù)量、存儲時間等，這與單獨的報表需求不同，因此我也不寫。

二、一些tips

說完我當(dāng)前的需求文檔構(gòu)成之后，我再來補充幾點我認(rèn)為比較重要的tips。

1. 善用目錄導(dǎo)航

對于動輒幾千字的需求文檔，要善用目錄導(dǎo)航，這樣在閱讀時可快速定位需求內(nèi)容，結(jié)構(gòu)性會更強。

關(guān)于管理端來說，我一般目錄導(dǎo)航中會根據(jù)頁面的從上到下的邏輯進行描述，例如按照查詢條件、列表和操作進行說明。

2. 文檔拆分

如果是一個大需求，涉及到系統(tǒng)的多個模塊的變更改造，最好對文檔進行拆分，再利用文件夾對其規(guī)整，這樣在團隊人員閱讀起來會降低一定門檻，對于后續(xù)的任務(wù)分配的工作也有一定幫助。

3. 需求顆粒度

需求的顆粒度是一個很難把控的事情。

比如，是否要涉及到表的相關(guān)字段。這個非常考驗產(chǎn)品經(jīng)理對于表的理解和系統(tǒng)的熟悉程度，因為很多情況下用戶端的字段和數(shù)據(jù)庫的字段并不是一一對應(yīng)的。于我而言，若是比較陌生的系統(tǒng)，則是按照‘取值路徑+截圖’的形式進行描述，這樣能有效避免二義性。

另外，B端產(chǎn)品很多情況下會涉及到與外部對接，那么對方系統(tǒng)和本司系統(tǒng)避免不了要交互，那么在這種情況下，盡量保證詳細(xì)到對接文檔中的每個字段，這樣能最大程度降低溝通成本。

4. 舉個例子

很多時候，研發(fā)和測試對于需求的描述會感到非?；逎y懂，這樣「舉個例子」就不可避免。我一般是會在比較難懂的部分后面增加一個實際例子，就比如：

1 + 1 = 2

通過一個具體的例子來對需求點進行闡釋，可以有效增強需求的可讀性。

5. 需求重點的標(biāo)注

需求文檔作為產(chǎn)品經(jīng)理的輸出物，產(chǎn)品經(jīng)理對于需求可謂是了然于胸，那么在文檔中就可以著重標(biāo)注出需求的重點（例如用紅色字體進行突出），以此突出某個重要需求點，要求研發(fā)和測試著重關(guān)注。

三、總結(jié)

需求文檔對于我來說主要作用還是傳達和記錄，讓團隊成員對于需求達成相同的認(rèn)知，以及讓后人對某個需求有跡可循，不至于系統(tǒng)‘口口相傳’。因此，需求文檔并不是所謂產(chǎn)品經(jīng)理一言堂的一個文檔，而是團隊對需求的共同認(rèn)知，所以適合團隊的就是一份好的需求文檔。

如果需要我對好的文檔下一份定義，那就是——問題的答案都在文檔中。