需求文檔是產(chǎn)品經(jīng)理日常工作輸出最重要的文檔，需求文檔是在寫什么？應(yīng)當(dāng)包含什么內(nèi)容？

弄清這個(gè)問(wèn)題，首先要明確需求文檔的讀者是誰(shuí)，讀者要從需求文檔中獲取到哪些內(nèi)容，讀者的不同影響到需求文檔的組織形式，而組織形式又依賴于產(chǎn)品經(jīng)理自身的習(xí)慣，不可一概而論。

以下是我理解的需求文檔該是什么樣子的，拋磚引玉，供大家探討。

需求文檔最重要的讀者首先是產(chǎn)品經(jīng)理自己，無(wú)論是需求實(shí)現(xiàn)前用需求文檔講述需求的實(shí)現(xiàn)思路，實(shí)現(xiàn)時(shí)按需求文檔進(jìn)行設(shè)計(jì)、研發(fā)、測(cè)試，還是需求上線后回顧需求文檔進(jìn)行復(fù)盤總結(jié)，都是依照產(chǎn)品經(jīng)理寫的需求文檔。其次的讀者才是負(fù)責(zé)需求實(shí)現(xiàn)的設(shè)計(jì)師、研發(fā)人員、測(cè)試人員以及其他產(chǎn)品經(jīng)理。

按我的習(xí)慣，需求文檔會(huì)包含以下五個(gè)部分的內(nèi)容。

一、需求變更日志和版本迭代記錄

第一部分是需求變更日志和版本迭代記錄。需求從提出到最終上線，中間必然經(jīng)歷一些需求變更或方案調(diào)整，因而需要有變更日志來(lái)記錄這些變更。

需求變更日志并不只是寫需求新增或減少了哪些功能，而是更仔細(xì)些。

例如：需求中的A功能點(diǎn)，原來(lái)打算用方案一實(shí)現(xiàn)，但考慮到資源、現(xiàn)實(shí)場(chǎng)景的限制，改為用方案二實(shí)現(xiàn)，這個(gè)也要寫，雖然從結(jié)果上看仍然是實(shí)現(xiàn)了需求中的A功能點(diǎn)，但從過(guò)程上看，方案一到方案二的轉(zhuǎn)變，是產(chǎn)品經(jīng)理思考的升級(jí)，也是對(duì)資源限制更深的考慮。

此外還應(yīng)記錄清楚需求是因什么原因變更，變更前后是什么樣子，可能會(huì)產(chǎn)生哪些影響，以便后面查找細(xì)節(jié)。

而版本迭代記錄，除了包括對(duì)需求中功能的版本迭代，還應(yīng)包括產(chǎn)品經(jīng)理對(duì)這個(gè)需求思考路徑的迭代。

需求中功能的版本迭代，這個(gè)大家比較熟悉，不贅述，主要想說(shuō)明下產(chǎn)品經(jīng)理對(duì)需求思考路徑的迭代是什么？為什么要這么做？

之前提過(guò)，產(chǎn)品經(jīng)理很大的工作是在做決策，因此決策質(zhì)量很重要，而決策質(zhì)量需要通過(guò)不斷地優(yōu)化決策思考路徑來(lái)提高，產(chǎn)品經(jīng)理應(yīng)該記錄自己對(duì)需求的思考過(guò)程，對(duì)過(guò)程進(jìn)行不斷總結(jié)和優(yōu)化。

另外，將這些思考的過(guò)程展示出來(lái)及與其他同事討論，可以跳出自己固有的思維模式，兼容并包。

所以我一直認(rèn)為產(chǎn)品經(jīng)理在處理一個(gè)需求時(shí)，其思考路徑、決策依據(jù)應(yīng)該公開(kāi)透明，能夠讓所有參與需求的人都能夠可查看、可探討（來(lái)自瑞·達(dá)里歐，有興趣的朋友可以去看看他的《原則》）。

那么，我輸出需求變更日志和版本迭代記錄的過(guò)程是怎樣的呢？

按我的習(xí)慣，在輸出一個(gè)需求文檔的時(shí)候，會(huì)先按當(dāng)下我能考慮的情況先寫一個(gè)Beta版，這時(shí)候我將它命名為V0.7版本，然后隔一天我再重新思考，看自己昨天寫的需求文檔，這時(shí)能發(fā)現(xiàn)很多不足的地方，那就從頭開(kāi)始改一遍，標(biāo)明需求有哪些變更，這時(shí)的版本是V0.8版本。

