国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

編輯導(dǎo)語：作為一個產(chǎn)品經(jīng)理，PRD文檔是必須要掌握的，PRD文檔是產(chǎn)品需求文檔，是可以將概念化的需求轉(zhuǎn)變?yōu)閳D紙化的文檔，做項目時起到輔助作用。本文作者分享了關(guān)于PRD文檔5W2H的詳細分析，我們一起來看一下。

經(jīng)常會有剛?cè)胄械漠a(chǎn)品小伙伴們問：“PRD文檔應(yīng)該怎么寫？要寫什么內(nèi)容？要細致到什么程度？用什么寫呀？”

這個問題我們可以根據(jù)5W2H分析法來進行一一拆解。（以下內(nèi)容都是根據(jù)筆者自己做過的項目總結(jié)，適用于筆者本人合作的團隊；實際的文檔內(nèi)容以及產(chǎn)出形式，只要自己的團隊能接受都OK的。）

一、What | 什么是PRD

PRD（Product Requirements Document），產(chǎn)品需求文檔，是產(chǎn)品經(jīng)理硬實力的表現(xiàn)形式之一。

“是將商業(yè)需求文檔（BRD）和市場需求文檔（MRD）用更加專業(yè)的語言進行描述”——百度詞條

簡而言之，就是將天馬行空的概念具象化為實際的業(yè)務(wù)邏輯、UI頁面、菜單按鈕、字段定義、數(shù)據(jù)結(jié)果，最終輔導(dǎo)開發(fā)人員將系統(tǒng)研發(fā)出來，落地開花。

二、Why | 為什么需要PRD文檔

PRD文檔是產(chǎn)品項目由“概念化”進入“圖紙化”的最主要的文檔，編寫主要有幾個目的：

• 概念具象化：產(chǎn)品人員搜集了各方的需求進行去偽存真的處理之后，需要對單個的需求點整合 –> 抽象 –> 具象，輸出為黑字白紙的落地文檔；并且的文檔的編寫過程中，可以從全局的角度和細節(jié)中去驗證邏輯是否正確；
• 協(xié)助項目開發(fā)：從項目立項開始、到項目評審、項目開發(fā)、項目驗收，PRD文檔貫穿了整個產(chǎn)品的誕生過程，重要性可想而知；
• 產(chǎn)品定版證據(jù)：產(chǎn)品文檔編寫完畢之后就要進行封版處理，不能在開發(fā)過程中頻繁變動需求，否則交付會無限延期；
• 記錄產(chǎn)品演進藍圖：若研發(fā)過程中需求有變動會首先排查文檔的定版內(nèi)容，對變動需求單獨進行處理；若為版本迭代，也可以根據(jù)以前的版本記錄進行追蹤查源；
• 預(yù)防人員變動：若公司的人員流動性比較強，文檔保存不當(dāng)，會導(dǎo)致產(chǎn)品的持續(xù)性研發(fā)迭代變得異常困難。

三、When | 什么時候需要PRD文檔

需要使用文檔的時機和文檔的適用對象是緊密相連的，下文一并詳細說明。

四、Who | 誰會閱讀PRD文檔

1. 公司領(lǐng)導(dǎo)——調(diào)研結(jié)束后、項目評審前

在經(jīng)過一系列的公司戰(zhàn)略會議、市場調(diào)研、競品分析研究之后，產(chǎn)品就要進入到實際的設(shè)計階段；公司領(lǐng)導(dǎo)或者產(chǎn)品直屬領(lǐng)導(dǎo)會查看部分PRD文檔，以確保需求沒有偏離軌道。

2. 設(shè)計師、研發(fā)人員——項目評審前后、研發(fā)過程中

項目評審前一般會提前下發(fā)PRD文檔，預(yù)留一些時間讓研發(fā)人員熟悉將要做的業(yè)務(wù)和內(nèi)容；以免在評審時不清楚具體需求是什么，也無法提出相應(yīng)的意見，結(jié)果在開發(fā)過程中不斷問產(chǎn)品經(jīng)理的情況。

3. 測試人員——研發(fā)過程中、測試中

項目研發(fā)過程較長，一般會讓測試人員提前介入測試，而非等開發(fā)完結(jié)后再統(tǒng)一測試，此舉也是為了避免項目研發(fā)出現(xiàn)偏差，或者測試后預(yù)留的修復(fù)bug時間不足。

