項目管理@IC --BP/MRD/PRD

BP：Business Plan , 定義項目的意義(Mission)MRD：Marketing Requirements Document, 定義項目目標(Target)PRD：Product Requirements Document,定義項目具體範圍(Scope)

Business Plan

BP和MRD，都是由產品經理編寫，並經過公司管理層審核。

我個人喜歡用BP來代替BRD，實際上任何一個集成電路開發項目，都像一次投資。對任何一家公司來說，時間、資金和人力的投入，都需要很好的計算和評估ROI。

當然，ROI中的Return，未必一定是財務回報。比如科研單位的項目和大部分公司都會有的test chip，或者研究性的項目。

BP要回答的問題：為什麼做這個產品，它至少應該包括：

• 市場競爭格局分析
• 銷售/市場策略
• ROI分析（return on investment）
• 成本分析
• 產品推出的時間窗口 （什麼時候要？）
• 風險分析及應對方案
• 財務預算（需要多少錢？多少人（其實還是錢）？分幾個階段給？）
• 融資計劃（資金從哪裡來？內部融資還是外部融資？一次性給還是分階段給？）

BP包含很多敏感信息，通常會控制傳播範圍，主要讀者是管理層。研發部門比較少看到，不在研發項目管理話題之內。如何寫出一份好BP是另外一個很大的話題，這部分就不再贅訴，

MRD

MRD是產品經理根據BP，儘可能用技術語言，給出的產品定義。它的讀者不止是研發部門，還有商務、市場、銷售、運營、生產及其他職能部門。

對研發部門來說，MRD是項目的原始輸入。拿到第一版MRD，是研發項目的籌備階段的開始

MRD應該包括以下內容和關鍵點：

• 市場分析（why）
• 盡量用工程師可以聽懂的語言，解釋為何要做這個項目
• 解釋這個項目為何如此定義，提高工程師對項目的認可度，這一點至關重要！所有工程師都希望他們的辛勤勞動能創造真正的價值。領導力有一個基本套路：共起願景，就是在這裡體現。
• 產品主要功能和參數要求（what）
• PPPA（Performance、Power、Area）（what）
• Area包括晶元die size和pin number，這個數字對晶元成本估算很重要。die size決定一片晶圓可以切出多少顆晶元，pin number決定了封裝成本
• 要拿到的資質認證（what）
• 比如有USB介面的，是否要通過USB-IF的logo測試
• 是否需要通過某些行業標準認證
• 重要milestones（when）
• kickoff：項目起始日期
• tapeout：第一次溜片時間
• ES：engineering sample時間點
• MP：mass production（量產） 時間點
• 為產品功能劃分優先順序（what）
• Critical：某些功能是必須具備，某些參數是必須做到，否則項目註定失敗。
• Medium：功能必須存在，但某些參數或指標有一定的裕量
• better to have：某些可有可無的功能
• 產品經理一定要明確、如實定義出優先順序，以便研發部門在分配資源和制定開發計劃方面有所參考
• 配套應用軟體/驅動開發需求（what）
• 不班門弄斧了，請軟體開發的朋友們補全
• MRD版本信息和修改記錄
• MRD和PRD通常會多次迭代修改，版本控制就顯得非常重要
• 使用標準技術語言，明確地描述
• 避免與工程師產生不同理解而產生分歧，特別是某些縮寫，常常會產生歧義
• 必要情況下可以維護一個術語表

PRD

研發團隊根據MRD編製出PRD，並反饋給產品經理。通常來說，產品經理和研發團隊會經過反覆溝通，對MRD和PRD進行進一步修正

PRD的作用主要是:

對MRD里定義的功能和參數，用工程師語言複述，並進一步詳細和準確的定義，反饋給產品經理審核，以確保雙方理解一致。

把MRD用技術語言，解釋給開發團隊。用於評估開發工作量，所需人力和時間，以及技術開發文檔編寫

PRD 包含的內容和關鍵點：

• 所有功能詳細列表和明確定義
• 技術可行性分析
• 產品經理主要是從市場角度考慮一個項目，對技術細節未必了解的很深入。所以研發部門必須組織技術專家，對MRD進行技術評估，以確定技術可行性
• 潛在風險評估
• 研發部門應該從技術實現角度，提出潛在風險和解決方案
• 開發計劃
• 根據PRD，開發團隊的Project Leader應該組織內部項目經理和技術經理，制定詳細開發計劃，具體內容在開發計劃相關文章中討論。
• 工作量/人力的評估
• 有了詳細功能列表和開發計劃，就可以大致估算出每個階段所需要的人數，最後作出一個逐月/周人力評估表。
• 這個表將提供給產品經理，用來修正預算評估。CFO批准過修正的預算之後，HR部門會根據此表招聘所短缺的員工，如果有的話。
• 所需外部依賴
• 研發部門應該列出為了完成這個項目所需要的所有外部依賴給產品經理，以便他協調資源，解決問題。比如：
• 晶元規模變大，模擬伺服器算力不夠，需要新增採購，並於特定日期之前就位
• 需要特定EDA工具或者第三方IP，必須某日之前到位
• 需要IT部門協助設立JIRA伺服器，並於項目開始前測試完畢

功能列表和MRD的不同之處，是「所有」。MRD一般只描述主要功能，還有些功能需要研發部門自己列出來

• 某些默認功能：有些項目是從上一個項目繼承，一些功能默認就需要有，或者所需要的工作量不大，MRD常常就省略不寫。
• 內部功能：為了實現那些主要功能所必需，或者為了讓晶元正常工作所必需，最終客戶未必看得到，BP/MRD里自然不會寫。比如：複雜soc晶元的debug子系統。
• 實驗性功能：晶元的流片成本很高，對於一些複雜SoC晶元，往往會搭載一些實驗性功能。這些功能BP/MRD上沒有，但是單獨去流片驗證又不划算，在不影響正常功能和晶元總體成本的前提下，會由研發部門提出，假如PRD

文檔的版本

MRD/PRD在項目初期會頻繁討論和修改，即便是項目開始之後，也可能根據當時情況的變化，修改MRD/PRD。所以版本的控制非常重要，要確保所有人最後看到的都是最新版本

關鍵的版本要由管理層書面簽核

這部分在SOP里具體討論

文檔的格式

相對於內容，文檔的格式不重要。通常BP是用ppt形式，畢竟要跟管理層彙報。

MRD/PRD一般是用excel。

特別是PRD，最好是用excel，畢竟要包含很多細節內容，寫在ppt上很容易漏掉細節