作為產(chǎn)品經(jīng)理的必備技能，寫PRD是基本功之一。但就是這么基礎(chǔ)的要求，還是有部分產(chǎn)品經(jīng)理不知道怎么寫，或者剛?cè)腴T還不會(huì)寫。這篇文章，作者給我們?cè)敿?xì)說(shuō)明了PRD的要求和寫法，希望可以幫到大家。

1.需求文檔的作用

1.1 對(duì)設(shè)計(jì)任務(wù)管理的作用

在做一個(gè)設(shè)計(jì)任務(wù)時(shí)，需要收集現(xiàn)有情況、歷史原因、設(shè)計(jì)阻礙點(diǎn)等信息，輸出當(dāng)前任務(wù)的設(shè)計(jì)文檔，當(dāng)前文檔又可作為后續(xù)優(yōu)化設(shè)計(jì)的方向和參考依據(jù)。

• 產(chǎn)品需求文檔是產(chǎn)品工作流程中各個(gè)環(huán)節(jié)對(duì)需求描述和傳達(dá)最快速的工具，減少溝通成本：每一個(gè)環(huán)節(jié)和任務(wù)協(xié)作人都需要理解需求的定義和描述，通過(guò)文檔對(duì)需求的傳達(dá)，能減少產(chǎn)品經(jīng)理在各環(huán)節(jié)與各方的溝通交流。
• 產(chǎn)品需求文檔保證各部門溝通有理有據(jù)，還可以為產(chǎn)品質(zhì)量控制做好保障：當(dāng)產(chǎn)品設(shè)計(jì)研發(fā)過(guò)程中不斷偏離需求時(shí)，此時(shí)需求文檔作為一份需求評(píng)審時(shí)已統(tǒng)一目標(biāo)的文檔，有利于團(tuán)隊(duì)回歸到產(chǎn)品設(shè)計(jì)的正軌上，保障產(chǎn)品按照目標(biāo)順利完成上線。
• 產(chǎn)品需求文檔有利于產(chǎn)品迭代管理中回溯：此前需求的設(shè)計(jì)及規(guī)劃產(chǎn)品迭代管理中，我們可以回溯上一版需求文檔中的迭代計(jì)劃的背景及需求的目標(biāo)，結(jié)合當(dāng)前的效果及不足，做出新的迭代的規(guī)劃。
• 產(chǎn)品需求文檔有助于新成員快速熟悉項(xiàng)目：對(duì)于組內(nèi)新的產(chǎn)品經(jīng)理來(lái)說(shuō)，了解過(guò)往的產(chǎn)品需求文檔可以更好地了解產(chǎn)品的內(nèi)在邏輯和外在表現(xiàn)。

1.2 對(duì)協(xié)作人員的作用

一般情況下，任務(wù)納入迭代計(jì)劃后，協(xié)作流程中第一個(gè)設(shè)計(jì)環(huán)節(jié)是產(chǎn)品設(shè)計(jì)，即輸出需求文檔。任務(wù)迭代過(guò)程中，協(xié)作人員需要閱覽需求文檔，依據(jù)需求文檔做設(shè)計(jì)和開發(fā)，其使用場(chǎng)景如下：

2. 如何寫好需求文檔

要想寫出好的需求文檔，那我們首先要明白什么樣的文檔才算是一個(gè)好的需求文檔。在我看來(lái)，一份好的需求文檔至少要講清楚以下幾個(gè)問(wèn)題：

• 方案是否合理：選擇的方案是否為解決當(dāng)前問(wèn)題的最優(yōu)解。
• 功能規(guī)則設(shè)計(jì)是否詳盡：功能改動(dòng)點(diǎn)和業(yè)務(wù)規(guī)則描述是否合理且詳盡，是否已存在邏輯漏洞。
• 設(shè)計(jì)是否具有拓展性：對(duì)后續(xù)迭代和拓展是否提供了良好的基礎(chǔ)。

