当前位置: 全天精准计划网 > 房产 > 正文

产品需求 之 庖丁解牛

时间:2019-10-05 15:33来源:房产
题图 在庄子的《南华经》中有一则寓言。说是有位叫丁的厨师,替梁惠王杀牛,其技法之娴熟,如同美妙的音乐一般。惠王就问他为什么会有如此高超的技术。他回答说:“臣所喜好的

图片 1

题图

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

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

工作流系统

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

1. 横切

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

图片 2

横切示例

图片 3

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

图片 4

携程商旅的工作流案例

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

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

如果采用横切的话,我们仅会选取让本流程可以工作的最小故事集,如

  • 会员可以根据起始城市搜索航班

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

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

2. 纵切

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

图片 5

纵切

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

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

把这几个步骤拆出来优先实现,及早上线;而中间的跟票务相关的步骤,仍然采用线下的形式。比如工作人员在携程商旅后台,把订单导出到 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. 复杂的业务模型拆分

对于有的系统,业务模型可能会非常复杂,比如一个房产交易平台中的房产信息,可能包含户型信息,中介信息,地理位置信息,价格及购买相关的税率信息,展示图,效果动画等等,当我们需要在系统中引入这样一个业务模型时,如果一上来我们就考虑清楚这个业务模型的方方面面,这是个性价比很低的事情 —— 做了很多功课,但没有给客户带来真正的业务价值。

这个时候,我们需要将业务模型,按照我们实际需要提供的功能进行拆分。比如,我们要做一个中介搜索系统,我们可以仅取出模型中的中介信息,而不需要去处理其它部分。即使我们需要整个业务模型去做一些事情,也可以把其拆成一个个子模型,根据子模型的业务价值及优先级去设计相应的功能。

比如在这个例子中,我们需要对房产的信息做展示

  • 对于户型信息,需要有户型图,户型相关的文案展示
  • 对于中介信息,可以看到中介人的头像,联系方式,可以使用多种方式在线联系中介代理
  • 对于地理信息,我可以在 Google Map 上查看其地理位置,并能够从我的位置导航过去
  • 对于展示的图片和动画,我需要像幻灯片一样,可以在页面上播放
  • …...

那么,我们如果一开始就着手于解析这个房产业务模型,那可能浪费了很多时间,而没有交付对用户有价值的业务功能。这个时候,我们需要区分哪些信息是核心信息,是对用户来说最有价值的,把这些信息从业务模型中提取出来,而后设计相应的更小的业务功能,切忌一蹴而就。

需求拆分是否有一套完美的方法?

需求拆分是没有银弹的,要根据具体的场景、限制选择合适的拆分方法。在遇到使用某个拆分方法,不能满足当前业务需求时,看看是不是可以换个思路,换个方法。

当然,在选择拆分方法时,也有一些技巧,如

  • 选择那些可以拆出低优先级卡片(或者可以被扔掉的卡片)的拆卡法,因为 80/20 法则
  • 选择可以把卡片拆的大小差不多的方法,未来在发布计划中更容易做需求置换
  • 选择开发团队更容易理解和实现的方式

当然,这一定不全面,每个人在不同的场景、限制条件下,都会有不同的技巧。相信你自己的拆分方法,多与团队成员沟通才是不变的法门。

以终为始 - 故事验收方法

Bill Wake 提出了一个好用户故事的验收标准 —— INVEST 模型,它由六个单词的首字母组成,分别是

  • Independent:每个用户故事应该是独立的,不会和其他用户故事产生耦合
  • Negotiable:并不会非常明确的阐述功能,细节应带到开发阶段跟程序员和客户来共同商议
  • Valuable:每一个用户故事的交付都需要能够给用户带来用户价值
  • Estimable:不需要能够准确的估计,但需要能辅助客户排定优先级
  • Small:要小一点,但不是越小越好,要大小合适,可以更容易圈定故事范围
  • Testable:需要能够进行验收测试,最好能把 Test Case 提前加进去

这不仅仅是故事的验收原则,更是在进行需求拆分的时候所需要考虑的拆分原则。当然,凡是有例外。在需求拆分中,有时会拆出一咩咩实在不能满足 INVEST 原则的故事卡片,也不要太纠结,我们追求完美,但也总要接受现实的不完美。这个时候,跟开发团队多交流,开拓思路,协调一个比较好的拆分方式,比自己一个人憋大招要好的多。

最后

再介绍几个反模式。

  • 按照技术架构分层进行拆分,常见的会按照持久层、应用层、展示层进行拆分。这种拆分方式拆出来的用户故事,会明显破坏 INVEST 中的 Valuable 的原则,而且各个故事卡由于各方面的原因,如开发进度不同意,无法灵活的集成上线。
  • 拆分时,把复杂的 UI 交互算在故事卡片中。大部分情况下,比较 fancy 的 UI 交互都不是核心的业务功能,这部分功能可以作为用户体验优化的卡片,独立拆出来
  • 拆分时,过早考虑性能问题。在性能基本达标不出现大的问题的情况下,提升性能很多情况下也属于用户体验的一部分,可以单独拆出来,左右优化卡片。
  • 拆出一些管理类的卡片。比如管理产品,实际上可能包含很多产品相关的操作,如导入、编辑、同步信息、改变状态、上架、下架等,所以应该根据具体的功能,拆分成更为准确和大小合适的故事卡片。

最后的最后

欧阳修在《卖油翁》中,提到一个老翁,在倒油时能通过铜钱中心的方孔,却不洒一滴油,大家都很惊叹,他只说了一句话 —— “无他,但手熟尔”。需求拆分也一样,并没有什么高深的学问,拆的次数多了,也便有了那份手熟。

编辑:房产 本文来源:产品需求 之 庖丁解牛

关键词: