今天分享一个产品文档的优雅结构：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），也就是文档撰写的目的，比如解决了什么问题，优化了什么问题等等
当然，大家可以在这个模型的基础上继续演化，形成自己的方法。
最后，与大家共勉！