MDVC框架：产品文档最优雅的结构

今天分享一个产品文档的优雅结构：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）