講到PRD，有兩種不同的意見：有的人認(rèn)為PRD十分關(guān)鍵，能夠體現(xiàn)出產(chǎn)品方案、設(shè)計思路；而有的人則認(rèn)為PRD無用，價值小。對此筆者認(rèn)為：我們應(yīng)該結(jié)合公司、業(yè)務(wù)、產(chǎn)品等去自定義PRD，發(fā)揮它的最大價值。

一、寫作緣由

PRD、原型可以說是產(chǎn)品經(jīng)理工作中最常見、最高頻的交付物了。但是最近與許多同事的交流中卻發(fā)現(xiàn)，很多產(chǎn)品人員、開發(fā)人員都對需求文檔抱有一種輕視、鄙夷的態(tài)度，產(chǎn)品經(jīng)理對于需求文檔敷衍了事，開發(fā)更是看都不看。加之一些不知從何處來的言論鼓吹，“一個好的產(chǎn)品經(jīng)理絕對不等同于寫文檔、畫原型”“寫文檔就是搬磚”，PRD更加成為了一個尷尬的存在。

然而事實并非如此。

對于產(chǎn)品經(jīng)理個人而言，需求文檔是產(chǎn)品方案、設(shè)計思路、實現(xiàn)思路的綜合體現(xiàn)和結(jié)果輸出，不管是使用可交互原型、手繪原型還是文字描述，產(chǎn)品經(jīng)理總是需要這樣一個載體來表達(dá)自己的思維結(jié)晶。

對于團(tuán)隊配合而言，隨著分工越來越細(xì)化以及員工流動性的增加，需求文檔轉(zhuǎn)而擔(dān)負(fù)起了聯(lián)絡(luò)產(chǎn)品、開發(fā)、測試以及新老員工的溝通工具。

對于公司或者業(yè)務(wù)這個抽象實體而言，需求文檔是其業(yè)務(wù)發(fā)展、變革的沉淀……

上面講到需求文檔存在的價值，不過我們也應(yīng)該看到，圍繞著目標(biāo)或者第一性，需求文檔可能只是交付產(chǎn)品或用戶價值的工具，我們確實應(yīng)當(dāng)結(jié)合公司、業(yè)務(wù)、產(chǎn)品的具體情況去自定義“需求文檔”，而不是直接生搬硬套。

下文所述，是基于我個人不到一年的產(chǎn)品工作以及PRD寫作經(jīng)驗。我相信隨著經(jīng)驗的不斷積累，還會不斷生發(fā)出新的認(rèn)知來，屆時通過比較，我也能感知到自己的成長，在這里也歡迎大家與我共同探討。

二、重新定義需求文檔

1. 面向人群與寫作目標(biāo)

需求文檔的使用人群主要包括產(chǎn)品經(jīng)理、開發(fā)、測試。對于產(chǎn)品產(chǎn)品經(jīng)理而言，使用并撰寫需求文檔應(yīng)當(dāng)可以幫助：

1. 細(xì)化產(chǎn)品方案
2. 輸出文字版的產(chǎn)品實現(xiàn)方案
3. 幫助整理思路、發(fā)現(xiàn)不足、促進(jìn)溝通
4. 用于對內(nèi)對外的溝通展示

對于開發(fā)和測試而言，需求文檔應(yīng)當(dāng)可以幫助其了解業(yè)務(wù)、功能、成功標(biāo)準(zhǔn)，從而更好的進(jìn)行開發(fā)和測試。

因而寫作PRD的過程，可以視為一個梳理產(chǎn)品思路、細(xì)化產(chǎn)品方案、細(xì)化技術(shù)方案的迭代的過程，而最終的PRD可以作為產(chǎn)品的藍(lán)圖、實施方案以及溝通工具。

2. 寫作思維

下面總結(jié)了在PRD寫作中我認(rèn)為比較重要的幾種思維模型：

（1）目標(biāo)思維

首先最頂層的思維應(yīng)當(dāng)是“目標(biāo)思維”，通過思考這些問題找到寫作目標(biāo)：這份文檔給誰看？他們想看哪些信息？他們會以何種方式看？我應(yīng)該以什么樣的形式、內(nèi)容來寫才能更好的幫助讀者？

我寫作的常見目標(biāo)可能是這樣的：

