今天分享一個產品文檔的優雅結構：MDVC框架。供大家參考，與大家共勉！

區分概念

什么是PRD？什么是MRD？什么是BRD？這些問題都是老生常談的。我從整理了一些，供大家參考。

PRD

PRD（Product Requirement Document）產品需求文檔。PRD文檔是產品項目由“概念化”階段進入到“形象化”階段乃至執行階段的最主要的一個文檔，“對MRD中的內容進行指標化和技術化”。PRD的質量好壞直接影響到設計、研發以及測試等部門，是否能夠明確產品的功能和性能。

MRD

MRD（Market Requirement Document）即市場需求文檔。該文檔在產品項目中是一個“承上啟下”的作用，“向上”是對不斷積累的市場數據的一種整合和記錄，“向下”是對后續工作的方向說明和工作指導。產品項目由“準備”階段進入到“實施”階段的第一文檔，“對產品中規劃的某個產品進行市場層面的說明”，這個文檔的質量好壞直接影響到產品項目的開展，并直接影響到公司產品戰略意圖的實現。

BRD

BRD（Business Requirement Document）商業需求描述?；谏虡I目標或價值所描述的產品需求內容文檔（報告），其核心的用途就是用于產品在投入研發之前，由企業高層作為決策評估的重要依據。BRD是產品生命周期中最早的文檔，再早就應該是腦中的構思了，其內容涉及市場分析，銷售策略，盈利預測等，通常是供決策層們討論的演示文檔，一般比較短小精煉，沒有產品細節。

PRD、MRD、BRD之間的關系

1. PRD要把MRD中的“產品需求”的內容獨立出來加以詳細的說明，而產品需求本身是在MRD中有所體現的。PRD銜接了設計、開發、測試與產品。一份好的PRD能夠很好的服務設計、開發以及測試人員。這也是本次文章的內容重點。
2. MRD側重的是對產品所在市場、客戶（client）、購買者（buyer）、用戶（user）以及市場需求進行定義，并通過原型的形式加以形象化。
3. 那么BRD的作用，就是決定了你的項目的商業價值。PRD、BRD和MRD，一起被認為是從市場到產品需要建立的文檔規范。

好了，鋪墊差不多了，應該能讓大家（包括我自己）對PRD、MRD、BRD的概念和關系有了一定的認知。那，我們開始進入正題吧。

產品文檔最優雅的結構是？

MDVC框架，是我在MVC框架的基礎上增加了D（Data）的環節衍生出來的。

眾所周知，MVC全名是Model View Controller，是模型（Model）－視圖（View）－交互（Controller）的縮寫，一種軟件設計規范，用一種業務邏輯、數據、界面顯示分離的方法組織代碼，將業務邏輯聚集到一個控件里面，在改進和個性化定制界面及用戶交互的同時，不需要重新編寫業務邏輯。MVC被獨特的發展起來用于映射傳統的輸入、處理和輸出功能在一個邏輯的圖形化用戶界面的結構中。

增加D（Data）的環節，是為了體現數據的重要性，而數據有兩大類型：已有數據和新產生數據。

簡單說，MDVC模式，是模型（Model）——數據（Data）——視圖（View）——交互（Controller）的過程。接下來我們分開講解整個過程以及過程之間的銜接。

模型（Model）

開發過程中，Model（模型）是應用程序中用于處理應用程序數據邏輯的部分。通常模型對象負責在數據庫中存取數據。在撰寫文檔過程中的Model，主要講的是對產品以及產品功能的定義。這一點，與《用戶體驗要素》中的框架類似，但又不完全一致。

可以說這是文檔撰寫過程中的模型一個提綱挈領的框架，也就是“我朝著這個方向做”，也會出現“為什么朝著這個方向做（后面會提到）”。沒有任何邏輯細節，也但沒有任何其他細節，“而不會說怎么做”。后面的數據、視圖、交互等，都是在這個框架下完成的。

數據（Data）

在Model（模型）的基礎上，考慮產品所需要的數據。上面提到過，數據有兩大類型：已有數據和新產生數據。相對應的，這部分就是考慮兩方面：

• 一是已有數據是從哪來的，以及如何使用已有數據；
• 二是，新產生的數據，是什么數據，如何定義數據。