下一步找其他產(chǎn)品經(jīng)理向他講述一遍這個(gè)需求文檔或在組內(nèi)組織一次需求評(píng)審，綜合意見(jiàn)，再修改一遍，標(biāo)明需求有哪些變更，這時(shí)的版本是V0.9版本，最后再找開(kāi)發(fā)測(cè)試設(shè)計(jì)的同學(xué)進(jìn)行需求評(píng)審，從開(kāi)發(fā)測(cè)試設(shè)計(jì)的角度對(duì)需求的實(shí)現(xiàn)做一遍修改，標(biāo)明有哪些變更，形成最終的版本V1.0。

這樣下來(lái)，一份需求文檔能夠包含產(chǎn)品經(jīng)理對(duì)一個(gè)需求實(shí)現(xiàn)方案完整的思考過(guò)程，其中不僅有自己思考的升級(jí)，還有從研發(fā)、測(cè)試、設(shè)計(jì)等各個(gè)角度對(duì)實(shí)現(xiàn)方案的調(diào)整補(bǔ)充，是針對(duì)這個(gè)需求，在當(dāng)前的資源限制、背景約束下最好的實(shí)現(xiàn)方案。

有了需求變更日志和需求版本迭代記錄，不僅可以做到需求的實(shí)現(xiàn)邏輯實(shí)現(xiàn)思路可溯源，完整記錄整個(gè)需求從被提出到上線多個(gè)版本，期間的產(chǎn)品思路、實(shí)現(xiàn)邏輯有了哪些變化，產(chǎn)品經(jīng)理可時(shí)?；仡櫮脕?lái)參考，產(chǎn)品團(tuán)隊(duì)可針對(duì)大的需求做針對(duì)性復(fù)盤，也可提供給后來(lái)接手工作的產(chǎn)品經(jīng)理了解需求的完整迭代過(guò)程。

二、背景&方案&價(jià)值

背景、方案和價(jià)值，是需求文檔的核心，是任何需求在進(jìn)入到實(shí)現(xiàn)階段前一定要想清楚、一定要反復(fù)探討的部分。

需求是背景下的需求。這里的背景，需要寫明白的內(nèi)容可包括但不限于當(dāng)前產(chǎn)品所處行業(yè)的現(xiàn)狀，產(chǎn)品/功能模塊所處的狀態(tài)、目標(biāo)，開(kāi)發(fā)團(tuán)隊(duì)的資源限制、技術(shù)限制等。

最開(kāi)始做產(chǎn)品經(jīng)理時(shí)，體驗(yàn)其他產(chǎn)品的一些功能，不免吐槽，這里怎能這樣做？應(yīng)該那樣做啊，要是我的話一定能比他做得更好，諸如此類。

到后來(lái)做產(chǎn)品的經(jīng)驗(yàn)見(jiàn)長(zhǎng)，才明白任何一個(gè)需求都受限于當(dāng)時(shí)的背景狀況、資源限制，拋開(kāi)這些背景談實(shí)現(xiàn)都是扯淡，產(chǎn)品經(jīng)理要做的是在當(dāng)前背景下，找到最佳的實(shí)現(xiàn)方案。因此，梳理需求背景是產(chǎn)品經(jīng)理對(duì)當(dāng)前資源現(xiàn)狀的考量，是實(shí)現(xiàn)需求的第一步。

方案是背景下需求的實(shí)現(xiàn)方案。既然需求會(huì)受到資源現(xiàn)狀的限制，那么方案也必然有所不同，甚至可能會(huì)有折中妥協(xié)，會(huì)有不完整的方案。有時(shí)需求本身就是試驗(yàn)性質(zhì)的，是為了快速測(cè)試效果，那么在方案上選擇一些實(shí)現(xiàn)簡(jiǎn)單、開(kāi)發(fā)難度較小的方案也就不足為奇了。

在寫方案時(shí)，可以按照「用戶-場(chǎng)景-問(wèn)題-方案」這個(gè)框架簡(jiǎn)要寫明實(shí)現(xiàn)方案，也就是什么樣的用戶在什么樣的場(chǎng)景下遇到了什么問(wèn)題，提供的解決方案是什么——這里要求方案要經(jīng)過(guò)提煉，能夠通過(guò)一句話說(shuō)清楚。

價(jià)值是指實(shí)現(xiàn)這個(gè)需求能夠帶來(lái)什么樣的價(jià)值，包括用戶價(jià)值和業(yè)務(wù)價(jià)值，用戶價(jià)值是指實(shí)現(xiàn)這個(gè)需求能夠給用戶帶來(lái)什么樣的價(jià)值，例如提升用戶的使用體驗(yàn)等；業(yè)務(wù)價(jià)值是指實(shí)現(xiàn)這個(gè)需求能給產(chǎn)品的業(yè)務(wù)帶來(lái)什么樣的價(jià)值，例如提升用戶留存或者提升業(yè)務(wù)收入等。