第一點(diǎn)實(shí)際上就是要求我們?nèi)ピO(shè)計(jì)對(duì)的需求。第二個(gè)點(diǎn)是要求對(duì)我們所定義的需求，不僅要描述主流程還要將與該流程相配合的相關(guān)其他模塊都描述清楚。第三點(diǎn)是在前兩者的基礎(chǔ)上進(jìn)行一個(gè)升級(jí)，也就是當(dāng)我們能正確的完整的描述一個(gè)需求之后接下來(lái)希望你所描述的需求能是最優(yōu)方案，也就是能給用戶帶來(lái)更好的用戶體驗(yàn)的一種方案。

3. 需求文檔各模塊要點(diǎn)

3.1 需求背景&歷史原因

需求是當(dāng)前背景下的需求。這里的背景，需要寫明白的內(nèi)容可包括但不限于當(dāng)前產(chǎn)品所處行業(yè)的現(xiàn)狀，產(chǎn)品/功能模塊所處的狀態(tài)、目標(biāo)，開發(fā)團(tuán)隊(duì)的資源限制、技術(shù)限制等。在作為用戶體驗(yàn)其他競(jìng)品的一些功能時(shí)，不免吐槽，這里怎能這樣做？應(yīng)該那樣做啊。對(duì)于自己所做的產(chǎn)品同樣如此，應(yīng)當(dāng)明白，任何一個(gè)需求都受限于當(dāng)時(shí)的背景狀況、資源限制，拋開這些背景談實(shí)現(xiàn)都是扯淡，產(chǎn)品經(jīng)理要做的是在當(dāng)前背景下，找到最佳的實(shí)現(xiàn)方案。因此，梳理需求背景是產(chǎn)品經(jīng)理對(duì)當(dāng)前資源現(xiàn)狀的考量，是實(shí)現(xiàn)需求的第一步。

通過(guò)對(duì)歷史原因和歷史設(shè)計(jì)方案的梳理，可以讓自己對(duì)當(dāng)前任務(wù)的阻礙點(diǎn)更加明確，甚至可以為自己的解決方案提供新思路。簡(jiǎn)道云內(nèi)，雖然各模塊任務(wù)都是分開設(shè)計(jì)，但不同任務(wù)之間可能有關(guān)聯(lián)關(guān)系，在需求背景梳理中，這些都可以明確。

3.2 需求分析

來(lái)源于用戶的需求才是最真實(shí)的需求，有些功能點(diǎn)無(wú)法滿足用戶需求，但是只有在具體業(yè)務(wù)場(chǎng)景下才能體現(xiàn)，通過(guò)對(duì)用戶場(chǎng)景的分析，挖掘出當(dāng)前要解決的問(wèn)題以及后續(xù)衍生出的問(wèn)題。

用戶回訪是其中一個(gè)重要環(huán)節(jié)，很多用戶需求，都有替代方案可以解決問(wèn)題，但是用戶不愿意采用替代方案，內(nèi)在原因需要深究。需求庫(kù)里的需求是經(jīng)過(guò)幾次轉(zhuǎn)手和加工的，可能會(huì)存在偏差和信息不對(duì)等，通過(guò)用戶回訪可以與用戶直接溝通，消除信息誤差。

3.3 競(jìng)品分析

競(jìng)品分析可分為兩部分：

直接競(jìng)品分析：

1. 直接競(jìng)品是否存在該問(wèn)題
2. 是否解決了該問(wèn)題。若沒(méi)解決，原因是什么。若解決了，是用何種方式解決的
3. 競(jìng)品的解決方案是最優(yōu)方案嗎，是否存在更好的方案

非標(biāo)競(jìng)品分析：

1. 非標(biāo)競(jìng)品中是否存在相似場(chǎng)景，該場(chǎng)景提供的適用范圍有哪些交叉點(diǎn)
2. 成熟的非標(biāo)競(jìng)品，一般具有更成熟的解決方案，當(dāng)前解決方案是否適用于當(dāng)前產(chǎn)品中

3.4 問(wèn)題分析與方案抉擇

方案是背景下需求的實(shí)現(xiàn)方案。既然需求會(huì)受到資源現(xiàn)狀的限制，那么方案也必然有所不同，甚至可能會(huì)有折中妥協(xié)，會(huì)有不完整的方案。有時(shí)需求本身就是試驗(yàn)性質(zhì)的，是為了快速測(cè)試效果，那么在方案上選擇一些實(shí)現(xiàn)簡(jiǎn)單、開發(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)的方向迭代。

