新產品開發專案的「文件管理」:BRD、MRD 和 PRD

寫「文件」這件事對很多人來說,尤其是工程師們,普遍覺得是浪費時間,此外,文件的「管理」更是門藝術,除了必須讓接收的人可以理解之外,還要能夠持續地更新與傳承,內化成公司的「知識管理」(Knowledge Management, KM),進而成為公司最重要的資產與核心競爭力(Core competence)。

為何寫這篇文章

過去筆者在擔任軟體開發職務時,每當Coding遇到問題,尤其是菜鳥期間,通常都會去問「師傅」(早期的企業多數是採取「師徒制」來帶領新人),但相信多數新人都會踢到「鐵板」-「師傅」會冷冷回答你:「旁邊有文件及手冊,自己去翻查吧!」。如果運氣不好,碰到的問題又「剛好」沒有文件記錄,那真的只能一本一本手冊查找(筆者那個年代還沒有「谷哥大神」阿),不僅耗時費力,還不一定能夠找到可能的解法(曾經為了解決一個問題,在公司「睡」五天)…這時,如果有「文件」,除了可以省掉不少時間之外,解決方案也許還「有跡可循」…

不過,寫「文件」這件事對很多人來說,尤其是工程師們,普遍覺得是浪費時間,此外,文件的「管理」更是門藝術,除了必須讓接收的人可以理解之外,還要能夠持續地更新與傳承,內化成公司的「知識管理」(Knowledge Management, KM),進而成為公司最重要的資產與核心競爭力(Core competence)。

本文將從以下三個面向來解構新產品開發專案必要的「文件」內容及管理方式:

  1. 文件管理對專案之重要性
  2. 新產品開發的三大文檔:BRD、MRD 和 PRD
  3. 文件如何內化成KM,促進跨部門溝通整合

文件管理對專案之重要性

新產品開發在多數公司都是極機密等級的專案,通常只有核心成員(Core team members)可以知道,這種「只可意會、無法言傳」的低調方式,不僅造成人才斷層、培養不易,要是 key person 整體出走,公司營運勢必大受影響。筆者過去就曾經承接某單位主管離職後的空缺,就任後才發現工作交接的文件,不僅內容不詳盡,還有很多事項未交待,也找不到相關資料,即使打電話去問,也是推說:「已經交接了,內容都在離職清單的文件上。」最後,只能一步步將「破網」補起來。

除此之外,筆者還觀察到,這類型的公司並未養成撰寫「文件」的習慣,「事後補件」就成了不成文的規定,如果有補件、歸檔那還好,至少下一次的新產品開發專案還有跡可循,最擔心的是:無前例可參考。筆者以為,如果依照這樣的模式去開發新產品,相信成功的機率肯定不高。

新產品開發的三大文檔:BRD、MRD 和 PRD

依照Crawford (2003)提出新產品開發流程(如下圖)來看,不僅每個階段(Phase)的任務(Activities)眾多、細節繁瑣,PM還需要與不同利害關係人溝通協調,因此,相關的文件內容肯定少不了,但大致上可以歸納成以下三大文檔(BRD、MRD、PRD),茲分述如下:

NPD Flow
Photo By Gary Hsia

BRD(Business Requirement Document)商業需求規劃書

從Business(商業)這個字來看,大概不難猜出這份文件是要呈報給老闆及高層主管們檢視的內容,目的是讓決策者們從制高點的角度去了解:

  • 為何要做這個產品?
  • 需要多少資源(如:人、設備、時間、錢)?
  • 可以幫公司帶來哪些效益?
  • 可以提升哪些競爭優勢?
  • 商業模式是什麼?

用簡單的話語來說,BRD是「一份企業想要運用產品或服務實現目標的藍圖。」 BRD的內容則涵蓋新產品開發專案所有的可交付成果(如:市占率可提升10%)以及與每個階段相關的輸入(inputs)和輸出(deliverables)。

通常BRD由公司幕僚(如:特助)或是PMO(專案管理辦公室)組織成員來撰寫,在大型企業比較適用,因為產品線(product line)及產品組合(product portfolio)相對複雜許多,但對於中小型企業來說,BRD可能會併入MRD(後文會說明)的文件內容。

MRD(Market Requirement Document)市場需求規劃書

當公司高層同意BRD的內容,也就表示市場需求有增強的可能性,值得繼續往下一個流程發展,這時就需要著手進行MRD市場需求規劃書的撰寫。MRD代表的是:

  • 對新產品開發或產品強化的要求。
  • 針對產品概念確定的顧客或潛在顧客以及市場需求。
  • 確保在產品設計過程中有履行「傾聽顧客聲音」(Voice of Customer, VOC)。

MRD大致上涵蓋以下內容:

  • 產品面:對新產品或既有產品功能強化進行完整描述。
  • 市場面:市場區隔和目標市場分析,確定誰是潛在客戶。
  • 競品面:競爭分析-全面細分市場中的競爭對手及其產品。
  • 營運面:針對即將開發的產品,描述其如何瞄準目標客群並與競爭產品做出區隔。

簡單來說,MRD需要明確指出產品的目標客群(Target Audience, TA),市場研究人員才能更好的進行分析,營運(operation)部門有了較精準的數據資料,自然在市場推廣(market promotion)方面,能夠制定出更好的方案。這就是MRD文件串連商業、市場、營運的關鍵角色。