如果要做足功課的話，測試人員基本要與研發(fā)人員同時熟悉PRD文檔，以免測試工作脫離了實際的業(yè)務(wù)場景。

4. 運營人員——測試中、上線后

有些業(yè)務(wù)部門可能會提前參與到項目驗收中，需要熟悉產(chǎn)品的關(guān)鍵業(yè)務(wù)流程。

功能性比較復(fù)雜的產(chǎn)品，有些公司是會專門設(shè)置職位為一線的市場、銷售人員進行使用培訓(xùn)。

5. 產(chǎn)品的接任者

如字面意思，產(chǎn)品的接任者。

五、Where | 在哪里閱讀PRD

這個應(yīng)該沒什么好說的，考慮PRD文檔的使用對象，一般就是在PC端閱讀吧，無需考慮閱讀的硬件適配啥的。

如果有人非要用手機閱讀，那只能眼睛受累了。

六、How | 如何編寫PRD文檔

寫了那么多，終于要到重點部分了。

曾聽過來自技術(shù)的一句話“一份好的PRD文檔，開發(fā)看見之后應(yīng)該是能行云流水的寫代碼，如果寫兩下就卡殼，那肯定是文檔質(zhì)量或業(yè)務(wù)邏輯出了問題。”

那一份好的PRD文檔，應(yīng)該包括哪些內(nèi)容呢？

1. 目錄或者導(dǎo)航索引

方便使用人員快速找到所需的文檔信息，個人認為建立層級分明的側(cè)邊欄索引比文檔目錄要使用便捷度高一些。

2. 關(guān)于文檔

內(nèi)容說明：基本沒人看的廢話。

適用對象：如上文所寫；主要是為了強調(diào)文檔是公司內(nèi)部保密資產(chǎn)，不可對外流出。

術(shù)語詞匯：很重要，對于新的系統(tǒng)出現(xiàn)的業(yè)務(wù)用詞或者行業(yè)內(nèi)的專有名詞，需要詳細說明。

（專有名詞說明）

3. 系統(tǒng)概述

功能模塊清單：列明系統(tǒng)版本所包含的子模塊、列表清單、菜單、備注、功能的需求等級；方便產(chǎn)品經(jīng)理清晰梳理系統(tǒng)覆蓋的業(yè)務(wù)內(nèi)容。

系統(tǒng)用戶角色說明

說明系統(tǒng)設(shè)計的所有用戶角色，對應(yīng)角色的職能。

數(shù)據(jù)權(quán)限、角色權(quán)限清單：

復(fù)雜的系統(tǒng)需要區(qū)別用戶角色、提供專門的權(quán)限清單，方便開發(fā)人員提前做好數(shù)據(jù)隔離、功能權(quán)限隔離；

4. 版本規(guī)劃

版本規(guī)劃藍圖，又稱產(chǎn)品roadtrip。

在產(chǎn)品的前期調(diào)研中，會盡量全面的考慮產(chǎn)品的完整生命周期應(yīng)該如何發(fā)展；但是研發(fā)資源是緊缺的，而且市場是需要經(jīng)過驗證的，時間也不等人，所以B端也會存在MVP的概念。

所以大型的產(chǎn)品一般會規(guī)劃分期實現(xiàn)，需要注意的是——每一期的產(chǎn)品規(guī)劃必須是一個完整的業(yè)務(wù)閉環(huán)，否則項目上線了會面了無法使用的尷尬局面。

本期需要實現(xiàn)的功能要和開發(fā)人員詳細溝通，如需預(yù)留接口的地方要做到心中有數(shù)。

例如：產(chǎn)品規(guī)劃要做多種支付通道，但是本期只做一種支付通道，那么支付通道的類型選擇，需要提前定義為便于拓展的字典，而非寫死的字段。

（某產(chǎn)品的三期規(guī)劃藍圖）

5. 框架圖、流程圖

組織架構(gòu)圖、信息框架圖：目前市面上對組織架構(gòu)圖和信息框架圖也沒有特別嚴(yán)格清晰的定義，主要是為了講解產(chǎn)品的整體框架是如何搭建的，具體框架包含的模塊，模塊所附帶的功能等；能將事情講清楚就行，不用過于在意架構(gòu)圖中是否需要詳細列明每個模塊下的細分功能點。

