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之间的关系

1、PRD要把MRD中的“产品需求”的内容独立出来加以详细的说明,而产品需求本身是在MRD中有所体现的。PRD衔接了设计、开发、测试与产品。一份好的PRD能够很好的服务设计、开发以及测试人员。这也是本次文章的内容重点。

2、MRD侧重的是对产品所在市场、客户(client)、购买者(buyer)、用户(user)以及市场需求进行定义,并通过原型的形式加以形象化。

3、那么BRD的作用,就是决定了你的项目的商业价值。PRD、BRD和MRD,一起被认为是从市场到产品需要建立的文档规范。

好了,铺垫差不多了,应该能让大家(包括我自己)对PRD、MRD、BRD的概念和关系有了一定的认知。那,我们开始进入正题吧。

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

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,从而导致写的大而全

我在wordpm中提问过《你是用什么结构写产品文档的?》,另外在一些产品平台大多也有介绍些产品文档的知识分享,但大多都是介绍得相当全的,这就会包含上面提到的三种文档,甚至会包括开发文档都会写进去。这就造成文档没有重点,而且因结构不清晰相关人员阅读起来也会很麻烦。

没有很好的方法论体系,写得不够细致

MDVC框架,能够很好的将产品分档细分为产品定义、数据、界面以及交互四大部分——当然,一定情况下能够扩展为多个部分。这样就能够很借助很好的框架撰写产品文档,又因为结构清晰,相关人员根据结构,很快就能够定位到对应产品功能对应的点。

同时,由于细分结构清晰,在撰写产品文档过程中,相关人员只需要将单一部分完成,之后继续撰写其他部分,这就保证了高效的思考。在进行其他部分撰写的同时,也能够对前面的部分进行思考和调整。

MDVC框架有助于管理复杂的文档撰写过程,因为可以在一个时间内专门关注一个方面。例如,可以在不依赖业务逻辑的情况下专注于视图设计。同时也让应用程序的测试更加容易。MDVC框架也简化了分组开发,不同的开发人员可同时开发视图、控制器逻辑和业务逻辑。

修复框架

自己

需要自己不断的思考和撰写,并且在工作中多留心找到自己的不足。比如,我平时会用类似的方式记录下来自己在撰写文档的时候有哪些不足,并且记录是在MDVC框架的哪个环节出了问题。

举一些例子:

进位展示方式;UI/交互部分

进位位置展示;UI部分

收藏问题:有关收藏和取消收藏、收藏作品被删除等条件下,收藏数量的展示情况;产品部分

对需求的细致程度;产品部分,开发实现部分(需要开发反馈,调整文档和需求)

及时修改文档;产品部分

飞行排行和飞行纪录数据计算方式了解的不够细致;产品部分开发部分(数据获得方式,客户端计算还是服务端通过协议返回)

他人

通过开发、设计、测试等都能够反馈给你很多宝贵的建议。比如需求评审环节,开发进行过程中,设计过程中,甚至测试过程中,这些相关人员的反馈,都有可能帮你修复产品文档,从而不断的帮你修复MDVC模型

竞品分析

单独将这部分拿出来,目的是想强调一点:可以使用MDVC框架,分析竞品。简单地说就是通过功能,能够分析出背后的逻辑,而不总是浮于表面。

框架的演化

AMDVC或GMDVC

即在MDVC模型的基础上,增加了目标(Aim或者Goal),也就是文档撰写的目的,比如解决了什么问题,优化了什么问题等等

当然,大家可以在这个模型的基础上继续演化,形成自己的方法。

最后,与大家共勉!

你可能感兴趣的:(MDVC框架:产品文档最优雅的结构)