PRD產(chǎn)品需求文檔 | 實(shí)例撰寫(xiě)指南

8 評(píng)論 61765 瀏覽 603 收藏 17 分鐘

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

一、什么是PRD?

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

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

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

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

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

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

二、為什么要有PRD?

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

在將PRD之前,首先講述一下產(chǎn)品開(kāi)發(fā)的流程中,核心的幾個(gè)節(jié)點(diǎn):需求分析——需求確認(rèn)——功能拆解——流程繪制——原型繪制——PRD書(shū)寫(xiě)——PRD講解——產(chǎn)品開(kāi)發(fā)——測(cè)試驗(yàn)收…

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

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

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

PRD是項(xiàng)目啟動(dòng)之前,必須要通過(guò)評(píng)審確定的最重要文檔:

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

三、PRD文檔的撰寫(xiě)

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

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

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

1. PRD的框架

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

  • 文檔的命名和編號(hào)
  • 文檔的版本歷史
  • 目錄
  • 需求概述
  • 產(chǎn)品描述
  • 功能需求
  • 非功能需求
  • 運(yùn)營(yíng)計(jì)劃

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

2. PRD攥寫(xiě)

1)文檔的命名和編號(hào)

這個(gè)就不用多說(shuō),封面的長(zhǎng)相排布都大差不差。

  • 主標(biāo)題:“XXXX需求文檔”,主標(biāo)題直接明了的說(shuō)明,這是個(gè)什么產(chǎn)品、什么需求。講究排版的童鞋,也自定義可以寫(xiě)一串“Product Requirements Document”上去;
  • 副標(biāo)題:當(dāng)主標(biāo)題無(wú)法說(shuō)明清楚的情況下,可以通過(guò)副標(biāo)題,更清楚的表達(dá)需求的范圍;
  • 編號(hào):根據(jù)公司的要求書(shū)寫(xiě)即可。

2)文檔的版本歷史

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

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

3)目錄

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

4)需求概述

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

5)產(chǎn)品描述

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

名詞解釋?zhuān)?/strong>PRD文檔中經(jīng)常涉及到很多專(zhuān)業(yè)名詞,或者是一些長(zhǎng)稱(chēng)呼的簡(jiǎn)寫(xiě),這些名詞解釋對(duì)理解產(chǎn)品需求至關(guān)重要。為了更方便、快捷的理解,還是希望在整個(gè)文檔中,可以使用大家都可以共識(shí)的詞語(yǔ)去定義功能、描述需求;

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

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

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

6)功能需求

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

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

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

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

  • 場(chǎng)景描述:對(duì)該功能的業(yè)務(wù)需求、使用場(chǎng)景的描述;
  • 流程圖:該模塊的詳細(xì)流程圖,說(shuō)明清楚任務(wù)、節(jié)點(diǎn)、流傳;
  • 原型圖:相當(dāng)于需求預(yù)覽圖;
  • 詳細(xì)說(shuō)明:如何把需求實(shí)現(xiàn)出來(lái),對(duì)流程圖以及原型圖的詳細(xì)說(shuō)明。

實(shí)例說(shuō)明(*以新增商品為例):

① 新增商品

A. 場(chǎng)景描述

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

② 流程圖

③ 原型圖

④ 詳細(xì)描述

路徑說(shuō)明:說(shuō)明清楚到達(dá)此頁(yè)面的路徑,如“商品中心-商品列表-新增”。

填寫(xiě)內(nèi)容:四個(gè)階段說(shuō)明:“填寫(xiě)基本信息”-“填寫(xiě)包裝信息”……(雖然有圖片,但是最好通過(guò)文字書(shū)寫(xiě)出來(lái),防止圖片模糊、文案變動(dòng)造成的差異)。

基本信息說(shuō)明:詳細(xì)到每個(gè)需要填寫(xiě)的字段;

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

下一步:

  1. 填寫(xiě)過(guò)程中,點(diǎn)擊下一步,頂部高亮說(shuō)明;
  2. 點(diǎn)擊下一步,保存上一步的內(nèi)容/不保存說(shuō)明;
  3. 下一步報(bào)錯(cuò)說(shuō)明;
  4. 取消:點(diǎn)擊取消的說(shuō)明。

確認(rèn)提交:

  1. 確認(rèn)校驗(yàn)說(shuō)明;
  2. 確認(rèn)成功說(shuō)明;
  3. 確認(rèn)失敗說(shuō)明。

取消/關(guān)閉頁(yè)面:

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

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

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

7)非功能需求

  • 安全需求
  • 統(tǒng)計(jì)需求
  • 性能需求
  • 財(cái)務(wù)需求
  • 跨部門(mén)的需求
  • ……

8)運(yùn)營(yíng)需求

個(gè)人較少接觸需要在PRD中寫(xiě)運(yùn)營(yíng)計(jì)劃的項(xiàng)目,對(duì)于這部分有詳細(xì)了解的友友可以貢獻(xiàn)一下相關(guān)的經(jīng)驗(yàn);

  • 后續(xù)的運(yùn)營(yíng)方式;
  • 后續(xù)的運(yùn)營(yíng)計(jì)劃。

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

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

成功不易,但未來(lái)可期?!癓et’s open the future!”

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

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

該文觀點(diǎn)僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺(tái)僅提供信息存儲(chǔ)空間服務(wù)。

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 還想問(wèn)下填寫(xiě)內(nèi)容就是把每個(gè)階段以及階段下的字段都列出來(lái)嗎

    來(lái)自湖南 回復(fù)
  2. 既然要寫(xiě)功能列表,而且和功能清單的顆粒度相同,為何不刪掉功能清單呢

    來(lái)自湖南 回復(fù)
    1. 功能清單應(yīng)該是指模塊,比如商品管理,而功能需求應(yīng)該是指功能點(diǎn),如商品的增、刪、改、查。

      來(lái)自重慶 回復(fù)
    2. 感謝 懂了

      來(lái)自湖南 回復(fù)
  3. 作者的經(jīng)驗(yàn)很有借鑒意義,感謝!

    來(lái)自四川 回復(fù)
  4. 感謝分享!

    來(lái)自上海 回復(fù)
  5. 基本上軟件設(shè)計(jì)的PRD差不多是這個(gè)結(jié)構(gòu),這還是比較簡(jiǎn)單的,但是如果是多系統(tǒng)集成的,可能會(huì)還會(huì)需要系統(tǒng)的時(shí)序交互圖用來(lái)說(shuō)明系統(tǒng)間的流程和數(shù)據(jù)傳遞,這樣開(kāi)發(fā)也比較清楚該找哪一位負(fù)責(zé)人

    來(lái)自上海 回復(fù)
  6. 感謝!如果可以附錄一個(gè)寫(xiě)好的案例可以看就更好啦

    來(lái)自廣東 回復(fù)