（某TMS系統(tǒng)單獨模塊的組織架構(gòu)圖）

業(yè)務(wù)流程圖：核心的業(yè)務(wù)流程圖顆粒度比較粗，講述關(guān)鍵節(jié)點的操作和數(shù)據(jù)流轉(zhuǎn)，以及關(guān)鍵環(huán)節(jié)的參與對象。

（某TMS系統(tǒng)核心業(yè)務(wù)流程圖）

核心業(yè)務(wù)流程定下來后，可以對業(yè)務(wù)流程進行細化；顆粒度最細的是具有邏輯判斷、異常流描述的流程圖。

本人的習(xí)慣是在進行具體的功能文字描述時，比較復(fù)雜的業(yè)務(wù)流程會配備流程圖，圖形比文字更容易理解。

（細化流程：常見的注冊流程圖）

6. 功能需求描述

功能需求的描述，需要覆蓋以下內(nèi)容：

• 功能描述：1-3句話概括功能要點，建立開發(fā)對功能大致了解；
• 業(yè)務(wù)場景描述：比較不容易理解的業(yè)務(wù)流程，可以描述實際業(yè)務(wù)場景，或者在評審環(huán)節(jié)，多詳細講解業(yè)務(wù)發(fā)生的線下場景，需要解決的用戶痛點，便于開發(fā)建立對業(yè)務(wù)更全面的認知，產(chǎn)生共鳴；
• 前置條件：動作發(fā)生的限制條件；例如操作該功能應(yīng)該具備的權(quán)限；例如司機接單的前置條件是已經(jīng)完成實名認證等；
• 后置條件：動作發(fā)生后引起的結(jié)果；例如指派訂單動作后，系統(tǒng)會更新一條訂單記錄，同時司機收到待運訂單消息；
• 異常情況：動作后可能存在的異常情況；；例如指派訂單后，需要對訂單進行取消或者撤回處理（根據(jù)個人的項目經(jīng)驗，異常情況的考慮在業(yè)務(wù)描述中基本占比能到30%-50%，甚至可能更高，異常比較考驗產(chǎn)品人員對業(yè)務(wù)的熟悉情況、逆向思考的邏輯能力以及邏輯的縝密性）；
• 排序方式：數(shù)據(jù)產(chǎn)生后，以什么條件進行排序；時間順序、逆序；數(shù)值正序、倒序等；
• 交互規(guī)則：可以附帶小卡片式頁面跳轉(zhuǎn)邏輯、彈窗展示描述等；
• 計算規(guī)則：有計算值的，給出計算公式；計算過程比較復(fù)雜的，最好是可以提供一份測算表格，方便開發(fā)人員比對實現(xiàn)的效果是否正確；
• 字段說明：對字段的類型、長度、默認值、計算規(guī)則等進行說明；之前寫過一篇《增刪改查顯算傳，7字箴言搭建B端底層框架》的文章，對字段進行過詳細講解，大家有興趣可以看一下；
• 核心字典狀態(tài)定義：清晰描述字典值變動的條件和業(yè)務(wù)狀況，字典之間的切換不要有冗余狀態(tài)或者瞬時狀態(tài)；例如支付業(yè)務(wù)中，常見的字典有：待支付、支付成功、支付失??；若是瞬時到賬的支付方式，此處加入已凍結(jié)狀態(tài)，就屬于字典冗余；需要預(yù)留接口的字典，暫時用不上的，需要對字典禁用，以免開發(fā)不清楚情況使用了錯誤的字典值。

（核心字典狀態(tài)定義）

（功能需求描述）

（字段說明）

7. 頁面原型

只要做好了以上的工作，原型只是水到渠成的事情——可謂“邏輯思考10小時，原型作圖2分鐘”。

對于比較簡單的需求，也很常用的是直接在原型頁面上編寫PRD文檔。

（原型直接標(biāo)注需求描述）

8. 數(shù)據(jù)說明

可能公司不同對產(chǎn)品的要求有區(qū)別，目前經(jīng)歷過的有：

