中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

PRD的核心功能是闡述清楚產(chǎn)品經(jīng)理所要實現(xiàn)的功能，同時讓參與方的信息同步一致，最終降低溝通成本。

為什么寫這篇文章？

1. 都說需求要有規(guī)范性，那怎樣才算規(guī)范詳細呢？而市面上又很少有適合的模板。自己將每一個細節(jié)點逐一鋪出來就特別費時間，不詳細的話項目成員又看不懂，容易造成理解偏差。
2. 產(chǎn)品經(jīng)理需要關注自己的方案，以及項目團隊成員看完文檔之后的第一時間理解情況。如果項目成員對于具體實現(xiàn)方案有認知偏，就等同于給自己挖坑。所以要想項目按預期發(fā)展，我們就需要建立團隊內(nèi)部規(guī)范，幫助項目成員建立認知一致性，
3. 自己曾經(jīng)遇到的坑，因為有些規(guī)范性沒寫清楚（比如排序）導致需求拒接。最后花時間和團隊進行討論，最終提煉出一份《B端PRD需求規(guī)范》之后，整個團隊需求理解、默契度以及工作效率得到了很大的提升。

基于以上，我將自己所整理的方法論分享出來，雖然不一定對，但希望對一些新人有所幫助。

附上本人理解的《B端PRD需求規(guī)范》。

一、 B端產(chǎn)品需求結構

說明：B端的需求設計更多的是為“流程”服務，關注拓展性。而體驗和效率不是設計的核心。

1. 文件名：項目名稱+版本號。

其中版本格式：主版本號.次版本號.修訂號，例如《提現(xiàn)需求V1.0.0》

2. B端需求文檔要素

1）變更記錄

• 記錄變更歷史，方便追蹤記錄

2）需求背景、需求目標、產(chǎn)品價值

• 強調(diào)需求痛點，講清楚為什么是現(xiàn)在要做這個需求，這個需求將要達到什么樣的效果，以及這個產(chǎn)品帶來的價值是什么。大致的成本和收益是怎樣的，講清楚這個是決定這個需求是否開始做。

3）產(chǎn)品結構圖/ 結構圖 / 大體流程圖

• 闡述這個B端邏輯時，通過架構圖、大體流程圖，讓大家有個清晰的概念、方向。

4）名詞解釋

• 涉及到新概念、專業(yè)詞需要提前交代清楚。

5）產(chǎn)品總邏輯圖、細分業(yè)務的時序圖

• 總邏輯圖是解決開發(fā)對核心流程的理解，而時序圖是為了讓開發(fā)更簡單快速的理解他自己應該關注那個模塊。

6）頁面流轉(zhuǎn)交互圖（如涉及到前端頁面）

7）相關表結構、相關接口字段信息

• 需要列舉產(chǎn)品這邊需要的,產(chǎn)品經(jīng)理特別關注的字段

8）頁面原型及說明

• 需要闡述頁面的判斷條件

9）Story功能拆分以及全局規(guī)范

• 涉及到通用規(guī)范的，最好統(tǒng)一在一個地方寫，不然有些地方寫有些地方不寫會對開發(fā)造成困惑以及視覺疲勞

二、 功能說明

1. 產(chǎn)品邏輯如何寫？

因為B端的邏輯都很長，需要采用“先總后分”模式；

1）總：先梳理整體邏輯圖

• 主邏輯是全鏈路闡述需求如何做的。如果邏輯圖比較長，需要劃分板塊，說明每個版塊的核心點。

2）分：再梳理細分模塊邏輯

① 分類判斷：國家、用戶等級

② 權限判斷：功能權限、數(shù)據(jù)權限

2. 接口、表結構如何寫？

1）對接接口的核心要數(shù)

① 通過時序圖寫清楚接口對接的邏輯，怎么交互的

② 作為對接方需要提供什么參數(shù)；比如appid

③ 寫清楚對接的注意事項，接口鏈接、對接人。

2）接口輸出的關鍵要數(shù)

① 請求接口：寫清楚請求參數(shù)、應答參數(shù)、異步參數(shù)。

② 查詢接口：請求參數(shù)、應答參數(shù)。

③ 接口要具有規(guī)范性，一定要有版本號；

④ 若有性能限制，可以定義查詢頻率

⑤ 定義接口的關鍵錯誤碼，以及錯誤描述

注意：在對外輸出接口時，特別要注意響應碼、錯誤碼的規(guī)范性，以及報錯提示的統(tǒng)一性，以及文字表達的一致性，一旦規(guī)范性前期沒做好，那么將會為以后留坑

3）表結構如何寫

① 定義表的核心字段值，不用定義所有字段

② 如果是新表，則定義字段取值來源

3. 頁面原型說明如何寫

① 基于當前頁面，寫清楚頁面判斷條件，包括前置條件、后置條件

② 說明交互形式，可點擊的按鈕或者文字進行注明。例如點擊跳入下一個頁面，還是彈窗、Toast，如果是彈窗，注明提示內(nèi)容有哪些。

③ 涉及到excel導入數(shù)據(jù)，一般需要有字段校驗、遍歷數(shù)據(jù)，然后提示錯誤的數(shù)據(jù)以及錯誤原因。

④ 特殊說明情況

⑤ 數(shù)據(jù)排序方式說明。例如：根據(jù)時間的倒序排列，最新數(shù)據(jù)在最上面。這些要規(guī)范清楚，不然技術就會按照自己的理解來寫；

4. 異常機制判斷

① 突然沒有網(wǎng)絡的情況

② 接口調(diào)用超時的情況

③ 收不到回調(diào)后的情況

④ 是否有逆向流程情況

5. 定義全局配置參數(shù)

① 下拉選項是否全局配置

② 渠道平臺是否全局配置

6. 通用組件規(guī)范如何寫？

一般涉及到的規(guī)范組件，如果適用于全局，或者可以進行單獨調(diào)用的話，則可以單獨注明

1）文本輸入框

① 是否允許空格

② 字符長度限制

③ 輸入前的文本框內(nèi)容

④ 輸入后是否有清除“×”顯示

⑤ 是否有文本格式要求

2）金額輸入框

① 格式校驗

② 提現(xiàn)門檻校驗

③ 是否限次，單日/單月

④ 限額判斷：單筆限額、日限額、年限額等

⑥ 是否調(diào)用九宮格鍵盤

3）toast /彈窗提示

① 提示的位置是否居中，是否需要浮層

② toast 提示時間

③ 提示樣式

總結

因為產(chǎn)品經(jīng)理是必須對項目結果負責，以價值結果為導向的，所以我們在項目的各個環(huán)節(jié)都要主動思考怎樣讓項目更順暢的完成，以及各個環(huán)節(jié)自己能做哪些事情。

同時我也知道每個產(chǎn)品經(jīng)理應該都會有各自PRD風格，有些PRD風格是重需求背景目的，重流程，然后輕細節(jié)；有些PRD風格是重細節(jié)，輕需求背景目的，這些都不是問題，也并沒有錯。

真正的關鍵點在于我們的合作技術團隊是怎樣的，因為要想快速推進項目，最快最好的方式是改變我們自己風格，擁抱變化，然后整合融入合作團隊中。

作者：JANMING；公眾號：產(chǎn)品思考隨筆

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

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