庖丁解牛：如何做产品需求分析

当我们在面对一头牛——复杂的业务需求时，如果不得其构造，不明其法，是不能够很好的拆解的。只有对需求深入了解，按照其本来的构造，在筋骨的缝隙处下刀，才能拆出不错的用户故事。今天在这里，就给大家介绍一些解牛之法。

在庄子的《南华经》中有一则寓言。说是有位叫丁的厨师，替梁惠王杀牛，其技法之娴熟，有行云流水一般的顺畅感。惠王就问他为什么有如此高超的技术。他回答说：“臣所喜好的是『道』，早就超越所谓的技术了。最初臣杀牛的时候，眼里看到的都是『完整的牛』；三年之后眼中就再看不到『完整的牛』。到了现在，臣以精神接触，而不用眼睛看牛，视觉感官停止了而精神在活动。按天然的道理，击入牛筋骨的缝隙，顺着筋骨的空洞进刀，依照它本来的构造，牛的筋骨接合的地方，臣都未以刀刃碰到过，而何况是大骨头呢！”

同样的道理。当我们在面对一头牛——复杂的业务需求时，如果不得其构造，不明其法，是不能够很好的拆解的。只有对需求深入了解，按照其本来的构造，在筋骨的缝隙处下刀，才能拆出不错的用户故事。今天在这里，就给大家介绍一些解牛之法。非『道』，唯术尔。

工作流系统

我们平时经常会接触到工作流类的系统。所谓工作流，就是我在完成一件工作的过程中，需要经过多个步骤，可能还会有多个不同的角色参与。对于这种系统，我们一般有两种方式 —— 横切和纵切。

1、横切

所谓横切，就是先切分出工作流中核心且轻薄的一层，然后再去实现各个步骤中的细节部分。这对于那些核心业务逻辑比较简单、但每个步骤的附属功能多且复杂的工作流系统来说比较适用。

（横切示例）

举个例子：

假如现在我们需要做一个商旅订票系统，其简化的订票流程如下图所示：

（携程商旅的工作流案例）

在这个流程中，每个步骤都包含了很多个功能。比如“会员查找需要预定的航班”这一步，会员的需求可能会包含：

根据起始城市搜索航班根据选择的城市，找出最近的机场所在城市使用GPS定位所在城市翻转起止城市根据航班号选择航班

如果采用横切的话，我们仅会选取让本流程可以工作的最小故事集，如：根据起始城市搜索航班。

甚至，在本故事中，我们可以设置会员仅能通过精确输入起落地城市名称的方式，来进行航班搜索，在不影响本步骤走通的情况下，来最小化这个步骤的工作量。其它的流程也使用同样的策略，来加速打通整个业务流程。

横切的优势在于可以快速实现核心逻辑，并快速上线，验证假设并收集反馈，可以根据反馈的结果来决定每个步骤中的功能应该如何设计、优先级是什么，来避免一些可能出现的浪费。缺点在于整个工作流设计会采用短平快的原则，用户体验较差。

2、纵切

另一种方式是纵切。纵切就是按照工作流中的每一个步骤进行切分，这样可以使每一个步骤都具有相对完善的功能，这在某些需要关注终端用户交互体验的产品中应用较多。注意，这里有个技巧：如果在整个工作流中，需要跟终端用户进行交互的功能仅出现在某几步中，如第一步和最后一步，而中间的N-2步都是后台流程，在开发中，我们可以先实现第一步和最后一步的功能，而中间的流程处理环节，仍然采用逐步线上化的方式，这样可以使整个工作流系统最快的上线，同时能平衡用户的交互体验。

（纵切）

比如上面携程商旅订票系统的例子，我们可以把涉及终端用户操作的步骤：

会员查找航班会员发起订票申请公司审批人审批订票申请会员收到订票成功通知

把这几个步骤拆出来优先实现，及早上线；而中间的跟票务相关的步骤，仍然采用线下的形式。比如工作人员在携程商旅后台，把订单导出到excel表中，人肉打电话给票代，再把票代确定的订票信息填入系统，然后手动通知会员。这种方式对于一些流程复杂但用户量较小的初创公司比较适用，可以在保证用户体验的情况下，大大提升产品上线速度，并降低试错成本。

在这里要注意的是，不管是横切还是纵切，工作流中的每一个步骤都会遵循80/20法则，也就是20%的功能决定了这个步骤的核心价值，而80%的功能仅仅是锦上添花的，所以我们需要更深刻地研究客户的真正需求是什么，提炼出这20%的业务价值到底在哪里，从而进行更加合理的拆分。

功能模块拆分

对于已经拆出的功能模块，仍然可以根据一些方法进行进一步的拆分，这里介绍三个方法。

1、按业务规则拆分

同样的流程和操作，由于输入的数据业务规则不同，因此进行数据处理时采用的方式也不同。对于这样的情况，我们可以把功能按照业务规则来进行拆分。

典型的例子是搜索引擎，比如Google。在Google中，输入框只有一个，但Google会根据你所输入的数据规则的不同，来进行不同的处理操作。看下面几种情况：

在Google搜索框中输入一个关键字，得到这个关键字相关的搜索结果在Google搜索框中输入一个算式，如“ 1+1=”，得到算式的结果在Google搜索矿中输入“ThoughtWorks site:www.example.com”，得到在www.example.com这个站点中出现ThoughtWorks的页面…

对于这样的情况，我们可以把每一个业务规则都单独拆分成一个用户故事。当然，虽然这些用户故事看起来很相似，但是大部分情况下，这些规则的优先级是截然不同的。总会有一簇最高优先级的用户故事以及围绕在外围的用户故事。比如在这个例子中，对于Google来说，支持关键字搜索一定是最高优先级的，需要在产品设计的一开始就要实现，而能够计算算式的，可能很多年之后，才开始考虑加这样一个功能。

2、1+N模式

第二种情况，是对同样一个流程，在终端接不同的网关或渠道。最典型的例子是在线支付。比如，我在京东上买了一盒磁力橡皮泥，提交订单进入支付流程，在支付页面可以选择微信支付、京东支付、银行卡支付等等。

第一次实现支付的功能，可能会比较复杂，但后面如果从一种扩充到多种支付方式，就相对比较简单。而且最先需要支持什么样的支付方式，你可能在一开始也拿不定主意。这个时候，我们不妨将支付功能拆成2张卡，形如

会员可以使用微信支付/京东支付/网银支付中的一种进行支付会员可以使用微信支付/京东支付/网银支付三种渠道进行支付

使用这种拆分方法，可以延迟决策-我们需要最先支持哪种支付方式，同时合理的评估项目的工作量。

3、复杂的业务模型拆分

编辑：未知