你是否有過(guò)因?yàn)镻RD文檔寫(xiě)得不夠好，而被開(kāi)發(fā)懟的經(jīng)歷呢？這里一份詳細(xì)的PRD文檔寫(xiě)作說(shuō)明，get這份說(shuō)明，你的開(kāi)發(fā)過(guò)程將會(huì)很順利。接下來(lái)，就讓筆者為我們講述如何寫(xiě)好一份PRD文檔吧。

產(chǎn)品和開(kāi)發(fā)之間的矛盾人盡皆知，其中一個(gè)核心問(wèn)題就是：PRD寫(xiě)得不夠好，于是開(kāi)發(fā)過(guò)程非常不順，導(dǎo)致產(chǎn)品和開(kāi)發(fā)不斷撕逼。

當(dāng)時(shí)剛做產(chǎn)品經(jīng)理時(shí)，也為此頗為煩惱。雖然大學(xué)時(shí)學(xué)過(guò)C++和Java，但對(duì)技術(shù)的理解有限，當(dāng)時(shí)還難以寫(xiě)出合格的PRD。

緊接著，我就和很多產(chǎn)品新人一樣——到網(wǎng)上到處搜PRD該如何寫(xiě)，搜了一堆模板、一堆文章。

但緊接著我們會(huì)發(fā)現(xiàn)：并沒(méi)有人給出一個(gè)足夠?qū)嵱玫腜RD詳細(xì)說(shuō)明，讓我們能直接在工作中應(yīng)用，并能保證開(kāi)發(fā)過(guò)程順暢。

到了現(xiàn)在，我終于能給出一份比較實(shí)用的PRD詳細(xì)說(shuō)明了。果然打是親，罵是愛(ài)，感謝那些曾經(jīng)懟過(guò)自己的開(kāi)發(fā)們。

有了這份PRD文檔寫(xiě)作詳細(xì)說(shuō)明后，有什么效果？

• 一位開(kāi)發(fā)評(píng)價(jià)：按照你上次的PRD文檔，以后就不是開(kāi)發(fā)懟你，而是你懟開(kāi)發(fā)了。
• 一位測(cè)試評(píng)價(jià)：我感覺(jué)PRD文檔寫(xiě)成這樣，以后就不用需求講解了（“需求講解”特指開(kāi)發(fā)之前的講解，便于開(kāi)發(fā)熟悉需求）。
• 一位面試官評(píng)價(jià)：你是我面試過(guò)的產(chǎn)品經(jīng)理中，一個(gè)難得的合格的產(chǎn)品經(jīng)理，你要感謝那些懟過(guò)你的開(kāi)發(fā)們。

確實(shí)如此，只要每次都按照這份詳細(xì)說(shuō)明來(lái)寫(xiě)PRD，開(kāi)發(fā)過(guò)程就很順暢。而如果有不順暢的地方，往往是忽略了詳細(xì)說(shuō)明中的部分內(nèi)容。

那么這份詳細(xì)說(shuō)明是怎么來(lái)的？

很簡(jiǎn)單：不斷地被開(kāi)發(fā)懟。

在被開(kāi)發(fā)懟了將近1年后，在接觸了6個(gè)開(kāi)發(fā)團(tuán)隊(duì)后，我收集了足夠多的開(kāi)發(fā)懟我的注意點(diǎn)，以及過(guò)程中的不斷完善，梳理出了這份詳細(xì)說(shuō)明。從此之后，一切就變得很順暢。

下面就來(lái)具體講解：

一、基本注意點(diǎn)

1. 不同團(tuán)隊(duì)需要不同的PRD

PRD是給開(kāi)發(fā)、測(cè)試看的，本質(zhì)上也是一個(gè)產(chǎn)品，產(chǎn)品的用戶就是開(kāi)發(fā)和測(cè)試。

因此，一個(gè)最基本的原則是：根據(jù)不同團(tuán)隊(duì)的具體需求，給出不同的PRD。

是的，PRD也不是一招鮮吃遍天。當(dāng)你接觸的團(tuán)隊(duì)足夠多，你會(huì)發(fā)現(xiàn)不同團(tuán)隊(duì)對(duì)PRD的要求有很大差異：

• 有的團(tuán)隊(duì)需要非常詳細(xì)的說(shuō)明——一般是比較成熟穩(wěn)定的開(kāi)發(fā)團(tuán)隊(duì)。
• 有的團(tuán)隊(duì)只需要原型圖足夠準(zhǔn)確，需求描述部分很少——這就需要在開(kāi)發(fā)過(guò)程中不斷溝通。
• 有的團(tuán)隊(duì)注重你對(duì)需求的深入理解，而不是PRD本身的描述是否足夠詳細(xì)——一般是創(chuàng)業(yè)團(tuán)隊(duì)。

所以，PRD到底要寫(xiě)到什么程度，最基本的原則就是：看團(tuán)隊(duì)的具體需求。

2. 一些注意點(diǎn)

另外，還有一些注意點(diǎn)：