3.5 功能規(guī)則&需求詳述

主要是需求實(shí)現(xiàn)的部分，詳述需求解決方案和功能規(guī)則邏輯。業(yè)務(wù)邏輯部分描述的是需求中涉及到的數(shù)據(jù)流向和用戶流向，特別是需求涉及到多個(gè)系統(tǒng)時(shí)，數(shù)據(jù)和用戶在系統(tǒng)之間如何交互的。目前針對(duì)業(yè)務(wù)邏輯部分，我主要的輸出是多通道的泳道圖來(lái)描述系統(tǒng)間的交互。這里應(yīng)該特別注意的是在說(shuō)明數(shù)據(jù)流向時(shí)要兼顧考慮正常流程和異常流程，以及在說(shuō)明用戶流向時(shí)要考慮清楚需求邊界。此外，需求的復(fù)雜程度不同，可能還會(huì)包含頁(yè)面流程圖、頁(yè)面結(jié)構(gòu)圖等。

在需求文檔中需要對(duì)交互形式和前端校驗(yàn)邏輯等做出簡(jiǎn)要說(shuō)明，以此來(lái)協(xié)助交互和前端更好的理解和實(shí)現(xiàn)需求。尤其是對(duì)重要的地方進(jìn)行文字說(shuō)明，包括字段邏輯、按鈕邏輯、頁(yè)面邏輯等。對(duì)一些非邏輯的交互進(jìn)行說(shuō)明，例如某些字段、需要突出顯示，頁(yè)面變化時(shí)需要怎樣的特殊效果等等。

3.6 數(shù)據(jù)埋點(diǎn)

凡是需求，必然要有驗(yàn)證效果的數(shù)據(jù)，而從每一個(gè)失敗與成功的需求中不斷總結(jié)和反思，是產(chǎn)品經(jīng)理成長(zhǎng)的重要途徑。實(shí)際效果數(shù)據(jù)是衡量需求輸出實(shí)現(xiàn)方案的其中一個(gè)標(biāo)準(zhǔn)，這既能夠促使產(chǎn)品經(jīng)理自己不斷改進(jìn)產(chǎn)品思路，也能夠讓參與需求的相關(guān)同事了解自己的工作成果。

4. 容易出現(xiàn)的問(wèn)題

初期寫PRD，容易出現(xiàn)以下問(wèn)題：

1. 剛開始的PRD可讀性較差，沒(méi)有站在閱讀對(duì)象的角度思考他們希望在PRD上獲取什么信息，對(duì)于結(jié)果輸出和總結(jié)內(nèi)容，沒(méi)有清晰明顯的體現(xiàn)出來(lái)。
2. PRD的信息同步有部分缺失，與研發(fā)或交互在同頻信息時(shí)，部分信息沒(méi)有傳達(dá)到，在后續(xù)設(shè)計(jì)中需要再次溝通確認(rèn)。
3. 當(dāng)前任務(wù)邊界不明顯，對(duì)于本次需要解決的問(wèn)題和以后解決的問(wèn)題，該如何區(qū)分，區(qū)分依據(jù)的闡述不夠清楚。

為了解決上述的問(wèn)題，需要嘗試從用戶思維、結(jié)構(gòu)化思維、閉環(huán)思維來(lái)幫助思考和解決問(wèn)題。

1）用戶思維：站在用戶視角，提升用戶體驗(yàn)

用戶思維，顧名思義，就是“站在用戶的角度來(lái)思考問(wèn)題”的思維。使得需求落地前期最為關(guān)鍵的一步，是將需求定義及描述清楚。為了讓協(xié)同的人員理解需求，產(chǎn)品經(jīng)理需要站在他們的視角，了解他們的工作場(chǎng)景及訴求，輸出解決方案。

2）結(jié)構(gòu)化思維：結(jié)論先行，突出重點(diǎn)