需求不一定要同時(shí)提供用戶價(jià)值和業(yè)務(wù)價(jià)值，也不一定兩個(gè)價(jià)值都需要為正（例如帶來(lái)很大的業(yè)務(wù)價(jià)值而犧牲很小的用戶價(jià)值也是可以的），具體需要依據(jù)產(chǎn)品當(dāng)前的狀態(tài)來(lái)考慮，但不能帶來(lái)價(jià)值的需求一定是有問(wèn)題的。

此外，在思考需求能夠產(chǎn)生什么價(jià)值時(shí)，同時(shí)要思考的是以什么數(shù)據(jù)指標(biāo)來(lái)評(píng)估這個(gè)價(jià)值，也就是需求上線后效果的好與壞要有量化的指標(biāo)。不一定所有的需求都能夠找到量化的效果指標(biāo)，但一定要盡量找到這個(gè)指標(biāo)。只有需求的效果能夠被衡量，產(chǎn)品才能夠往更優(yōu)的方向迭代。

三、業(yè)務(wù)邏輯&流程說(shuō)明&功能需求詳述

第三部分主要是需求實(shí)現(xiàn)的部分，我把它劃分為業(yè)務(wù)邏輯、流程說(shuō)明和功能需求詳述。

業(yè)務(wù)邏輯部分描述的是需求中涉及到的數(shù)據(jù)流向和用戶流向，特別是需求涉及到多個(gè)系統(tǒng)時(shí)，數(shù)據(jù)和用戶在系統(tǒng)之間如何交互的（這部分的內(nèi)容偏復(fù)雜，后面再單獨(dú)寫下我的理解）。

目前針對(duì)業(yè)務(wù)邏輯部分，我主要的輸出是多通道的泳道圖來(lái)描述系統(tǒng)間的交互。這里應(yīng)該特別注意的是在說(shuō)明數(shù)據(jù)流向時(shí)要兼顧考慮正常流程和異常流程，以及在說(shuō)明用戶流向時(shí)要考慮清楚需求邊界。

此外，需求的復(fù)雜程度不同，可能還會(huì)包含頁(yè)面流程圖、頁(yè)面結(jié)構(gòu)圖等。

功能需求詳述就是常說(shuō)的原型。

我目前的習(xí)慣，在需求文檔的早期版本不喜歡輸出高保真的原型，而是傾向于用低保真原型加文字描述的方式來(lái)說(shuō)明需求中的功能實(shí)現(xiàn)。

功能需求詳述以需求中的頁(yè)面為單位，分為原型圖、需求說(shuō)明和交互說(shuō)明三個(gè)部分。

原型圖對(duì)需求涉及的每個(gè)元素進(jìn)行標(biāo)注；需求說(shuō)明針對(duì)原型圖中的標(biāo)注進(jìn)行文字說(shuō)明，包括字段邏輯、按鈕邏輯、頁(yè)面邏輯等；交互說(shuō)明則是針對(duì)一些非邏輯的交互進(jìn)行說(shuō)明，例如某些字段、需要突出顯示，頁(yè)面變化時(shí)需要怎樣的特殊效果等等。

四、相關(guān)文檔的集合

日常工作中，時(shí)常出現(xiàn)想要找需求的某個(gè)相關(guān)文檔時(shí)，四處搜索，浪費(fèi)很多時(shí)間的情況，為此我形成了一個(gè)習(xí)慣，就是把需求文檔作為一個(gè)所有相關(guān)文檔的集合。如埋點(diǎn)文檔、設(shè)計(jì)稿、接口文檔、測(cè)試用例文檔、開(kāi)發(fā)相關(guān)的鏈接、上線后的數(shù)據(jù)等，都以鏈接的形式整理在需求文檔中，這樣每次需要找需求的相關(guān)文檔，都可以從需求文檔中快速找到。

五、需求上線后的數(shù)據(jù)

凡是需求，必然要有驗(yàn)證效果的數(shù)據(jù)，而從每一個(gè)失敗與成功的需求中不斷總結(jié)和反思，是產(chǎn)品經(jīng)理成長(zhǎng)的重要途徑。如上文所說(shuō)，產(chǎn)品經(jīng)理應(yīng)該保持開(kāi)放透明，那么就意味著產(chǎn)品經(jīng)理對(duì)于需求輸出的實(shí)現(xiàn)方案，最終結(jié)果無(wú)論是好是壞，都應(yīng)該將效果數(shù)據(jù)按實(shí)際公開(kāi)，這既能夠促使產(chǎn)品經(jīng)理自己不斷改進(jìn)產(chǎn)品思路，也能夠讓參與需求的相關(guān)同事了解自己的工作成果，增加他們的參與感與成就感。

以上便是我理解的需求文檔應(yīng)該包含的一些內(nèi)容，可能過(guò)于繁雜，具體還是要根據(jù)每個(gè)人自己的工作習(xí)慣做取舍，僅供參考。

希望能幫到你。

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

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