• 這份PRD詳細(xì)說(shuō)明主要針對(duì)業(yè)務(wù)類(lèi)產(chǎn)品。因?yàn)檫@份說(shuō)明來(lái)自實(shí)際工作經(jīng)驗(yàn)，筆者沒(méi)做過(guò)AI、大數(shù)據(jù)、區(qū)塊鏈等高新技術(shù)產(chǎn)品，更多的是業(yè)務(wù)類(lèi)產(chǎn)品。
• 這份PRD詳細(xì)說(shuō)明非常詳細(xì)，但不代表你的PRD就要這么詳細(xì)。如上面所說(shuō)，不同團(tuán)隊(duì)需要不同的PRD。但你的PRD可以比較簡(jiǎn)略，所以，對(duì)功能的思考上要考慮到這份詳細(xì)說(shuō)明中的內(nèi)容，以避免開(kāi)發(fā)過(guò)程的不順暢。
• 這份PRD詳細(xì)說(shuō)明只針對(duì)功能的技術(shù)可行性，不針對(duì)需求的合理性——這是PRD的核心目的，需求的合理性可在其他階段考慮。

二、PRD文檔寫(xiě)作詳細(xì)說(shuō)明

先說(shuō)明一下：一些基本的PRD模塊我們就不說(shuō)了——比如：「歷史版本修改記錄」、「需求背景說(shuō)明」這些人盡皆知的部分。

我們只講PRD最核心的部分——對(duì)各個(gè)功能應(yīng)該如何描述才足夠準(zhǔn)確、詳細(xì)。

至于其他模塊，我們?cè)谖哪┓乓粋€(gè)鏈接，大家自行下載即可，看一眼就懂了。

1. 取值規(guī)則

取值規(guī)則：產(chǎn)品前端/客戶端的字段取的是對(duì)應(yīng)的什么字段。

我們以「人人都是產(chǎn)品經(jīng)理」APP首頁(yè)為例：

比如：下圖的banner部分，取值規(guī)則就是這些banner的圖和標(biāo)題取自哪里？

一般來(lái)說(shuō)，banner部分的圖和標(biāo)題都在后臺(tái)配置，因此你就可以寫(xiě)成：

banner圖片：取值后臺(tái)字段XX。

banner標(biāo)題：取值后臺(tái)字段YY。

PS：建議寫(xiě)出后臺(tái)的具體字段，否則時(shí)間長(zhǎng)了，字段就亂了，下次你想知道前后端的對(duì)應(yīng)關(guān)系時(shí)，還得找開(kāi)發(fā)查半天。

當(dāng)然 ，取值的來(lái)源可以不是后臺(tái)某字段，比如：

• 前端用戶操作的數(shù)據(jù)——比如用戶點(diǎn)贊次數(shù)。
• 某幾個(gè)字段綜合計(jì)算后的結(jié)果。
• 符合特定條件的某字段——比如取值后臺(tái)字段 [狀態(tài)] 的值為”顯示”的字段XX。
• ……

這些在實(shí)際工作中會(huì)有變化，核心是得想清楚前端/客戶端的字段，其取值的對(duì)應(yīng)字段是什么。

2. 顯示規(guī)則

顯示規(guī)則：與顯示相關(guān)的規(guī)則。

以下圖banner部分為例，顯示規(guī)則要考慮：

• 取值數(shù)據(jù)為空時(shí)如何處理：例如banner的圖片對(duì)應(yīng)的后臺(tái)字段為空，此時(shí)如何顯示？
• 顯示數(shù)量：banner的圖片要顯示幾張？超出數(shù)量限制時(shí)如何處理？banner的標(biāo)題要顯示多少字？超出數(shù)量限制時(shí)如何處理？
• 顯示格式：比如標(biāo)題是靠左還是居中還是靠右？如果是數(shù)字，比如時(shí)間，是要顯示成12小時(shí)制還是24小時(shí)制？
• 排序規(guī)則：banner的圖片顯示的先后順序如何排序？是按照后臺(tái)的某個(gè)字段排序？還是按照其他規(guī)則排序？

3. 交互規(guī)則

交互規(guī)則：將對(duì)應(yīng)的交互設(shè)計(jì)描述出來(lái)。

比如下圖的banner部分，至少要考慮：

• 自動(dòng)輪播的時(shí)間間隔。
• 左右滑動(dòng)時(shí)的交互效果。
• 點(diǎn)擊后的交互效果——比如點(diǎn)擊后進(jìn)入XX頁(yè)面。

4. 默認(rèn)規(guī)則

對(duì)一些默認(rèn)情況的說(shuō)明。

• 默認(rèn)的取值規(guī)則：默認(rèn)取值xx，當(dāng)xx為空則取值yy。
• 默認(rèn)的顯示規(guī)則：默認(rèn)顯示xx，當(dāng)….則顯示yy。
• 默認(rèn)的交互規(guī)則：導(dǎo)航欄，默認(rèn)選中某個(gè)標(biāo)簽——比如上圖的首頁(yè)部分，底部TAB默認(rèn)選中的是「閱讀」，頂部導(dǎo)航欄默認(rèn)選中的是「文章」。
• 其他的默認(rèn)情況說(shuō)明。

