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

產(chǎn)品從開發(fā)到結(jié)束，過程中會經(jīng)歷很多階段，為了確保需求可以滿足提出者的訴求，且過程中的所有人都可以達成一致理解，PRD的存在就至關(guān)重要了。那么，PRD究竟可以怎么撰寫？本文作者做了總結(jié)，一起來看看吧。

一、什么是PRD？

PRD就是產(chǎn)品需求文檔，取英文Product?requriement document 的首字母。簡單來說就是一份用來介紹產(chǎn)品是什么，以及怎么實現(xiàn)的文檔。

• “產(chǎn)品”：介紹產(chǎn)品
• “需求”：闡述需求
• “文檔”：以文檔的形式呈現(xiàn)

產(chǎn)品需求文檔 PRD文檔是產(chǎn)品項目由“概念化”階段進入到“圖紙化”階段的最主要的一個文檔，是將商業(yè)需求文檔（BRD）和市場需求文檔（MRD）用更加專業(yè)的語言進行描述。

在整個軟件產(chǎn)品的開發(fā)，一定是不同部門、不同角色、不同崗位，協(xié)同工作的成果；因此在過程中，也就需要大家各自在自己的職責(zé)范圍內(nèi)，完成相應(yīng)的工作。

MRD、BRD、PRD就是過程中的比較詳盡的交付文檔，一起被認(rèn)為是從市場到產(chǎn)品需要建立的文檔規(guī)范。

• MRD：市場需求文檔，英文全稱Market Requirement Document。該文檔在產(chǎn)品項目中是一個“承上啟下”的作用，“向上”是對不斷積累的市場數(shù)據(jù)的一種整合和記錄，“向下”是對后續(xù)工作的方向說明和工作指導(dǎo)；
• BRD：商業(yè)需求描述，英文全稱Business Requirement Document?；谏虡I(yè)目標(biāo)或價值所描述的產(chǎn)品需求內(nèi)容文檔，其核心的用途就是用于產(chǎn)品在投入研發(fā)之前，由企業(yè)高層作為決策評估的重要依據(jù)，是產(chǎn)品生命周期中最早的文檔。

二、為什么要有PRD？

為什么要有PRD？PRD又是如何發(fā)揮作用的呢？

在將PRD之前，首先講述一下產(chǎn)品開發(fā)的流程中，核心的幾個節(jié)點：需求分析——需求確認(rèn)——功能拆解——流程繪制——原型繪制——PRD書寫——PRD講解——產(chǎn)品開發(fā)——測試驗收…

• 需求來源：產(chǎn)品接收業(yè)務(wù)需求；
• 需求分析：產(chǎn)品分析需求是否合理，需求價值點；
• 需求確認(rèn)：同業(yè)務(wù)方確認(rèn)需求；
• 功能拆解：產(chǎn)品基于業(yè)務(wù)需求，拆解產(chǎn)品需求；
• 流程繪制：產(chǎn)品基于需求，明確系統(tǒng)實現(xiàn)流程；
• 原型繪制：產(chǎn)品繪制原型圖，原型相當(dāng)于產(chǎn)品的一個最初的demo演示；
• PRD書寫：產(chǎn)品撰寫PRD，需書說明PRD中詳盡的寫了需求的背景、來源、價值；以及包括的功能范圍、功能說明；
• PRD評審：產(chǎn)品同業(yè)務(wù)方、開發(fā)團隊、UI設(shè)計等相關(guān)部門，基于PRD文檔召開需求評審；
• 產(chǎn)品開發(fā)：研發(fā)人員基于PRD文檔開發(fā)代碼；UI人員基于PRD設(shè)計頁面；測試人員基于PRD寫測試用例；產(chǎn)品配合各個部門推進需求開發(fā)；
• ……

需求從開始到結(jié)束，期間經(jīng)過了不同的階段，需求的提出者、需求的實現(xiàn)者并不會一直同時跟進需求的進度。所以要確保開發(fā)出來的需求，滿足提出者的訴求，且參與其中的所有人可以理解一致，這個時候就需要PRD把這些需求描述清楚。

開發(fā)可以根據(jù)PRD獲知整個產(chǎn)品的邏輯；測試可以根據(jù)PRD建用例；項目經(jīng)理可以根據(jù)PRD拆分工作包，并分配開發(fā)人員；交互設(shè)計師可以通過PRD來設(shè)計交互細(xì)節(jié)。

PRD是項目啟動之前，必須要通過評審確定的最重要文檔：

• 保證一致的需求理解；
• 提高協(xié)同的效率；
• 版本的記錄和留存。

三、PRD文檔的撰寫

產(chǎn)品經(jīng)理作為一直參與其中的角色，也作為PRD文檔的輸出者，需要負(fù)責(zé)PRD的撰寫、文檔更新、文檔版本記錄。PRD文檔側(cè)重的是對產(chǎn)品產(chǎn)品功能和性能的說明，相對于業(yè)務(wù)需求中的同樣內(nèi)容，要更加詳細(xì)，并進行量化。

