閱讀356 返回首頁    go 技術社區[雲棲]


PRD


該文檔是產品項目由“概念化”階段進入到“圖紙化”階段的最主要的一個文檔,其作用就是“對MRD中的內容進行指標化和技術化”,這個文檔的質量好壞直接影響到研發部門是否能夠明確產品的功能和性能。


產品需求文檔

  產品需求文檔(Product Requirement Document,PRD)的英文簡稱。是將商業需求文檔(BRD)和市場需求文檔MRD)用更加專業的語言進行描述。

文檔意義

  該文檔在產品項目中是一個“承上啟下”的作用,“向上”是對MRD內容的繼承和發展,“向下”是要把MRD中的內容技術化,向研發部門說明產品的功能和性能指標。

文檔撰寫

  在該文檔中,基點依然是MRD中的內容,隻是把重心放在了“產品需求”上,而產品需求本身是在MRD中有所體現的,區別就是在於,PRD要把MRD中的“產品需求”的內容獨立出來加以詳細的說明。
  這部分是PRD寫得最多的內容,也就是傳統意義上的需求分析,我們這裏主要指UC(use case)文檔。主要內容有,功能使用的具體描述(每個UC一般有用例簡述、行為者、前置條件、後置條件、UI描述、流程/子流程/分支流程,等幾大塊),Visio做的功能點業務流程,界麵的說明,demo等。Demo方麵,可能用dreamweaver、ps甚至畫圖板簡單畫一下,有時候也會有UI/UE支持,出高保真的demo,開發將來可以直接用的那種。
  文檔核心
  該文檔中,側重的是對產品產品功能和性能(即“產品需求”)的說明,相對於MRD中的同樣內容,要更加詳細,並進行量化。
  在一些國外的公司,是允許把MRD和PRD合並成一個文檔的,通常叫做“Marketing & Product Requirements Document”。
  該文檔一般可以包括以下內容:
  該產品的遠景目標(vision)
  目標市場和客戶(target market and customers)的描述
  競爭對手分析(competitive summary)
  對產品主要feature的比較詳細的描述
  這些feature的優先級
  初步擬定的實現進度安排
  用例(use cases),這可以是較粗略的大致描述,未必一定要UML Use Case圖。
  產品的軟硬件需求
  產品的性能要求
  銷售方式上的思路、需求(直銷還是渠道?直銷怎麼做?渠道怎麼做?)
  技術支持方式上的思路、需求(提供什麼樣的技術服務?)
  開發工具推薦 :
  Rational Rose--熟悉項目發生的相關業務行為。
  visio 2007--將業務,從產品層麵肢解開來,做到抽絲剝繭部分與整體統一
  mind manager--把項目條目化,條理化,目錄結構具體規定好。
  Axure--前台結構布局,合理規範的將係統脫去朦朧的華紗。
  Word--穿針織網,把需求綜合起來,整理成最終的產品需求文檔

錯誤認識

  1)PRD無原始數據(MRD為體現載體)支持,隻是個人經驗、部門要求或者領導指示進行撰寫。
  2)在PRD中,隻重視“產品功能”的描述,而缺乏對產品其它指標項的說明。在一個完整的PRD中,一共需要對產品的10個產品需求項指標進行說明,分別是“功能要求、開發要求、兼容性要求、性能要求、擴展要求、產品文檔要求、產品外觀要求、產品發布要求、產品支持和培訓要求、產品其它要求”。
  3)照搬國外的PRD模板,來源於何處,不知道,將去向何處,也不知道,無頭無尾,一個被割裂的文檔。


其它解釋

  1)Pesticides Regulation Division:(美國)農藥管理局
  2)pro-rata distribution:按比例分配
  3) .prd文件擴展名
  4) Pearl River Delta: 珠江三角洲
  5) Phase Reserval Disconnector:換相閘刀(發電電動機)


BRD與PRD的差異

  BRD不同於常見的MRD(Market Requirement Document-市場需求文檔)和PRD(Product Requirement Document-產品需求文檔),既然是用於產品實施之前的決策評估依據,必然對其文檔(報告)的內容和格式要求夠直觀、精煉,要點突出。作為報告的撰寫者,你必須讓高層明白,你的報告中將展現出怎樣的商業價值,如何用有力的論據來說服企業對你這個項目的認可,並為之慷慨的投入研發資源及市場費用。如果說PRD的好壞,直接決定了項目的質量水平,那麼BRD的作用,就是決定了你的項目的商業價值。優秀的BRD文檔,可以讓決策層充分被你的報告觀點所吸引,或許財務主管會因為報告呈現的低投入高產出的經濟效益預測而蠢蠢欲動;或許技術主管會因為項目的牽涉麵廣泛而頭疼不已;又或許公司的VP之流因之報告而看到了未來一年業績的飛速發展的廣闊前景……
  說白了,BRD需要產品經理(產品設計師)像對待PRD一樣,充分應用市場調查、用戶研究、需求分析等各種設計手段來充分闡述報告的內容。基於這樣的狀況,顯然不是給大家一份完整的BRD標準格式規範,就能夠搞定一切的!哈,也許有人會說這有點危言聳聽,不過我一向讚成,麵對一切“產品”,都應該用設計的眼光看待它。
  首先,你應該把決策層當作你的產品——BRD的受眾群體,一切從這裏開始……
擴展閱讀:
開放分類:

最後更新:2017-04-02 16:48:17

  上一篇:go 子類方法返回類型必須和父類相同,拋出的異常聲明可以小於或等於父類
  下一篇:go 怎樣成為一個優秀的程序員?