B端PRD需求規(guī)范
PRD的核心功能是闡述清楚產(chǎn)品經(jīng)理所要實(shí)現(xiàn)的功能,同時(shí)讓參與方的信息同步一致,最終降低溝通成本。
為什么寫(xiě)這篇文章?
- 都說(shuō)需求要有規(guī)范性,那怎樣才算規(guī)范詳細(xì)呢?而市面上又很少有適合的模板。自己將每一個(gè)細(xì)節(jié)點(diǎn)逐一鋪出來(lái)就特別費(fèi)時(shí)間,不詳細(xì)的話(huà)項(xiàng)目成員又看不懂,容易造成理解偏差。
- 產(chǎn)品經(jīng)理需要關(guān)注自己的方案,以及項(xiàng)目團(tuán)隊(duì)成員看完文檔之后的第一時(shí)間理解情況。如果項(xiàng)目成員對(duì)于具體實(shí)現(xiàn)方案有認(rèn)知偏,就等同于給自己挖坑。所以要想項(xiàng)目按預(yù)期發(fā)展,我們就需要建立團(tuán)隊(duì)內(nèi)部規(guī)范,幫助項(xiàng)目成員建立認(rèn)知一致性,
- 自己曾經(jīng)遇到的坑,因?yàn)橛行┮?guī)范性沒(méi)寫(xiě)清楚(比如排序)導(dǎo)致需求拒接。最后花時(shí)間和團(tuán)隊(duì)進(jìn)行討論,最終提煉出一份《B端PRD需求規(guī)范》之后,整個(gè)團(tuán)隊(duì)需求理解、默契度以及工作效率得到了很大的提升。
基于以上,我將自己所整理的方法論分享出來(lái),雖然不一定對(duì),但希望對(duì)一些新人有所幫助。
附上本人理解的《B端PRD需求規(guī)范》。
一、 B端產(chǎn)品需求結(jié)構(gòu)
說(shuō)明:B端的需求設(shè)計(jì)更多的是為“流程”服務(wù),關(guān)注拓展性。而體驗(yàn)和效率不是設(shè)計(jì)的核心。
1. 文件名:項(xiàng)目名稱(chēng)+版本號(hào)。
其中版本格式:主版本號(hào).次版本號(hào).修訂號(hào),例如《提現(xiàn)需求V1.0.0》
2. B端需求文檔要素
1)變更記錄
- 記錄變更歷史,方便追蹤記錄
2)需求背景、需求目標(biāo)、產(chǎn)品價(jià)值
- 強(qiáng)調(diào)需求痛點(diǎn),講清楚為什么是現(xiàn)在要做這個(gè)需求,這個(gè)需求將要達(dá)到什么樣的效果,以及這個(gè)產(chǎn)品帶來(lái)的價(jià)值是什么。大致的成本和收益是怎樣的,講清楚這個(gè)是決定這個(gè)需求是否開(kāi)始做。
3)產(chǎn)品結(jié)構(gòu)圖/ 結(jié)構(gòu)圖 / 大體流程圖
- 闡述這個(gè)B端邏輯時(shí),通過(guò)架構(gòu)圖、大體流程圖,讓大家有個(gè)清晰的概念、方向。
4)名詞解釋
- 涉及到新概念、專(zhuān)業(yè)詞需要提前交代清楚。
5)產(chǎn)品總邏輯圖、細(xì)分業(yè)務(wù)的時(shí)序圖
- 總邏輯圖是解決開(kāi)發(fā)對(duì)核心流程的理解,而時(shí)序圖是為了讓開(kāi)發(fā)更簡(jiǎn)單快速的理解他自己應(yīng)該關(guān)注那個(gè)模塊。
6)頁(yè)面流轉(zhuǎn)交互圖(如涉及到前端頁(yè)面)
7)相關(guān)表結(jié)構(gòu)、相關(guān)接口字段信息
- 需要列舉產(chǎn)品這邊需要的,產(chǎn)品經(jīng)理特別關(guān)注的字段
8)頁(yè)面原型及說(shuō)明
- 需要闡述頁(yè)面的判斷條件
9)Story功能拆分以及全局規(guī)范
- 涉及到通用規(guī)范的,最好統(tǒng)一在一個(gè)地方寫(xiě),不然有些地方寫(xiě)有些地方不寫(xiě)會(huì)對(duì)開(kāi)發(fā)造成困惑以及視覺(jué)疲勞
二、 功能說(shuō)明
1. 產(chǎn)品邏輯如何寫(xiě)?
因?yàn)锽端的邏輯都很長(zhǎng),需要采用“先總后分”模式;
1)總:先梳理整體邏輯圖
- 主邏輯是全鏈路闡述需求如何做的。如果邏輯圖比較長(zhǎng),需要?jiǎng)澐职鍓K,說(shuō)明每個(gè)版塊的核心點(diǎn)。
2)分:再梳理細(xì)分模塊邏輯
① 分類(lèi)判斷:國(guó)家、用戶(hù)等級(jí)
② 權(quán)限判斷:功能權(quán)限、數(shù)據(jù)權(quán)限
2. 接口、表結(jié)構(gòu)如何寫(xiě)?
1)對(duì)接接口的核心要數(shù)
① 通過(guò)時(shí)序圖寫(xiě)清楚接口對(duì)接的邏輯,怎么交互的
② 作為對(duì)接方需要提供什么參數(shù);比如appid
③ 寫(xiě)清楚對(duì)接的注意事項(xiàng),接口鏈接、對(duì)接人。
2)接口輸出的關(guān)鍵要數(shù)
① 請(qǐng)求接口:寫(xiě)清楚請(qǐng)求參數(shù)、應(yīng)答參數(shù)、異步參數(shù)。
② 查詢(xún)接口:請(qǐng)求參數(shù)、應(yīng)答參數(shù)。
③ 接口要具有規(guī)范性,一定要有版本號(hào);
④ 若有性能限制,可以定義查詢(xún)頻率
⑤ 定義接口的關(guān)鍵錯(cuò)誤碼,以及錯(cuò)誤描述
注意:在對(duì)外輸出接口時(shí),特別要注意響應(yīng)碼、錯(cuò)誤碼的規(guī)范性,以及報(bào)錯(cuò)提示的統(tǒng)一性,以及文字表達(dá)的一致性,一旦規(guī)范性前期沒(méi)做好,那么將會(huì)為以后留坑
3)表結(jié)構(gòu)如何寫(xiě)
① 定義表的核心字段值,不用定義所有字段
② 如果是新表,則定義字段取值來(lái)源
3. 頁(yè)面原型說(shuō)明如何寫(xiě)
① 基于當(dāng)前頁(yè)面,寫(xiě)清楚頁(yè)面判斷條件,包括前置條件、后置條件
② 說(shuō)明交互形式,可點(diǎn)擊的按鈕或者文字進(jìn)行注明。例如點(diǎn)擊跳入下一個(gè)頁(yè)面,還是彈窗、Toast,如果是彈窗,注明提示內(nèi)容有哪些。
③ 涉及到excel導(dǎo)入數(shù)據(jù),一般需要有字段校驗(yàn)、遍歷數(shù)據(jù),然后提示錯(cuò)誤的數(shù)據(jù)以及錯(cuò)誤原因。
④ 特殊說(shuō)明情況
⑤ 數(shù)據(jù)排序方式說(shuō)明。例如:根據(jù)時(shí)間的倒序排列,最新數(shù)據(jù)在最上面。這些要規(guī)范清楚,不然技術(shù)就會(huì)按照自己的理解來(lái)寫(xiě);
4. 異常機(jī)制判斷
① 突然沒(méi)有網(wǎng)絡(luò)的情況
② 接口調(diào)用超時(shí)的情況
③ 收不到回調(diào)后的情況
④ 是否有逆向流程情況
5. 定義全局配置參數(shù)
① 下拉選項(xiàng)是否全局配置
② 渠道平臺(tái)是否全局配置
6. 通用組件規(guī)范如何寫(xiě)?
一般涉及到的規(guī)范組件,如果適用于全局,或者可以進(jìn)行單獨(dú)調(diào)用的話(huà),則可以單獨(dú)注明
1)文本輸入框
① 是否允許空格
② 字符長(zhǎng)度限制
③ 輸入前的文本框內(nèi)容
④ 輸入后是否有清除“×”顯示
⑤ 是否有文本格式要求
2)金額輸入框
① 格式校驗(yàn)
② 提現(xiàn)門(mén)檻校驗(yàn)
③ 是否限次,單日/單月
④ 限額判斷:?jiǎn)喂P限額、日限額、年限額等
⑥ 是否調(diào)用九宮格鍵盤(pán)
3)toast /彈窗提示
① 提示的位置是否居中,是否需要浮層
② toast 提示時(shí)間
③ 提示樣式
總結(jié)
因?yàn)楫a(chǎn)品經(jīng)理是必須對(duì)項(xiàng)目結(jié)果負(fù)責(zé),以?xún)r(jià)值結(jié)果為導(dǎo)向的,所以我們?cè)陧?xiàng)目的各個(gè)環(huán)節(jié)都要主動(dòng)思考怎樣讓項(xiàng)目更順暢的完成,以及各個(gè)環(huán)節(jié)自己能做哪些事情。
同時(shí)我也知道每個(gè)產(chǎn)品經(jīng)理應(yīng)該都會(huì)有各自PRD風(fēng)格,有些PRD風(fēng)格是重需求背景目的,重流程,然后輕細(xì)節(jié);有些PRD風(fēng)格是重細(xì)節(jié),輕需求背景目的,這些都不是問(wèn)題,也并沒(méi)有錯(cuò)。
真正的關(guān)鍵點(diǎn)在于我們的合作技術(shù)團(tuán)隊(duì)是怎樣的,因?yàn)橐肟焖偻七M(jìn)項(xiàng)目,最快最好的方式是改變我們自己風(fēng)格,擁抱變化,然后整合融入合作團(tuán)隊(duì)中。
作者:JANMING;公眾號(hào):產(chǎn)品思考隨筆
本文由 @JANMING 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載。
題圖來(lái)自Unsplash,基于CC0協(xié)議。
產(chǎn)品如果懂技術(shù),可以讓研發(fā)參考產(chǎn)品定義的接口,只是參考而已,如果介入的太深,會(huì)干擾研發(fā),技術(shù)范疇是產(chǎn)品主導(dǎo),還是研發(fā)主導(dǎo)
接口、表結(jié)構(gòu)屬于技術(shù)文檔的范疇吧
同感
加1
說(shuō)的沒(méi)錯(cuò),表結(jié)構(gòu) 接口 這是需要技術(shù)方案說(shuō)明的,一個(gè)產(chǎn)品列這些意義不大,還是勸把重心放到業(yè)務(wù)上去吧
有的平臺(tái)需要技術(shù)型產(chǎn)品經(jīng)理,我目前負(fù)責(zé)ERP需要對(duì)接大量的電商平臺(tái),需要產(chǎn)品先做好接口能力調(diào)研,根據(jù)接口設(shè)計(jì)表結(jié)構(gòu),最后形成產(chǎn)品功能。
寫(xiě)得有些籠統(tǒng)啊
干貨,如果有一個(gè)完整的文檔作為例子說(shuō)明,會(huì)更好
這是數(shù)據(jù)產(chǎn)品吧
樓主有無(wú)好用的prd寫(xiě)作工具推薦,方便prd迭代和團(tuán)隊(duì)內(nèi)協(xié)作的?最近為更好地與設(shè)計(jì)和開(kāi)發(fā)協(xié)作絞盡腦汁 ?
現(xiàn)在找到合適的工具了嗎
你好,想問(wèn)一下一般寫(xiě)一份PRD要多久
一看就是具有深厚技術(shù)背景的大神
要做懂技術(shù)的產(chǎn)品啦????
首先要說(shuō)的是PRD很重要,制定PRD的標(biāo)準(zhǔn)格式(需要演進(jìn))很難,堅(jiān)持去撰寫(xiě)高質(zhì)量的PRD就跟難了。
針對(duì)ToB領(lǐng)域產(chǎn)品所解決的不同問(wèn)題,我們框定為基礎(chǔ)軟件產(chǎn)品。文章更像是一個(gè)功能的prd,功能性給出一些小小的建議
1、PRD要寫(xiě)清楚使用的場(chǎng)景,客戶(hù)在什么場(chǎng)景下使用
2、對(duì)于其他功能的影響,關(guān)聯(lián)關(guān)系,是否影響或者依賴(lài)其他組件
3、功能的計(jì)費(fèi)模式
4、功能的業(yè)務(wù)邏輯和交互邏輯
5、競(jìng)品情況
6、驗(yàn)收標(biāo)準(zhǔn)(測(cè)試用例和預(yù)期結(jié)果)
只說(shuō)這么多,還有一些其他的
娛樂(lè)一下:打出prd,提示是“騙人的”
首先要說(shuō),PRD沒(méi)有特別標(biāo)準(zhǔn)的需求規(guī)范,其次所有的prd都是為了方便團(tuán)隊(duì)高效溝通而服務(wù)的,如果是新團(tuán)隊(duì)就得盡量細(xì)一點(diǎn),總得闡述清楚這次大需求所帶來(lái)的核心價(jià)值,背景是什么,以至于開(kāi)發(fā)稀里糊涂的接需求。第三,這肯定不是功能性規(guī)范,但你說(shuō)的計(jì)費(fèi)模式是功能性的點(diǎn),功能性規(guī)范只是占大需求里面的一小部分細(xì)拆分就行。最后,干嘛說(shuō)騙人呢,我又沒(méi)指望把文章分享出去后獲得什么利益價(jià)值,純個(gè)人梳理
您好像誤會(huì)了層住最后一句話(huà)??
哈哈,我打prd也是提示“騙人的”
嗯呢
求份模板mcnkk@qq.com
沒(méi)有完整規(guī)范的pfd,如果你說(shuō)B端互聯(lián)網(wǎng)行業(yè),那這篇文章可以給你帶來(lái)些思路
哈哈
沒(méi)看出跟B端有多大關(guān)系
so 你認(rèn)為b端和c端prd的區(qū)別是什么,C端更重交互,b端重邏輯,重底層實(shí)現(xiàn)方式
需求文檔要深入到設(shè)計(jì)端?
是的,必須清楚詳細(xì)
可以關(guān)注個(gè)人公眾號(hào),交流心得:產(chǎn)品思考隨筆