在庄子的《南华经》中有1则寓言。说是有位叫丁的厨师,替梁惠王杀牛,其技法之纯熟,有行云流水1般的顺畅感。惠王就问他为何有如此高超的技术。他回答说:“臣所喜好的是『道』,早就超出所谓的技术了。最初臣杀牛的时候,眼里看到的都是『完全的牛』;3年以后眼中就再看不到『完全的牛』。到了现在,臣以精神接触,而不用眼睛看牛,视觉感官停止了而精神在活动。按天然的道理,击入牛筋骨的缝隙,顺着筋骨的空洞进刀,依照它本来的构造,牛的筋骨接合的地方,臣都未以刀刃碰到过,而何况是大骨头呢!”
一样的道理。当我们在面对1头牛——复杂的业务需求时,如果不得其构造,不明其法,是不能够很好的拆解的。只有对需求深入了解,依照其本来的构造,在筋骨的缝隙处下刀,才能拆出不错的用户故事。今天在这里,就给大家介绍1些解牛之法。非『道』,唯术尔。
工作流系统
我们平时常常会接触到工作流类的系统。所谓工作流,就是我在完成1件工作的进程中,需要经过量个步骤,可能还会有多个不同的角色参与。对这类系统,我们1般有两种方式 —— 横切和纵切。
1、横切
所谓横切,就是先切分出工作流中核心且轻浮的1层,然后再去实现各个步骤中的细节部份。这对那些核心业务逻辑比较简单、但每一个步骤的附属功能多且复杂的工作流系统来讲比较适用。
(横切示例)
举个例子:
假设现在我们需要做1个商旅订票系统,其简化的订票流程以下图所示:
(携程商旅的工作流案例)
在这个流程中,每一个步骤都包括了很多个功能。比如“会员查找需要预定的航班”这1步,会员的需求可能会包括:
- 根据起始城市搜索航班
- 根据选择的城市,找出最近的机场所在城市
- 使用GPS定位所在城市
- 翻转起止城市
- 根据航班号选择航班
如果采取横切的话,我们仅会选取让本流程可以工作的最小故事集,如:根据起始城市搜索航班。
乃至,在本故事中,我们可以设置会员仅能通过精确输入起落地城市名称的方式,来进行航班搜索,在不影响本步骤走通的情况下,来最小化这个步骤的工作量。其它的流程也使用一样的策略,来加速买通全部业务流程。
横切的优势在于可以快速实现核心逻辑,并快速上线,验证假定并搜集反馈,可以根据反馈的结果来决定每一个步骤中的功能应当如何设计、优先级是甚么,来避免1些可能出现的浪费。缺点在于全部工作流设计会采取短平快的原则,用户体验较差。
2、纵切
另外一种方式是纵切。纵切就是依照工作流中的每个步骤进行切分,这样可使每个步骤都具有相对完善的功能,这在某些需要关注终端用户交互体验的产品中利用较多。注意,这里有个技能:如果在全部工作流中,需要跟终端用户进行交互的功能仅出现在某几步中,如第1步和最后1步,而中间的N⑵步都是后台流程,在开发中,我们可以先实现第1步和最后1步的功能,而中间的流程处理环节,依然采取逐渐线上化的方式,这样可使全部工作流系统最快的上线,同时能平衡用户的交互体验。
(纵切)
比如上面携程商旅订票系统的例子,我们可以把触及终端用户操作的步骤:
- 会员查找航班
- 会员发起订票申请
- 公司审批人审批订票申请
- 会员收到订票成功通知
把这几个步骤拆出来优先实现,尽早上线;而中间的跟票务相干的步骤,依然采取线下的情势。比如工作人员在携程商旅后台,把定单导出到excel表中,人肉打电话给票代,再把票代肯定的订票信息填入系统,然后手动通知会员。这类方式对1些流程复杂但用户量较小的初创公司比较适用,可以在保证用户体验的情况下,大大提升产品上线速度,并下降试错本钱。
在这里要注意的是,不论是横切还是纵切,工作流中的每个步骤都会遵守80/20法则,也就是20%的功能决定了这个步骤的核心价值,而80%的功能仅仅是锦上添花的,所以我们需要更深入地研究客户的真正需求是甚么,提炼出这20%的业务价值到底在哪里,从而进行更加公道的拆分。
功能模块拆分
对已拆出的功能模块,依然可以根据1些方法进行进1步的拆分,这里介绍3个方法。
1、按业务规则拆分
一样的流程和操作,由于输入的数据业务规则不同,因此进行数据处理时采取的方式也不同。对这样的情况,我们可以把功能依照业务规则来进行拆分。
典型的例子是搜索引擎,比如Google。在Google中,输入框只有1个,但Google会根据你所输入的数据规则的不同,来进行不同的处理操作。看下面几种情况:
- 在Google搜索框中输入1个关键字,得到这个关键字相干的搜索结果
- 在Google搜索框中输入1个算式,如“ 1+1=”,得到算式的结果
- 在Google搜索矿中输入“ThoughtWorks site:www.example.com”,得到在www.example.com这个站点中出现ThoughtWorks的页面
- …
对这样的情况,我们可以把每个业务规则都单独拆分成1个用户故事。固然,虽然这些用户故事看起来很类似,但是大部份情况下,这些规则的优先级是截然不同的。总会有1簇最高优先级的用户故事和围绕在外围的用户故事。比如在这个例子中,对Google来讲,支持关键字搜索1定是最高优先级的,需要在产品设计的1开始就要实现,而能够计算算式的,可能很多年以后,才开始斟酌加这样1个功能。
2、1+N模式
第2种情况,是对一样1个流程,在终端接不同的网关或渠道。最典型的例子是在线支付。比如,我在京东上买了1盒磁力橡皮泥,提交定单进入支付流程,在支付页面可以选择微信支付、京东支付、银行卡支付等等。
第1次实现支付的功能,可能会比较复杂,但后面如果从1种扩充到多种支付方式,就相对照较简单。而且最早需要支持甚么样的支付方式,你可能在1开始也拿不定主张。这个时候,我们无妨将支付功能拆成2张卡,形如
- 会员可使用微信支付/京东支付/网银支付中的1种进行支付
- 会员可使用微信支付/京东支付/网银支付3种渠道进行支付
使用这类拆分方法,可以延迟决策-我们需要最早支持哪一种支付方式,同时公道的评估项目的工作量。
3、复杂的业务模型拆分
对有的系统,业务模型可能会非常复杂,比如1个房产交易平台中的房产信息,可能包括户型信息、中介信息、地理位置信息、价格及购买相干的税率信息、展现图、效果动画等等,当我们需要在系统中引入这样1个业务模型时,如果1上来就要斟酌清楚这个业务模型的各个方面,是个性价比很低的事情——做了很多作业,但没有给客户带来真实的业务价值。
这个时候,我们需要将业务模型,依照我们实际需要提供的功能进行拆分。比如,我们要做1个中介搜索系统,可以仅取出模型中的中介信息,而不需要处理其它部份。即便我们需要全部业务模型去做1些事情,也能够把其拆成1个个子模型,根据子模型的业务价值及优先级去设计相应的功能。
比如在这个例子中,我们需要对房产的信息做展现
- 对户型信息,需要有户型图,户型相干的文案展现
- 对中介信息,可以看到中介人的头像、联系方式,可使用多种方式在线联系中介代理
- 对地理信息,我可以在Google Map上查看其地理位置,并能够从我的位置导航过去
- 对展现的图片和动画,我需要像幻灯片1样,可以在页面上播放
- ……
那末,如果我们1开始就着手于解析这个房产业务模型,那可能浪费了很多时间,而没有交付对用户有价值的业务功能。这个时候,我们需要辨别哪些信息是核心信息,是对用户来讲最有价值的,把这些信息从业务模型中提取出来,而后设计相应的更小的业务功能,切忌一挥而就。
需求拆分是不是有1套完善的方法?
需求拆分是没有银弹的,要根据具体的场景、限制来选择适合的拆分方法。在遇到使用某个拆分方法,不能满足当前业务需求时,看看是否是可以换个思路,换个方法。
固然,在选择拆分方法时,也有1些技能,如
- 基于80/20法则,选择那些可以拆出低优先级卡片(或可以被扔掉的卡片)的拆卡法。
- 选择可以把卡片拆的大小差不多的方法,未来在发布计划中更容易做需求置换
- 选择开发团队更容易理解和实现的方式
固然,这1定不全面,每一个人在不同的场景、限制条件下,都会有不同的技能。相信你自己的拆分方法,多与团队成员沟通才是不变的法门。
以终为始-故事验收方法
Bill Wake提出了1个好用户故事的验收标准——INVEST模型,它由6个单词的首字母组成,分别是
- Independent:每一个用户故事应当是独立的,不会和其他用户故事产生耦合
- Negotiable:其实不会非常明确的论述功能,细节应带到开发阶段跟程序员、客户来共同商讨
- Valuable:每个用户故事的交付都要能够给用户带来用户价值
- Estimable:不需要能够准确的估计,但需要能辅助客户排定优先级
- Small:要小1点,但不是越小越好,要大小适合,可以更容易的圈定故事范围
- Testable:需要能够进行验收测试,最好能把Test Case提早加进去
这不单单是故事的验收原则,更是在进行需求拆分的时候所需要斟酌的拆分原则。固然,凡事有例外。在需求拆分中,有时会拆出1些实在不能满足INVEST原则的故事卡片,也不要太纠结,我们寻求完善,但也总要接受现实的不完善。这个时候,跟开发团队多交换,开辟思路,调和1个比较好的拆分方式,比自己1个人憋大招要好的多。
最后
再介绍几个反模式。
- 依照技术架构分层进行拆分,常见的会依照持久层、利用层、展现层进行拆分。这类拆分方式拆出来的用户故事,会明显破坏INVEST中的Valuable的原则,而且各个故事卡由于各方面的缘由,如开发进度不统1,没法灵活的集成上线。
- 拆分时,把复杂的UI交互算在故事卡片中。大部份情况下,比较fancy的UI交互都不是核心的业务功能,这部份功能可以作为用户体验优化的卡片,独立拆出来。
- 拆分时,过早斟酌性能问题。在性能基本达标、不出现大问题的情况下,提升性能很多情况下也属于用户体验的1部份,可以单独拆出来,左右优化卡片。
- 拆出1些管理类的卡片。比如管理产品,实际上可能包括很多产品相干的操作,如导入、编辑、同步信息、改变状态、上架、下架等,所以应当根据具体的功能,拆分成更加准确和大小适合的故事卡片。
欧阳修在《卖油翁》中,提到1个老翁,在倒油时能通过铜钱中心的方孔,却不洒1滴油,大家都很惊叹,他只说了1句话——“无他,但手熟尔”。需求拆分也1样,并没有甚么精深的学问,拆的次数多了,也便有了那份手熟。
作者:张久坤
来源:人人都是产品经理