而新產生的數據也有兩類，一類是通過已有數據的整合而來，一類是完全意義上的新產生。已有數據整合以及新產生的數據需要自己部門內解決，也有可能需要跨組、跨部門，甚至是夸公司級別的合作等等。

視圖（View）

View（視圖）也就是產品的UI，是對M（Model）以及D（數據）的展示和處理，是應用程序中處理和展示數據，以及相關控件的部分，通常視圖是依據模型以及數據創建的。視圖主要解決的是展示什么，以及如何展示的問題。

交互（Controller）

在開發過程中，C翻譯成控制，不過在產品文檔撰寫過程中，我認為表示稱交互更貼切，這部分處理用戶交互，是解決頁面之間、控件和頁面之間、控件效果之間等的交互問題。

通常，交互負責幾部分能力：

1. 一是從通過視圖向模型寫入數據，控制用戶輸入，向模型發送數據；
2. 二是通過視圖向模型獲取數據，從模型獲得數據；
3. 三是解決界面之間控件的動效，比如刷新、加載、點擊控件效果等。

適用范圍

目前，我認為采用MDVC框架撰寫文檔的方式，不但能夠在傳統web行業中適用，也能夠對移動應用的產品工作有比較大的幫助。

為什么用這個模型？

不清楚MRD，從而導致寫的大而全

在一些產品平臺有很多介紹些產品文檔的知識分享，但大多都是介紹得相當全的，這就會包含上面提到的三種文檔，甚至會包括開發文檔都會寫進去。這就造成文檔沒有重點，而且因結構不清晰相關人員閱讀起來也會很麻煩。

沒有很好的方法論體系，寫得不夠細致

MDVC框架，能夠很好的將產品分檔細分為產品定義、數據、界面以及交互四大部分——當然，一定情況下能夠擴展為多個部分。這樣就能夠很借助很好的框架撰寫產品文檔，又因為結構清晰，相關人員根據結構，很快就能夠定位到對應產品功能對應的點。

同時，由于細分結構清晰，在撰寫產品文檔過程中，相關人員只需要將單一部分完成，之后繼續撰寫其他部分，這就保證了高效的思考。在進行其他部分撰寫的同時，也能夠對前面的部分進行思考和調整。

MDVC框架有助于管理復雜的文檔撰寫過程，因為可以在一個時間內專門關注一個方面。例如，可以在不依賴業務邏輯的情況下專注于視圖設計。同時也讓應用程序的測試更加容易。MDVC框架也簡化了分組開發，不同的開發人員可同時開發視圖、控制器邏輯和業務邏輯。

模型修復

自己

需要自己不斷的思考和撰寫，并且在工作中多留心找到自己的不足。比如，我平時會用類似的方式記錄下來自己在撰寫文檔的時候有哪些不足，并且記錄是在MDVC框架的哪個環節出了問題。

舉一些例子：

• 進位展示方式；UI／交互部分
• 進位位置展示；UI部分
• 收藏問題：有關收藏和取消收藏、收藏作品被刪除等條件下，收藏數量的展示情況；產品部分
• 對需求的細致程度；產品部分，開發實現部分（需要開發反饋，調整文檔和需求）
• 及時修改文檔；產品部分
• 飛行排行和飛行紀錄數據計算方式了解的不夠細致；產品部分開發部分（數據獲得方式，客戶端計算還是服務端通過協議返回）

他人

通過開發、設計、測試等都能夠反饋給你很多寶貴的建議。比如需求評審環節，開發進行過程中，設計過程中，甚至測試過程中，這些相關人員的反饋，都有可能幫你修復產品文檔，從而不斷的幫你修復MDVC模型。

競品分析

單獨將這部分拿出來，目的是想強調一點：可以使用MDVC框架，分析競品。簡單地說就是通過功能，能夠分析出背后的邏輯，而不總是浮于表面。

模型的演化

AMDVC或GMDVC

即在MDVC模型的基礎上，增加了目標（Aim或者Goal），也就是文檔撰寫的目的，比如解決了什么問題，優化了什么問題等等

當然，大家可以在這個模型的基礎上繼續演化，形成自己的方法。

最后，與大家共勉！

本文由人人都是產品經理專欄作家@鄭幾塊 ?原創發布于人人都是產品經理?。未經本站許可，禁止轉載。