1. 通過需求文檔梳理整個產(chǎn)品設(shè)計思路，并簡要的傳達(dá)給項目成員。
2. 通過需求文檔，將產(chǎn)品方案細(xì)化為文字版的解決方案，這個文字版方案應(yīng)當(dāng)涵蓋所有開發(fā)細(xì)節(jié)，以便開發(fā)可以快速展開工作而無需多次找我溝通確認(rèn)。
3. 需求文檔應(yīng)該有良好的組織結(jié)構(gòu)，便于以后加入新的文檔。
4. 跟隨敏捷與迭代的原則，需求文檔也應(yīng)是敏捷并且不斷迭代的。
5. 需求文檔應(yīng)當(dāng)及時記錄和告知變更。

（2）基本的邏輯思維

產(chǎn)品文檔的各個組成模塊，應(yīng)當(dāng)具備合理的邏輯關(guān)系，而不是雜亂地鋪在文檔里。

例如，可以首先描寫和論證用戶需求；然后簡要敘述為了解決需求，選擇了怎樣的產(chǎn)品方案或業(yè)務(wù)模型；隨后列出為了實現(xiàn)業(yè)務(wù)模型需要鋪設(shè)的產(chǎn)品功能點；進(jìn)一步的，通過功能流程圖，將功能點進(jìn)一步細(xì)化為一個個頁面路徑和頁面元素；最后還要有對于頁面元素的詳細(xì)描述。

可以看到，這樣的需求文檔是邏輯清晰、有說服力的，出現(xiàn)問題也很容易定位到具體環(huán)節(jié)。

（3）微言大義

對語言文字有所敬畏，語言文字作為溝通工具，是非常容易造成歧義的，要想準(zhǔn)確地將自己的思路想法傳達(dá)給別人是一件非常難的事情。需求文檔在文字表達(dá)上應(yīng)該力求簡潔、清晰、無歧義，多試著以讀者的角度去審視自己的文字表達(dá)，相信你會發(fā)現(xiàn)很多問題。

（4）產(chǎn)品思維

我個人將PRD的寫作過程看作對產(chǎn)品思路的梳理和記錄。這個產(chǎn)品思路或許并沒有唯一正確答案，我個人的思路可以概括為：

（1）自上而下，基本遵循目標(biāo)-概要性產(chǎn)品解決方案–詳細(xì)解決方案（對于常見的2C互聯(lián)網(wǎng)產(chǎn)品，這個詳細(xì)解決方案可能包括從功能結(jié)構(gòu)到頁面視覺的一系列工作）

（2）由內(nèi)而外，主要用于對現(xiàn)有功能的優(yōu)化，基本遵循可用-易用-好用的迭代原則。

因而實際工作中，我的寫作思路一般也遵循上述原則，對于新功能通常按照目標(biāo)-概要方案-詳細(xì)方案去寫；對于功能優(yōu)化，結(jié)合現(xiàn)有使用場景和痛點，去提出優(yōu)化方案。

（5）技術(shù)思維

產(chǎn)品思維比較偏重于分析決策和提出面向用戶或商業(yè)的解決方案，而技術(shù)主要考慮如何去實現(xiàn)這個解決方案，以及這個解決方案對既有技術(shù)框架的影響有多大。

實際上，一個好的解決方案絕不僅僅只考慮用戶或商業(yè)，技術(shù)實現(xiàn)也是必須考量的要素。技術(shù)將解決方案落實并決定項目的資源和成本，技術(shù)方案的好壞也會直接決定用戶的使用體驗，甚至有些時候技術(shù)實現(xiàn)可以驅(qū)動商業(yè)和用戶需求的變革。

產(chǎn)品經(jīng)理缺失技術(shù)思維，就會很容易將自己沒完成的任務(wù)無意識的甩鍋給開發(fā)，實際工作中開發(fā)經(jīng)常跑來找產(chǎn)品溝通需求細(xì)節(jié)也是源于此。

以一個簡單的例子來說明：

技術(shù)層面，用戶在登錄注冊后，可以本地緩存賬號信息，從而下次訪問應(yīng)用時無需手動進(jìn)行登錄操作。如果產(chǎn)品經(jīng)理不懂這個緩存技術(shù)，在PRD中就會缺失相應(yīng)描述，開發(fā)人員無法明確是否要做這樣一個自動登錄的功能，就只能拍腦袋決定了。