結(jié)構(gòu)化思維的本質(zhì)是框架。是從無(wú)序到有序的一種思考過(guò)程，將搜集到的信息、數(shù)據(jù)、知識(shí)等素材按一定的邏輯進(jìn)行歸總，繼而讓繁雜的問(wèn)題簡(jiǎn)單化；從而讓我們的大腦更快速、更有效的處理信息。

• 產(chǎn)品需求文檔應(yīng)從宏觀到微觀地進(jìn)行鋪展，因而需要先寫總體需求（依據(jù)實(shí)際情況可附上業(yè)務(wù)流程、功能列表清單、功能結(jié)構(gòu)圖、信息架構(gòu)圖、角色權(quán)限等），再寫具體需求（詳細(xì)講解需求的流程、規(guī)則和實(shí)現(xiàn)）。
• 使用結(jié)構(gòu)化思維去進(jìn)行思考和表達(dá)時(shí)：結(jié)論先行，再去展開闡述，先突出重點(diǎn)，能夠讓對(duì)方更加輕松地理解我們想表達(dá)的觀點(diǎn)。如編寫背景及目標(biāo)時(shí)，可先寫總的結(jié)論，在分點(diǎn)詳細(xì)闡述,對(duì)需要關(guān)注的地方進(jìn)行加粗，避免大段文字的敘述。
• 業(yè)務(wù)流程圖繪制也可采用結(jié)構(gòu)化的思維。在進(jìn)行流程圖的繪制過(guò)程中，只有一個(gè)流程主線，可使得流程圖脈絡(luò)清晰，業(yè)務(wù)明了。如果異常流程非常復(fù)雜，針對(duì)每一個(gè)流程節(jié)點(diǎn)，如果出現(xiàn)異常流程，可以建立子流程模塊，在子流程中標(biāo)記出異常場(chǎng)景的分支流程；然后把子流程鏈接到流程概圖。

3）閉環(huán)思維：有始有終，推動(dòng)問(wèn)題解決

閉環(huán)思維是指我們?cè)谧鲆患虑闀r(shí)，要做到有始有終。不是僅僅把事情做了，而是要保證事情做了以后，是能夠解決問(wèn)題，或者有相應(yīng)的見效或進(jìn)展的。

• 依據(jù)評(píng)審后的討論結(jié)果，不斷修正產(chǎn)品需求文檔。在需求評(píng)審前，產(chǎn)品經(jīng)理已經(jīng)輸出了第一份產(chǎn)品需求文檔。但這個(gè)產(chǎn)品需求并非初步方案就能夠解決問(wèn)題，在歷經(jīng)交互、開發(fā)評(píng)審后，才會(huì)最終敲定方案。因此，我們需要不斷地修正需求文檔并同步給各協(xié)同人員。當(dāng)然，也應(yīng)該附上相應(yīng)的修訂記錄，但由于工具的發(fā)展，我們可以依賴工具的變更歷史來(lái)回顧修訂記錄，因此不再需要在需求文檔上附上修訂記錄。
• 產(chǎn)品需求文檔解決的不僅僅是當(dāng)前的一個(gè)問(wèn)題，也是規(guī)劃推動(dòng)下一個(gè)問(wèn)題的解決。盡管每次迭代的目標(biāo)細(xì)分不一樣，但是總體的目標(biāo)都是把產(chǎn)品做好。因而為了推動(dòng)這個(gè)終極目標(biāo)的實(shí)現(xiàn)，我們需要明確清楚每一次迭代需求的目標(biāo)，并且規(guī)劃好下一個(gè)迭代的需求，才能不斷推動(dòng)問(wèn)題解決，得到良性循環(huán)。

5. 總結(jié)

產(chǎn)品需求文檔是任務(wù)迭代流程中的重要內(nèi)容。我們應(yīng)當(dāng)把PRD作為推動(dòng)需求落地上線的指導(dǎo)綱領(lǐng)，提高產(chǎn)研效率的有效工具，將產(chǎn)品思維的思考方式運(yùn)用到需求文檔中。在一次次的需求文檔撰寫中，需要我不斷總結(jié)思考，再運(yùn)用到下一次的實(shí)踐中，反復(fù)思考優(yōu)化自己的方法論。