产品经理们如果站在用程序员的思维去思考需求并完成PRD文档,运用MVC模式进行产品设计,那么程序员就能够更好地理解需求,那些不必要的撕逼也会减少许多。 每一位程序猿心中都有一个理想,那就是有一天不再需要coding,每一位产品狗心中也有一个理想,那就是自己会coding多好。产品经理和程序猿难道就是这样矛盾的两个群体? 据不完全统计,产品经理与程序猿的撕逼案例中,引起撕逼的原因有: 频繁改需求、需求不明确、逻辑不清晰、无法实现…等等。 但是问题的根本原因还是产品经理和程序员的思维方式不同,如果产品经理们用程序员的思维去思考需求并完成PRD文档,应该会让程序员们更好的理解吧。 MVC简介 今天给大家谈谈程序开发中的MVC(Model-View-Controller)模式如何体现在产品设计中。 MVC模式作为软件工程的经典架构模式,已经被广泛应用到实际软件开发中,现在主流的开发框架(如Spring、Struts2等)都是采用了MVC的设计思想。简要介绍一下MVC模式: 模型(Model):模型代表业务数据和业务规则,是应用程序的主体; 视图(View):视图表示用户看到并与之交互的页面; 控制器(Controller):控制器接受用户的输入,并调用模型和视图去完成用户的需求。 产品层面的对比 这些内容似乎太抽象,在产品层面如何体现呢? 下面就按照我们分析需求、设计产品时需要考虑的点,介绍产品层面的MVC模式: 产品Model:同样是业务数据和业务规则,举个栗子:注册表单的设计,产品经理考虑注册需要哪些字段,这些字段中哪些是必填项,每项的最大输入长度,是否允许输入字母和数字等,这些就是数据和规则,即模型层; 产品View:用户看到并与之交互的界面,产品在这一层需要考虑界面的布局,比如按钮的摆放位置、如何突出重点内容、如何让用户更少的思考和点击,这些是视图层需要考虑的; 产品Controller:控制层调用模型和视图完成用户的需求,还用注册的例子,用户输入需要填写的字段,点击注册按钮,如果注册成功跳转哪个页面,如果不成功给用户什么提示,都需要调用模型中的数据和规则在视图中展示给用户,这就是控制层。 MVC在你的PRD中如何体现 每个产品经理的日常工作是离不开PRD的,PRD文档的质量直接影响整个团队的工作效率。每个公司的PRD文档规范都不一样,但是在PRD中需要展现的内容几乎是差不多的。 Model:产品涉及的数据(或者字段)以及对应的业务规则,比如在PRD中描述订单模块时,订单的所有状态需要全部罗列,每个状态下用户可以进行什么操作,每一步操作需要展示的数据及来源,这些是PRD中的model。 View:在PRD中,View很容易就会想到页面原型,低保真或高保真都可以。这一层需要考虑产品在各种情况下页面的展示,比如同样一个页面在正常情况、无网环境的展示,界面要始终保持友好。 Controller:PRD中的控制层即交互和流程,这是许多产品经理容易忽视的内容。PRD中有数据和原型是不够的,必须加上详细的流程图,才能将数据和原型页面贯穿始终。流程图也分以下几类:业务流程图、任务流程图和逻辑流程图,这三者是递进关系,后一个对前一个流程在逻辑上进行细化。对于比较复杂的模块,建议PRD中都加入这三种流程图。 产品的MVC模式,不是什么新内容,只是将日常工作的内容进行了总结和提炼,并结合程序猿熟悉的模式进行对比讲解,产品经理就是需要站在不同人群的角度思考问题,希望这篇文章能够给部分产品经理以帮助~