不同的公司、不同的項目對需求實現(xiàn)的流程都不太一樣，有的可能是通過MRD進行溝通、有的是依據(jù)于BRD、更多的需求可能是一句話的事情，無論是哪一種形式，最好還是通過一個正式的方式，將業(yè)務(wù)需求確認(rèn)下來，可以避免很多研發(fā)過程中的風(fēng)險，像是拉扯、甩鍋……

同樣，不同的公司對PRD文檔的形式要求也不一樣，有的是word文檔形式、有的是原型備注說明，需要根據(jù)具體的需求場景、緊迫程度來衡量，無論什么形式，PRD的核心的目的，依舊是把事情說明白。

1. PRD的框架

在我們進入一家新的公司之后，寫PRD之前，通常都會向同事詢問：“我們這里的PRD模版什么樣子，發(fā)一份給我看看吧?！泵總€公司都有自己的PRD模版，有標(biāo)準(zhǔn)的頁眉、頁腳以及內(nèi)容框架，包括但不限于：

• 文檔的命名和編號
• 文檔的版本歷史
• 目錄
• 需求概述
• 產(chǎn)品描述
• 功能需求
• 非功能需求
• 運營計劃

當(dāng)然以上內(nèi)容是按需自取，任何事情都要講究因地制宜。實在沒有必要為了套模版，一句話換不同角度去描述，長篇大論，反倒影響到需求的傳達。以自己的工作為例，經(jīng)常用到的模塊像是概述、產(chǎn)品描述、功能需求、非功能需求；像是一些大型項目，驗收標(biāo)準(zhǔn)、運營計劃都會有單獨的文檔說明。

2. PRD攥寫

1）文檔的命名和編號

這個就不用多說，封面的長相排布都大差不差。

• 主標(biāo)題：“XXXX需求文檔”，主標(biāo)題直接明了的說明，這是個什么產(chǎn)品、什么需求。講究排版的童鞋，也自定義可以寫一串“Product Requirements Document”上去；
• 副標(biāo)題：當(dāng)主標(biāo)題無法說明清楚的情況下，可以通過副標(biāo)題，更清楚的表達需求的范圍；
• 編號：根據(jù)公司的要求書寫即可。

2）文檔的版本歷史

文檔信息：形式可參考如下。

版本更新歷史：形式參考如下，用來記錄文檔版本的更新，以及更新內(nèi)容，方便協(xié)作以及回溯。

3）目錄

一方面目錄展示了整個PRD的邏輯，以及PRD的需求概覽；另一方面也起到了快速檢索、快速定位的作用。

4）需求概述

• 產(chǎn)品概述及目標(biāo)：簡單明了的說明清楚需求的背景、目標(biāo)、價值點；
• 文檔閱讀對象：該文檔主要面對的人員范圍，已經(jīng)明確不同閱讀對象相關(guān)的職責(zé)和負(fù)責(zé)的事項；
• 運營環(huán)境：本次需求涉及到的各個系統(tǒng)的大概說明；
• 產(chǎn)品風(fēng)險：目前已存在的風(fēng)險，需在文檔中記錄，以及需確保在評審結(jié)束后，項目參與人員已周知。

5）產(chǎn)品描述

在產(chǎn)品描述中的內(nèi)容，為對整個需求的全局描述，一些涵蓋全局的需求描述和設(shè)計內(nèi)容，可以在這個模塊統(tǒng)一解釋說明。

名詞解釋：PRD文檔中經(jīng)常涉及到很多專業(yè)名詞，或者是一些長稱呼的簡寫，這些名詞解釋對理解產(chǎn)品需求至關(guān)重要。為了更方便、快捷的理解，還是希望在整個文檔中，可以使用大家都可以共識的詞語去定義功能、描述需求；

產(chǎn)品整體流程圖：整體的流程圖，可以更快更準(zhǔn)確的像開發(fā)、參與人員傳遞出需求的全貌。產(chǎn)品整體流程圖的主要目的，是為了方面閱讀者理解整個需求的場景、參與的角色、彼此的關(guān)聯(lián)、核心的主流程。整體的流程圖中，主要表明要完成哪些任務(wù)、核心節(jié)點…任務(wù)或者核心節(jié)點的拆解，可以不在這個階段做詳細(xì)的拆解。

功能清單：功能清單很好理解，即說明清楚這次的文檔中，需要實現(xiàn)的產(chǎn)品功能有哪些的，也就是下一章節(jié)的內(nèi)容概覽；關(guān)于功能清單，需要考慮的問題包括，以什么維度去拆解、以及拆解的顆粒度；無論是以場景去拆解、還是系統(tǒng)框架去拆解、亦或是頁面邏輯等，依舊是以“因地制宜”、“理解為上”為核心目的。