5. 邊界情況

對(duì)各種邊界情況的考量，防止出現(xiàn)異常。

比如：

取值規(guī)則：被取值字段為空時(shí)如何取值？

顯示規(guī)則：

當(dāng)沒(méi)有內(nèi)容時(shí)，如何處理？——當(dāng)前頁(yè)面沒(méi)有任何內(nèi)容時(shí)顯示什么頁(yè)面？當(dāng)前字段沒(méi)有任何內(nèi)容時(shí)顯示什么內(nèi)容？

當(dāng)數(shù)量巨大時(shí)，如何處理？——列表顯示數(shù)量過(guò)大時(shí)可能影響性能，要與開(kāi)發(fā)協(xié)商處理措施。

時(shí)間顯示格式——如顯示時(shí)間區(qū)間格式：若開(kāi)始時(shí)間和結(jié)束時(shí)間為同一天，那么，是否只顯示一個(gè)時(shí)間即可？

交互規(guī)則：

• 操作次數(shù)限制：是否要限制？如要限制，限制多少次？達(dá)到上限后如何提醒？比如，輸入密碼錯(cuò)誤達(dá)到上限后，就要凍結(jié)一段時(shí)間。
• 輸入內(nèi)容限制：是否要限制？如要限制，限制多少次？達(dá)到上限后如何提醒？比如，輸入手機(jī)號(hào)碼限制11位數(shù)字，超過(guò)后如何處理？
• 返回按鈕：若上一個(gè)頁(yè)面為空，則返回哪里？
• 提示：提示多久消失？比如toast提示，是否3s后消失？
• 編輯：是否可編輯？涉及到編輯時(shí)，要描述清楚編輯成功后的交互。比如保存后是否要刷新頁(yè)面。
• ……

異常情況：出現(xiàn)異常時(shí)如何處理？

1. 當(dāng)沒(méi)有網(wǎng)絡(luò)/網(wǎng)絡(luò)異常時(shí)，顯示什么？
2. 當(dāng)服務(wù)器忙時(shí)，顯示什么？
3. 當(dāng)產(chǎn)品下架/頁(yè)面被刪除等時(shí)，顯示什么？
4. 被惡意評(píng)論、惡意刷分等時(shí)，顯示什么？

幾個(gè)不同狀態(tài)的綜合考慮：

• 登錄/未登錄：例如，未登錄狀態(tài)下不能點(diǎn)贊。
• 有權(quán)限/無(wú)權(quán)限：例如，無(wú)權(quán)限時(shí)是否顯示？交互如何？
• ……

版本兼容考量——如果是APP，不同版本之間的兼容需要考慮，web端一般不需要考慮這塊。

以上是PRD要考慮的核心部分，是站在開(kāi)發(fā)角度的考量。

當(dāng)然，由于例子有限，以上內(nèi)容并不完整（如下方列舉了一部分），所以整理一個(gè)思維導(dǎo)圖下載鏈接，大家參照即可。

• 比如：APP端、小程序端、web端各有不同，各自有各自的注意點(diǎn)。
• 比如：流程上的注意點(diǎn)，如需為設(shè)計(jì)考慮，可以標(biāo)注清楚這個(gè)版本涉及的更改內(nèi)容，這樣設(shè)計(jì)就能更快地知道自己該設(shè)計(jì)哪些地方；還應(yīng)該給出可復(fù)制的文案，否則設(shè)計(jì)得自己輸入對(duì)應(yīng)內(nèi)容等等。
• 比如：與線上功能一致的，盡量沿用線上已有的功能，這樣便于開(kāi)發(fā)，可降低開(kāi)發(fā)成本。此時(shí)最好還說(shuō)清楚線上功能所在的位置，便于開(kāi)發(fā)找到對(duì)應(yīng)的功能。
• 對(duì)于關(guān)聯(lián)性較強(qiáng)的數(shù)據(jù)，開(kāi)發(fā)難度往往更大，此時(shí)應(yīng)更多地考慮性能。
• 如果更改頻率低，寫(xiě)死比在后臺(tái)添加更好。
• 可以把通用的功能全部收集起來(lái)放在一個(gè)文檔中，這樣后續(xù)用到對(duì)應(yīng)功能時(shí)，可以直接給出鏈接，讓開(kāi)發(fā)看之前的文檔描述即可。
• ……

PRD文檔寫(xiě)作詳細(xì)說(shuō)明、PRD模板：

鏈接：https://pan.baidu.com/s/1tVhJ6A6On3TFE0lGHO3-TQ

提取碼：smu7

#專(zhuān)欄作家#

萬(wàn)能的船長(zhǎng)，公眾號(hào)：PMWang，人人都是產(chǎn)品經(jīng)理專(zhuān)欄作家。一個(gè)做產(chǎn)品的人。

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

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