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

1.需求文檔的作用

1.1 對設計任務管理的作用

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

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

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

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

2. 如何寫好需求文檔

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

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

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

3. 需求文檔各模塊要點

3.1 需求背景&歷史原因

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

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

3.2 需求分析

來源于用戶的需求才是最真實的需求，有些功能點無法滿足用戶需求，但是只有在具體業(yè)務場景下才能體現(xiàn)，通過對用戶場景的分析，挖掘出當前要解決的問題以及后續(xù)衍生出的問題。

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

3.3 競品分析

競品分析可分為兩部分：

直接競品分析：

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

非標競品分析：

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

3.4 問題分析與方案抉擇

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

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

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

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

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

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

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

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

3.6 數(shù)據(jù)埋點

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

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

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

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

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

1）用戶思維：站在用戶視角，提升用戶體驗

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

2）結(jié)構化思維：結(jié)論先行，突出重點

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

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

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

閉環(huán)思維是指我們在做一件事情時，要做到有始有終。不是僅僅把事情做了，而是要保證事情做了以后，是能夠解決問題，或者有相應的見效或進展的。

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

5. 總結(jié)

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