上述的幾個模塊是從需求來源、全局角度，對整個需求的概述，方便閱讀者快速的理解需求的目的、價值，且達成一致。功能需求章節(jié)則是對每個細(xì)項功能點的詳細(xì)描述，不同角色閱讀后，可以根據(jù)此進行下一步的工作；例如說開發(fā)可根據(jù)內(nèi)容，完成任務(wù)的拆解以及代碼開發(fā)；測試可以根據(jù)內(nèi)容，完成任務(wù)的拆解以及測試用例的編寫等……

6）功能需求

這個模塊毋庸置疑，是這個PRD文檔核心發(fā)力的模塊。首先是要將需求拆解開，比如說本次的需求是完成“商品中心”的搭建，那么就可以拆解為：

1. 商品列表
2. 新增商品
3. 編輯商品
4. 查看商品
5. 刪除商品
6. ……

同功能清單一樣，拆解的顆粒度按照實際的需求，拆解完成之后，這部分內(nèi)容就會生成PRD的目錄；因此在進行的過程中可先把需求的層級先梳理清楚，再填充內(nèi)容。先搭框架、再填充的步驟，都已經(jīng)是被大家熟知的方式，無需多說其好處。

框架構(gòu)建好以后，就該填充內(nèi)容了，可按照如下的邏輯順序按需自取，例如在中后臺系統(tǒng)的設(shè)計中，需要有對角色權(quán)限的描述，就需要新增一個權(quán)限說明的模塊：如果無需以下內(nèi)容，也可以刪減修改。

• 場景描述：對該功能的業(yè)務(wù)需求、使用場景的描述；
• 流程圖：該模塊的詳細(xì)流程圖，說明清楚任務(wù)、節(jié)點、流傳；
• 原型圖：相當(dāng)于需求預(yù)覽圖；
• 詳細(xì)說明：如何把需求實現(xiàn)出來，對流程圖以及原型圖的詳細(xì)說明。

實例說明（*以新增商品為例）：

① 新增商品

A. 場景描述

新增商品主要面向商品運營人員，新商品需上市，需要運營人員將新的商品信息，新增維護進主數(shù)據(jù)，包括商品的基礎(chǔ)信息等。

② 流程圖

③ 原型圖

④ 詳細(xì)描述

路徑說明：說明清楚到達此頁面的路徑，如“商品中心-商品列表-新增”。

填寫內(nèi)容：四個階段說明：“填寫基本信息”-“填寫包裝信息”……（雖然有圖片，但是最好通過文字書寫出來，防止圖片模糊、文案變動造成的差異）。

基本信息說明：詳細(xì)到每個需要填寫的字段；

1. 字段名稱：名稱
2. 字段類型：輸入框、下拉框…
3. 默認(rèn)顯示
4. 填寫限制
5. 填寫校驗
6. 是否必填
7. 提示信息
8. 使用場景
9. ……

下一步：

1. 填寫過程中，點擊下一步，頂部高亮說明；
2. 點擊下一步，保存上一步的內(nèi)容/不保存說明；
3. 下一步報錯說明；
4. 取消：點擊取消的說明。

確認(rèn)提交：

1. 確認(rèn)校驗說明；
2. 確認(rèn)成功說明；
3. 確認(rèn)失敗說明。

取消/關(guān)閉頁面：

1. 取消說明；
2. 關(guān)閉說明；
3. ……

在詳細(xì)說明階段，除去一開始默認(rèn)的原型圖外，在說明的過程中也需要補充許多交互原型圖，如校驗提示、彈窗、切換、按鈕變化、狀態(tài)的變化等等。在一些狀態(tài)和頁面復(fù)雜的需求中，一定要把每個狀態(tài)的流傳定義清楚，包括不同狀態(tài)下的頁面、按鈕、交互的變化等。

功能需求這個章節(jié)的形式，可根據(jù)個人愛好，有的人喜歡word原始的版式，有的喜歡表格區(qū)分塊；如無公司強制要求，可以根據(jù)個人的習(xí)慣。包括詳細(xì)文檔中字段的介紹，像我個人就喜歡用表格管理，修改更方便，不容易亂序。

7）非功能需求

• 安全需求
• 統(tǒng)計需求
• 性能需求
• 財務(wù)需求
• 跨部門的需求
• ……

8）運營需求

個人較少接觸需要在PRD中寫運營計劃的項目，對于這部分有詳細(xì)了解的友友可以貢獻一下相關(guān)的經(jīng)驗；

• 后續(xù)的運營方式；
• 后續(xù)的運營計劃。

結(jié)尾：這篇PRD撰寫的文章到這里就差不多結(jié)束了，還是需要強調(diào)切勿生搬硬套，核心掌握大方向的框架構(gòu)建、以及細(xì)節(jié)上的流轉(zhuǎn)，關(guān)鍵詞應(yīng)該是邏輯能力、表達能力，學(xué)之以“漁”。

以及文章的內(nèi)容也是基于個人經(jīng)驗的總結(jié)，并非是標(biāo)準(zhǔn)的模版參考，有表達不當(dāng)?shù)牡胤揭舱堈徑?，感謝認(rèn)真讀完的友友，希望有可以幫助到大家的地方。

成功不易，但未來可期?！癓et’s open the future!”