大厂方法论+案例:从0到1轻松拆解产品需求,对程序员的质疑说不
一、产品经理设计思路是什么样
面临新业务线拓展或者产品升级的时候,在收集到一大堆乱七八糟的需求后,你可能会想,我要怎么着手呢?答案是,搭框架找思路。
这是一个产品经理通用的设计思路框架,遵循由粗到细、自上而下的流程,具体如下:
- 战略层—–业务目标是什么,即定方向,含用户、使用终端、市场竞争力和解决方案、项目计划;想清楚做什么,即把具备价值的需求进行梳理优先级排序包括形成产品初步架构
- 搭框架—–(功能和DFX非功能框架)难点在于梳理功能的全面和思路;dfx需求:保证用户使用产品的安全、性能、可拓展等需求注:DFX其实很重要但大部分都会被忽视,此文不做拓展、后续会通过一篇文章进行详细说明,(产品经理千万不能只盯住功能做产品)
- 拆细节—–业务流程(重点梳理异常分支和外围数据交互)、业务操作、信息结构)
- 画界面—–交互设计、信息设计
以上的思路大家可以按需参考,本文着重讲解拆解2步骤的方法,即搭建初步功能框架,并可落地到原型指导设计。
二、如何搭建功能框架呢?
注:搭功能框架也是从宽度上定义业务范围,而不是要深挖细节、要注意避免陷入思路混乱、把握好分寸、见好就收。
1. 用例驱动设计法(UDD)
用例驱动设计是一种基于用户行为和需求来设计软件开发的方法,有步骤有层次梳理出系统功能的方法,可粗浅理解为用户故事,是一个通用的搭框架方法;如类似网购下单、酒店预定、银行贷款等场景;
整体思路遵循:识别参与者使用场景及问题—–定义描述用例(目标层用例—步骤层用例—-实现层用例)并简化
(1)识别使用场景及问题
首先,我们通过华为IPD需求管理思路那篇,知道产品需求=基于场景的解决方案,因此拿到一个产品需求,我们需要想清楚对应的场景,即5w1h1e。
who(面向对象)、why、when+where(场景)、what(干什么)、以及how(怎么实现)、else(限前置和后置)
比如要做一个访客预约系统,按照上面的描述方法,我们明白了系统的使用场景是这样:
一个基于外来访客,由于园区为了保障安全管理,在临时进入园区前,需要进行线上登记个人资料、并实名认证的产品,并且园区审核通过,验证身份才可以进入和离园。
(2)拆分:目标层-步骤层-实现层
结合上面的例子:
访客进入园区就是目标层用例,为了实现这个整体目标,我们需要步骤层用例进行支撑,这时候就可以拆分为第一个大框架
具体为:
步骤1:访客在系统上提前登记—–线上预约
步骤2:访客填写登记资料—–填写表单
步骤3:园区通过系统审核资料并通知访客结果—–审核管理
步骤4:访客接收通知—-消息提醒
步骤5:访客查看提交记录—–预约记录
步骤6:访客获得许可进入园区—身份验证
步骤7:访客离园确认—身份验证
那针对每一个步骤层、具体如何实现呢?按照这个思路,通过拆分形成实现层用例(也就是用什么方案实现)
最终这个功能框架会形成这样、(注意把不同用户端分开保证用例全面)如图:
当然这是初步框架,仅作部分举例说明,你们可以自行拓展,只要保证覆盖全部的用例就行。
在这里,我们要注意几点:
在多种实现方案并存的情况下,如何权衡呢?
1、结合功能实现成本、第三方对接周期、客户需要、技术实现能力、外围的交互模块等多方面因素进行决策,选择一个较为合理的实现方案:
2、如上面的进出身份验证,给了4种方案,有通行扫码、临时卡、人脸识别、指纹、语音,包括我们常见的支付也可以多种路径实现,如现金支付、信用卡支付、微信支付等
小结:
1、工具:建议用思维导图、或者用例图进行梳理
2、目标:是形成产品功能结构(含一级特性、二级特性、甚至三级特性)
3、适用项目:比较独立、小型或需要快速迭代和更新的项目,注重从用户的角度出发来描述系统的功能需求
4、特点:方便快捷、拓展性较差、易于理解协作,但难以适用复杂业务
2. 流程驱动设计法(PDD)
适用于业务协作方较多,具备较复杂的业务层级及审核,更注重流程标准化管理的产品,如CRM、ERP系统、工单管理系统、采购系统、数据精细管理等。
整体思路遵循:识别关键业务流程—–拆分目标层用例—–业务操作
比如CRM系统的流程是有明显前后顺序的,且为了精准做好客户关系管理,标准化的流程非常重要。通常按照以下步骤进行操作:
1、客户档案创建和维护—–客户管理流程
2、销售机会(Lead)创建和跟进——销售管理流程
3、市场活动的策划、执行和跟进——-市场活动管理流程
结合以上顺序流程,就很适合用PDD来搭框架,我们大概拆分出几个目标层,并进一步落地到具体的功能模块中。下面是一些可能包括的模块:
客户管理模块:
a. 客户档案:创建、查看、编辑、删除客户资料;
b. 客户分类:对客户进行分组和标记,例如根据客户来源、优先级、交易状态等进行分类;
c. 客户关系历史记录:记录客户与企业之间的活动历史,包括通话、邮件、漏斗进展等。
销售管理模块:
a. 销售机会(Leads):创建、跟进、评估及关闭销售机会,可以关联相关的客户信息;
b. 产品/服务信息:录入、查看、编辑和删除产品或服务信息;
c. 报价单/订单:创建、发送、听取意见、确认并完成报价和订单交付等流程;
d. 合同信息:建立一个合同管理库存储合同信息,以追踪合同执行情况和收款计划。
市场活动管理:
a. 活动策划:创建市场活动,定义主题,摘要、预算、时间表等参数;
b. 活动跟踪:批量创建活动推广计划来实现对活动方案的执行,包括在线广告、email、电话营销等;
c. 活动分析:记录活动成效,比如邮件打开率、转化率等进行绩效统计,以及对活动与销售数据的关系分析。
在设计过程中,功能模块要尽量紧密贴合上述CRM系统的整体流程,具体实现时,也可依据企业的运营或者工作方式进行特定的定制。
例如,在某些企业中市场活动管理可能更为重要,根据不同的客户属性,社交媒体营销方式有些偏年轻化公司会利用大量互联网和移动设备,而传统行业的企业上门拜访更常见。
小结:
1、适用项目:PDD适用于更大型、复杂或需要对业务流程进行全面分析和优化的项目。
2、工具:UML流程图、状态图等
3、优点:帮助理清内部系统数据、业务流程,基于过程建模,从整体到局部深度设计,复杂业务简单化
4、缺点:过于关注流程,导致各个子系统业务耦合较高,难以实现拓展
3. 领域驱动设计(DDD)
领域驱动设计(Domain-Driven Design,DDD)是由领域驱动设计之父埃里克·埃文斯提出的,涵盖面较广,其核心思想是先梳理领域信息结构和业务规则,再梳理业务的用例、流程和操作等内容。
整体思路遵循:确定场景领域—-识别核心领域对象(信息结构)—-业务规则(定义对象之间的属性关系及行为)—–其他模块的交互
举例:场景领域—-电子商务平台
我们识别到的核心对象为:
- 商品管理:包括商品信息的管理、上架、下架、分类、标签等。
- 订单管理:包括订单的生成、查询、修改、删除等。
- 用户管理:包括用户信息的注册、登录、个人信息维护等。
- 支付管理:包括各种支付方式的接入、支付状态的管理和处理等。
- 物流管理:包括订单状态的跟踪、配送信息的记录、快递单信息的管理等。
- 售后服务:包括退换货的处理、客户服务的管理、投诉反馈的处理等
这里以订单管理为例,用类图表达信息结构。
信息结构表述了信息内容之间的关系。这种关系可以用类图(Class Diagram)来表达。
该图片来源于图书【“图解”产品:产品经理业务设计与UML建模】作者擎苍
当我们使用类图来识别领域模型和实体关系后,需要根据业务需求和限制条件定义对象、属性、操作业务规则和流程,如买家只能在特定时间段内下单,不能重复购买同样的商品;订单满足3人立刻成团进入待支付;订单超时未支付自动取消等。
最后,在实现层,我们需要识别系统内的其他部分或与系统交互的部分,并确定他们对业务领域的影响。比如,与支付相关的银行接口、第三方支付接口、物流跟踪动态数据的集成等都是我们必须考虑的。
小结:
- 适用行业:复杂且灵活多变的行业需求,开发此软件的公司,通常是行业的引领者,如中台等大型团队项目
- 工具:UML类图、思维导图
- 优点:低耦合可扩展、能灵活应对复杂业务变更需求、可增强代码质量
- 缺点:团队技能要求高、时间成本高、协调难度高、编码量增加(长期来看是值得的)
注:通过选择合适的方法论,我们完成了产品设计第2步:搭框架,后续再通过第3步拆细节,重点梳理各分支下的异常流程,逐步完善细节,最后一步,再进行页面信息收集填充,剩下的就是画原型了,此处不做展开。
三、面对不同项目,如何选择?
综上,通过以上3种搭功能框架的方法论,我们知道,产品设计方法论,包含用例驱动设计发(UDD)、流程驱动设计法(PDD)、领域驱动设计法(DDD),我们来整体再做个对比总结,通过以下维度进行决策,方便我们在具体的项目设计中,选择较为合适的方法。
当然,他们各自有优缺点,在一个项目里,完全可以结合交叉使用。
四、拆解需求需要具备的能力和思维
- 设计思维:清晰的产品设计思路、并形成自己的通用方法论,掌握并应用(如上面的3种方法)、包括其他的成熟模型(如AARRR模型…)
- 设计方案:内心要有很多成熟可用的方案思维和评估方案的能力,就需要多练多看、多去关注一些最新的技术,不然没法梳理框架里具体都包含什么,怎么实现
- 深度思考能力:多使用结构化思维培养深度思考能力、体现在异常流程、外围数据交互处理上(平时要多观察竞品、多问几个为什么、包括开发阶段潜在的问题、面对开发的质疑才可以真正说不)
- 最佳的UI感及交互设计能力(审美、人机交互最佳策略)
- 工具使用能力:巧用UML建模,事半功倍(重点关注类图、用例图、状态图、流程图)、还有其他思维导图等
五、其他想说的话
本文的重点是教大家如何通过成熟的方法论,拆解需求指导原型设计,在写的时候,里面其实包含了很多知识点,并没有展开:
比如最容易被忽视的DFX需求:UDD、PDD、DDD3种方法论如何灵活保证系统的DFX需求,这部分产品经理必须有相应地思考和考量,不能老是产品做了用不起来或者代码混乱、后面维护难、迭代难……
UML建模能力的学习:高效辅助产品经理工作,梳理需求和团队协作、包括作为评审材料后期可进行系统设计检视,很值得研究运用,但不是都要学;
再比如产品设计由静态到动态,框架的各个模块之间如何进行交互设计关联;页面信息结构怎么收集并合理展示……..
后续我也会慢慢整理总结、输出。
最后,我们还可以问自己一个问题,从程序员角度,逆向考虑下,程序员拿到一个需求,都是怎么拆解并实现的?
或许你会知道,你设计的功能是不是相对完美的。
本文作者@凯拉Kella 。
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!