再舉一個登錄注冊相關(guān)的例子：

網(wǎng)站登錄注冊需要考慮是否限制用戶多賬號登錄的問題，網(wǎng)站運行在瀏覽器上，瀏覽器在緩存用戶信息的時候是按域存儲的；如果網(wǎng)站允許多賬號登錄，在不加以設(shè)計的情況下，這些同時登錄的賬號會出現(xiàn)數(shù)據(jù)混亂的情況。因而必須在產(chǎn)品設(shè)計之初就從需求上定義是否需要多賬號登錄，進(jìn)而才能由開發(fā)給出一個完善的多賬號數(shù)據(jù)存儲或請求方案。

現(xiàn)實工作中，產(chǎn)品經(jīng)理可能無法達(dá)到技術(shù)人員的水平，解決之道可以是自己多學(xué)習(xí)、和技術(shù)多去溝通產(chǎn)品方案；還可以通過制定設(shè)計&開發(fā)規(guī)范，讓產(chǎn)品、設(shè)計、技術(shù)可以協(xié)同工作(類似于ant design，定義了一套常用的設(shè)計開發(fā)規(guī)范，產(chǎn)品設(shè)計和開發(fā)都可以基于共同規(guī)范去開展，而不用重復(fù)造輪子)。

在我最初的認(rèn)知中，產(chǎn)品經(jīng)理應(yīng)該盡量去定義一套足夠詳盡的解決方案，而開發(fā)人員、設(shè)計人員只需根據(jù)PRD去進(jìn)行自己的工作。

在對設(shè)計、開發(fā)有了一定的了解后，我認(rèn)為，單靠產(chǎn)品經(jīng)理一人之力去輸出詳盡的解決方案是不太可能的（除非產(chǎn)品經(jīng)理既懂得產(chǎn)品設(shè)計、又懂得技術(shù)、還懂得交互設(shè)計和視覺設(shè)計等）。一個真正優(yōu)秀的產(chǎn)品方案應(yīng)該由產(chǎn)品人員、開發(fā)人員、設(shè)計人員、測試人員通力合作，這些人員不是上下游關(guān)系、規(guī)劃與執(zhí)行關(guān)系，而是一種能力互補的關(guān)系，這些人員的才能共同造就一個優(yōu)秀的產(chǎn)品。

另一方面，在不斷的配合中，產(chǎn)品、設(shè)計、開發(fā)應(yīng)該嘗試去將常用功能封裝成一個設(shè)計&開發(fā)框架，在以后的工作中可以直接沿用或改動現(xiàn)有框架，提高工作與溝通效率。

三、PRD結(jié)構(gòu)

下面簡要介紹我個人常常使用的PRD的基本結(jié)構(gòu)：

1. 需求

也是產(chǎn)品方案要達(dá)到的目標(biāo)，需求可能是用戶需求（即以用戶價值為導(dǎo)向），也可能是業(yè)務(wù)需求（即以商業(yè)價值為導(dǎo)向），后面的產(chǎn)品方案細(xì)節(jié)，最終都是為了達(dá)到這一目標(biāo)。

在PRD中闡述項目的目標(biāo)，有助于激發(fā)團(tuán)隊成員的動機(jī)，從而在目標(biāo)上達(dá)成一致。

2. 設(shè)計模型

面向需求或目標(biāo)，提出解決方案或設(shè)計模型，可以以泳道圖、流程圖等可視化的方式或者文字表達(dá)的方式描述主要的業(yè)務(wù)邏輯、產(chǎn)品架構(gòu)。

3. 功能列表

根據(jù)設(shè)計模型，將用戶需求、業(yè)務(wù)需求轉(zhuǎn)換為大大小小的產(chǎn)品功能模塊或非功能性要求，闡述這些模塊間的業(yè)務(wù)關(guān)聯(lián)、數(shù)據(jù)關(guān)聯(lián)，對于功能進(jìn)行優(yōu)先級分析和版本規(guī)劃。

4. 功能流程