• 要求寫明基本的請求參數(shù)，即字段說明；
• 要求設(shè)計基礎(chǔ)的業(yè)務(wù)表結(jié)構(gòu)，表明數(shù)據(jù)之間的建模關(guān)系，一對一、一對多、多對多等；
• 也有要求產(chǎn)品做業(yè)務(wù)數(shù)據(jù)建模；正在了解中，希望以后有機會可以寫一下。

（ER圖，數(shù)據(jù)之間的關(guān)系）

9. 全局規(guī)范

對通用交互原則、產(chǎn)品規(guī)則的描述，大型的團隊一般會配專門的交互設(shè)計師，在原型設(shè)計的基礎(chǔ)上對產(chǎn)品交互進行優(yōu)化。

10. 非功能性需求描述

• 埋點需求：對特定用戶的行為和活動路徑進行數(shù)據(jù)捕捉、獲取的手段，為產(chǎn)品的持續(xù)優(yōu)化迭代提供數(shù)據(jù)支撐；常用第三方埋點平臺而非自研埋點平臺，后者研發(fā)成本較高（偏向于產(chǎn)品的運營方向）。
• 產(chǎn)品性能需求：目前淺薄的了解過并發(fā)性能、響應(yīng)性能、安全性能等（技術(shù)向，了解不深）。

11. 文檔編寫工具

• Word文字描述 + 原型截圖：常用形式；
• Axure原型 + 批注/說明：需求簡單情況適用；
• 口述：緊急需求適用，后期需補充文檔。

小結(jié)：PRD文檔的描述，需要保持交互邏輯的一致性（避免二級頁面，時而為“彈窗”時而為“跳轉(zhuǎn)頁面”）、文案風(fēng)格的一致性、功能命名的一致性、字段命名的一致性（避免個人名稱字段此列表叫“名稱”彼列表叫“姓名”的情況）。

七、How much | 文檔版本控制

5W2H原則，這里使用how much其實有點不太合適；但是文檔的版本記錄，還是值得一說的。

一般從0-1的產(chǎn)品文檔相對好寫一些，評審結(jié)束后研發(fā)期間，基本會對文檔進行封版處理。

如果有不得已的情況需要對文檔進行變動，一定及時告知相關(guān)負責(zé)人員，例如產(chǎn)品領(lǐng)導(dǎo)、技術(shù)開發(fā)人員、測試人員，并及時維護文檔，每一次的變更都需要留下文字記錄。

個人認為對閱讀者來說比較好的方式是：文檔頭部增加版本變更記錄，同時在文檔內(nèi)部用不同的顏色將變動的內(nèi)容標(biāo)注出來。

已經(jīng)上線的版本變更，需要著重梳理變動內(nèi)容和前后業(yè)務(wù)流程的關(guān)聯(lián)影響，特別是產(chǎn)品的業(yè)務(wù)耦合性比較強的，很容易發(fā)生修改一處需求，引起多出報錯的情況。

版本變更記錄，需要包含的信息有：

• 版本號：重大變更V1.0.0/V2.0.0；小規(guī)模修改：V1.1.0/V1.2.0；
• 提交時間；
• 狀態(tài)：新增、變更或者刪除需求；
• 簡要描述變更的內(nèi)容；
• 部門：需求提出人；
• 更改人：需求文檔變更人；
• 批準(zhǔn)人/批準(zhǔn)部門。

八、總結(jié)

PRD文檔的編寫是需要萬分聚精會神的細致的工作，基礎(chǔ)中現(xiàn)功底。

在評審結(jié)束后，PRD文檔交接給設(shè)計人員、開發(fā)人員，如果文檔編寫的足夠扎實，那基本不太會出現(xiàn)返工的情況，研發(fā)的過程也會比較順暢。

好的文檔，會讓研發(fā)人員覺得靠譜、安心，也會給產(chǎn)品經(jīng)理帶來一份自信。

特別是某天你躺在床上驚坐起，感覺自己漏了什么關(guān)鍵內(nèi)容，趕快打開文檔，發(fā)現(xiàn)聚精會神的狀態(tài)下自己的邏輯思考很嚴(yán)密沒有遺漏的時候，那種快樂你一定也體會過。

時間久了，你會更相信自己的判斷，能更從容的應(yīng)對來自各方的質(zhì)疑。

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

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