為何寫這篇文章
過去筆者在擔任軟體開發職務時，每當Coding遇到問題，尤其是菜鳥期間，通常都會去問「師傅」（早期的企業多數是採取「師徒制」來帶領新人），但相信多數新人都會踢到「鐵板」－「師傅」會冷冷回答你：「旁邊有文件及手冊，自己去翻查吧！」。如果運氣不好，碰到的問題又「剛好」沒有文件記錄，那真的只能一本一本手冊查找（筆者那個年代還沒有「谷哥大神」阿），不僅耗時費力，還不一定能夠找到可能的解法（曾經為了解決一個問題，在公司「睡」五天）…這時，如果有「文件」，除了可以省掉不少時間之外，解決方案也許還「有跡可循」…
不過，寫「文件」這件事對很多人來說，尤其是工程師們，普遍覺得是浪費時間，此外，文件的「管理」更是門藝術，除了必須讓接收的人可以理解之外，還要能夠持續地更新與傳承，內化成公司的「知識管理」（Knowledge Management, KM），進而成為公司最重要的資產與核心競爭力（Core competence）。
本文將從以下三個面向來解構新產品開發專案必要的「文件」內容及管理方式：
- 文件管理對專案之重要性
- 新產品開發的三大文檔：BRD、MRD 和 PRD
- 文件如何內化成KM，促進跨部門溝通整合
文件管理對專案之重要性
新產品開發在多數公司都是極機密等級的專案，通常只有核心成員（Core team members）可以知道，這種「只可意會、無法言傳」的低調方式，不僅造成人才斷層、培養不易，要是 key person 整體出走，公司營運勢必大受影響。筆者過去就曾經承接某單位主管離職後的空缺，就任後才發現工作交接的文件，不僅內容不詳盡，還有很多事項未交待，也找不到相關資料，即使打電話去問，也是推說：「已經交接了，內容都在離職清單的文件上。」最後，只能一步步將「破網」補起來。
除此之外，筆者還觀察到，這類型的公司並未養成撰寫「文件」的習慣，「事後補件」就成了不成文的規定，如果有補件、歸檔那還好，至少下一次的新產品開發專案還有跡可循，最擔心的是：無前例可參考。筆者以為，如果依照這樣的模式去開發新產品，相信成功的機率肯定不高。
新產品開發的三大文檔：BRD、MRD 和 PRD
依照Crawford (2003)提出新產品開發流程（如下圖）來看，不僅每個階段（Phase）的任務（Activities）眾多、細節繁瑣，PM還需要與不同利害關係人溝通協調，因此，相關的文件內容肯定少不了，但大致上可以歸納成以下三大文檔（BRD、MRD、PRD），茲分述如下：
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）討論。 轉貼時禁止修改內容及標題、須保持所有連結、禁止商業使用，並且必須註明原文標題、連結、及作者訊息。
覺得這篇文章好嗎？ 請分享給您的朋友吧~