針對每一個功能模塊，圍繞著功能目標(biāo)，設(shè)計功能流程。如圍繞著用戶賬號登錄這一目標(biāo)，設(shè)計登錄注冊的流程。這里要注意：

根據(jù)功能模塊的特性，使用不同種類的流程圖，比如泳道圖、時序圖、狀態(tài)圖。

突出主流程、弱化分支流程、以文字表達(dá)異常流程，將三者區(qū)隔開來。

（產(chǎn)品設(shè)計應(yīng)當(dāng)優(yōu)先考慮引導(dǎo)用戶走向主流程，次之考慮對于用戶的分支行為作出一定約束，最后還要考慮整個環(huán)境系統(tǒng)可能出現(xiàn)的異常。對于用戶、設(shè)計人員、開發(fā)人員而言，這三者的作用和優(yōu)先級都是不同的）。

5. 頁面設(shè)計與頁面元素

頁面設(shè)計是對功能流程的進(jìn)一步細(xì)化，許多的頁面元素串聯(lián)起來，引導(dǎo)用戶走完整個功能流程并達(dá)成目標(biāo)。根據(jù)功能流程圖，考慮以最少的頁面和最清晰有效的頁面布局實現(xiàn)功能。

6. 頁面詳細(xì)說明

對于頁面之間的邏輯和每一個頁面元素進(jìn)行必要的說明。

頁面元素包括信息和控件等，在說明信息時，需要對信息的展示效果、信息來源、信息的計算規(guī)則、信息的刷新規(guī)則等進(jìn)行說明；對于控件，以輸入性控件為例，對控件類型、控件樣式、控件交互、輸入限制、輸入校驗等屬性進(jìn)行說明。

個人覺得，頁面詳細(xì)說明是開發(fā)和測試最終要參考的部分，也是產(chǎn)品經(jīng)理最容易有遺漏的地方，因為這里會涉及很多細(xì)節(jié)；對于這里的寫作也是爭議最多的，是否要寫得足夠詳盡？我只能說，對此要具體情況具體分析，如果團(tuán)隊已經(jīng)有了成熟的配合模式和規(guī)范，這里自然可以簡化；但是我想每個產(chǎn)品經(jīng)理都應(yīng)該具備寫一份詳盡文檔的能力。

那么怎樣才能避免遺漏細(xì)節(jié)呢？

我個人覺得，還是要有技術(shù)思維。換位思考如果你是開發(fā)，你需要知道哪些必要因素才能開工。

對此，個人認(rèn)為最快的學(xué)習(xí)途徑不是看別人怎么寫需求文檔，而是讀一些技術(shù)的書，真正明白當(dāng)一個開發(fā)在寫代碼時是在做什么。

以網(wǎng)頁表單為例，前端需要通過html和CSS來定義表單的結(jié)構(gòu)和樣式，通過javascript執(zhí)行一些輸入限制和校驗，通過AJAX和服務(wù)端通信，發(fā)送POST請求將用戶輸入的一些字段信息上報；服務(wù)端需要編寫程序?qū)φ埱筮M(jìn)行處理并在處理完成后發(fā)送響應(yīng)給前端。

因而從前端的角度出發(fā)，PRD里應(yīng)當(dāng)包含頁面控件樣式的描述、控件交互的描述、輸入限制的描述、數(shù)據(jù)上報的描述等；從后端的角度出發(fā)，PRD里應(yīng)該包含有數(shù)據(jù)上報的描述。

7. 全局說明

一些各個頁面都有的功能點、交互模式、設(shè)計樣式，或者一些通用的異常控制，可以放在全局說明里。

四、總結(jié)

在PM的日常工作中，對于PRD有了一些認(rèn)知上的升級，在這里進(jìn)行了初步總結(jié)。主要講述了：

（1）PRD寫作的目的和價值

（2）PRD寫作中應(yīng)該具備的思維模式

（3）PRD的常見結(jié)構(gòu)

此文雖以PRD為主要話題，但實質(zhì)上重在對產(chǎn)品經(jīng)理邏輯與理性思維的體察。誠如很多大佬說的，產(chǎn)品經(jīng)理需要有一秒內(nèi)變?yōu)榘装V的能力；但個人認(rèn)為，除了直覺與感性，良好的邏輯思維與理性亦是產(chǎn)品人必不可少的。

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

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