MDVC框架:產品文檔最優雅的結構
![](http://image.woshipm.com/wp-files/img/38.jpg)
今天分享一個產品文檔的優雅結構:MDVC框架。供大家參考,與大家共勉!
區分概念
什么是PRD?什么是MRD?什么是BRD?這些問題都是老生常談的。我從整理了一些,供大家參考。
PRD
PRD(Product Requirement Document)產品需求文檔。PRD文檔是產品項目由“概念化”階段進入到“形象化”階段乃至執行階段的最主要的一個文檔,“對MRD中的內容進行指標化和技術化”。PRD的質量好壞直接影響到設計、研發以及測試等部門,是否能夠明確產品的功能和性能。
MRD
MRD(Market Requirement Document)即市場需求文檔。該文檔在產品項目中是一個“承上啟下”的作用,“向上”是對不斷積累的市場數據的一種整合和記錄,“向下”是對后續工作的方向說明和工作指導。產品項目由“準備”階段進入到“實施”階段的第一文檔,“對產品中規劃的某個產品進行市場層面的說明”,這個文檔的質量好壞直接影響到產品項目的開展,并直接影響到公司產品戰略意圖的實現。
BRD
BRD(Business Requirement Document)商業需求描述。基于商業目標或價值所描述的產品需求內容文檔(報告),其核心的用途就是用于產品在投入研發之前,由企業高層作為決策評估的重要依據。BRD是產品生命周期中最早的文檔,再早就應該是腦中的構思了,其內容涉及市場分析,銷售策略,盈利預測等,通常是供決策層們討論的演示文檔,一般比較短小精煉,沒有產品細節。
PRD、MRD、BRD之間的關系
- PRD要把MRD中的“產品需求”的內容獨立出來加以詳細的說明,而產品需求本身是在MRD中有所體現的。PRD銜接了設計、開發、測試與產品。一份好的PRD能夠很好的服務設計、開發以及測試人員。這也是本次文章的內容重點。
- MRD側重的是對產品所在市場、客戶(client)、購買者(buyer)、用戶(user)以及市場需求進行定義,并通過原型的形式加以形象化。
- 那么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翻譯成控制,不過在產品文檔撰寫過程中,我認為表示稱交互更貼切,這部分處理用戶交互,是解決頁面之間、控件和頁面之間、控件效果之間等的交互問題。
通常,交互負責幾部分能力:
- 一是從通過視圖向模型寫入數據,控制用戶輸入,向模型發送數據;
- 二是通過視圖向模型獲取數據,從模型獲得數據;
- 三是解決界面之間控件的動效,比如刷新、加載、點擊控件效果等。
適用范圍
目前,我認為采用MDVC框架撰寫文檔的方式,不但能夠在傳統web行業中適用,也能夠對移動應用的產品工作有比較大的幫助。
為什么用這個模型?
不清楚MRD,從而導致寫的大而全
在一些產品平臺有很多介紹些產品文檔的知識分享,但大多都是介紹得相當全的,這就會包含上面提到的三種文檔,甚至會包括開發文檔都會寫進去。這就造成文檔沒有重點,而且因結構不清晰相關人員閱讀起來也會很麻煩。
沒有很好的方法論體系,寫得不夠細致
MDVC框架,能夠很好的將產品分檔細分為產品定義、數據、界面以及交互四大部分——當然,一定情況下能夠擴展為多個部分。這樣就能夠很借助很好的框架撰寫產品文檔,又因為結構清晰,相關人員根據結構,很快就能夠定位到對應產品功能對應的點。
同時,由于細分結構清晰,在撰寫產品文檔過程中,相關人員只需要將單一部分完成,之后繼續撰寫其他部分,這就保證了高效的思考。在進行其他部分撰寫的同時,也能夠對前面的部分進行思考和調整。
MDVC框架有助于管理復雜的文檔撰寫過程,因為可以在一個時間內專門關注一個方面。例如,可以在不依賴業務邏輯的情況下專注于視圖設計。同時也讓應用程序的測試更加容易。MDVC框架也簡化了分組開發,不同的開發人員可同時開發視圖、控制器邏輯和業務邏輯。
模型修復
自己
需要自己不斷的思考和撰寫,并且在工作中多留心找到自己的不足。比如,我平時會用類似的方式記錄下來自己在撰寫文檔的時候有哪些不足,并且記錄是在MDVC框架的哪個環節出了問題。
舉一些例子:
- 進位展示方式;UI/交互部分
- 進位位置展示;UI部分
- 收藏問題:有關收藏和取消收藏、收藏作品被刪除等條件下,收藏數量的展示情況;產品部分
- 對需求的細致程度;產品部分,開發實現部分(需要開發反饋,調整文檔和需求)
- 及時修改文檔;產品部分
- 飛行排行和飛行紀錄數據計算方式了解的不夠細致;產品部分開發部分(數據獲得方式,客戶端計算還是服務端通過協議返回)
他人
通過開發、設計、測試等都能夠反饋給你很多寶貴的建議。比如需求評審環節,開發進行過程中,設計過程中,甚至測試過程中,這些相關人員的反饋,都有可能幫你修復產品文檔,從而不斷的幫你修復MDVC模型。
競品分析
單獨將這部分拿出來,目的是想強調一點:可以使用MDVC框架,分析競品。簡單地說就是通過功能,能夠分析出背后的邏輯,而不總是浮于表面。
模型的演化
AMDVC或GMDVC
即在MDVC模型的基礎上,增加了目標(Aim或者Goal),也就是文檔撰寫的目的,比如解決了什么問題,優化了什么問題等等
當然,大家可以在這個模型的基礎上繼續演化,形成自己的方法。
最后,與大家共勉!
本文由人人都是產品經理專欄作家@鄭幾塊 ?原創發布于人人都是產品經理?。未經本站許可,禁止轉載。
受教了,謝謝樓主
https://zhuanlan.zhihu.com/p/28526831
“MDVC框架”應用實例以及簡單了解
https://zhuanlan.zhihu.com/p/28526831“MDVC框架”應用實例以及簡單了解
來個案例才實在。要不然都是科普性的文案。
案例等找個時間在填補吧
很是期待,能提供模版或著樣例說明,這樣對初學者很有幫助的
樓主可以做個模板再提供一個樣例么?對新手來說更實際一些。
同感,求模板
回頭我補上 ??
我會增加到我的公眾號上去,這里估計由于審核發不出來