通常MRD由公司的產品行銷經理(Product Marketing Manager, PMM)或是PM自己來撰寫,筆者認為無論公司大小,都應該要有一份類似MRD的文件內容-對市場及用戶需求的充分了解。

PRD(Product Requirement Document)產品需求規劃書

PRD的主要作用在於-向所有利害關係人及產品開發團隊描述該產品將是什麼?確保所有成員都明白該產品即將交付的內容為何?

一般來說,PRD包含以下內容:

  • 摘要總結:包括產品願景、目標、範圍和風險。
  • 產品功能:詳細定義產品功能列表(List of Features),包括:發布計劃、功能性需求、非功能性需求、相容性、安全性、性能、可用性、操作性、服務機制、法律、安規、通路、包裝、測試、體驗…等,以及其他大大小小瑣碎的事。如果你的公司在Run敏捷,那麼此部分的內容只需要簡化到目前已知的部分。因為,敏捷會在此過程的後期適應變化。如有必要,請主動添加到列表中,然後刪除不適用的內容。
  • 開發架構:本次產品開發專案的架構為何?將使用哪些工具和流程來開發產品?
  • 高層次範疇:說明所需的資源、工具、日期和里程碑。
  • 風險分析:說明可能的風險及分析因應對策。
  • 結論或建議:總結對於本次產品開發專案的具體結論或建議。
  • 附錄:圖表、參考資料或更多詳細文件都可以放在此處。

以上內容大致上可以再簡化成產品介面、產品流程、功能需求、測試需求、體驗需求等面向,至於PRD要展開到什麼程度,還是要看公司大小及產品的複雜程度而定。

筆者建議,PRD必須由PM自己來撰寫,理由有以下兩點:

第一、確保產品能有效率有節奏的進行!

第二、PRD的優劣關係到整個產品的發展方向!

BRD、MRD、PRD三者之間有何連結

從為什麼要做新產品的角度來看,BRD是從企業經營管理的觀點來看產品策略;MRD是從使用者的觀點來看市場問題;PRD則是從產品的觀點提供解決市場問題的方式

從黃金圈法則(Golden circle)來看,Why所代表的是BRD,How是所謂的是MRD,What則是PRD。

用一句話來形容:BRD是產品的Head、MRD是產品的Body、PRD是產品的Heart,有了Head、Body、Heart這就是一個完整的產品了!

文件如何內化成KM,促進跨部門溝通整合

專案失敗並不可恥,特別是新產品開發的失敗率尤其高,如果我們沒有從每一次的專案失敗過程中汲取經驗(Lesson Learned),難保下一次不會再出現類似的情況。以這次疫情防範為例,歐美日韓等國家相繼出現離譜的防疫漏洞、如果不是2003年SARS的防疫經驗傳承(相關的文件紀錄及當時的防疫人員協助),相信台灣這次也難逃此劫!因此,「保留專案經驗記錄,提供未來專案參考」這件事就顯得日益重要。

筆者認為,要讓「文件管理」做得好,並且內化成公司的KM,首要之務就是要成立專責組織來推動,如果公司已經有PMO相關組織,那麼這件事的進展就比較有機會能達成目標,反之,將成為三不管地帶,大家相互推諉責任,這也是長久以來公司推行KM失敗的主因。

其次,要建立文件樣態的標準化,不同單位的文件格式(如:Office、Visio、Xmind、Axure…等)、內容(如:文字、圖片、影音…等)可能有極大的差異,KM推動小組需要跨單位進行溝通協調,並扮演「文件標準化」的橋樑。

最後,則是要將各部門是否有落實「文件管理」列入KPI指標,作為績效考核的一部分,KM推動小組則是要定期與各單位進行訪談,以了解運用「文件」與其他單位溝通的成效以及遇到的問題有哪些?

上述的做法可以運用敏捷的專案管理來執行,經過幾次迭代修正(如:口罩實名制),就能逐漸讓KM標準化,也能充分運用在新人的入職訓練(Orientation),不僅可以節省不少公司內部溝通的成本,還能化解不必要的跨部門衝突發生。

結語

宏碁過去的文化信念有一條是「不留一手的師傅」,意即「經驗傳承」,目的是要避免公司的營運因為人員流失或離職而發生斷層,進而衝擊到公司的整體績效。不過,真的要做到「人人不藏私」,確實需要領導者能以身作則,樹立典範,方有可為。

筆者認為,隨者5G、AIoT的快速發展,新產品開發的複雜程度可想而知,「文件」的「數位化」將是必然的趨勢,隨之而來的資安問題(如:文件控管)必定是公司需正視的問題。至於新產品開發專案的「文件」有哪些具體內容或是標準格式、範本(網路上有很多範例參考),也許就不一定是最重要的問題,只要能有效達成團隊溝通的目的、共同完成產品上市的目標才是最核心的關鍵。

(本文同步刊登於10/01出刊的《專案經理》雜誌第53期

圖片來源:Image by Jerzy Górecki from Pixabay

若有轉貼需求,請來信(service@pmtone.com)討論。 轉貼時禁止修改內容及標題、須保持所有連結、禁止商業使用,並且必須註明原文標題、連結、及作者訊息。

覺得這篇文章好嗎? 請分享給您的朋友吧~

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on email
Email
Share on print
列印

延伸閱讀