呢喃22

外包做久了,各种客户都会遇到,当然有提着厚厚一大本需求说明书过来的,但更多的客户只有一个想法,一个点子。

完全抓不准谁最终会成为你的客户,所以必须得跟进。积累下来,就有了摸清用户需求的三图一表大法。


首先是脑图,又叫思维导图,一种像树状的图。

脑图真的非常有用。

其实我一直觉得自己,甚至我们团队,对脑图的掌握并不够好,水平很是一般,但已经感觉到这个图的力量非常巨大。

我们一般按系统、子系统、模块、子模块、其它细节需求,这样四到五级进行纵向的需求分割,然后简单地再为向个系统、模块的依赖关系拉上一条线,项目就跃然纸上了。


作为脑图的补充,还需要画的是流程图。

流程图是计算机科班出身的人在大学程序设计课上是学习过来的,不过这里的用法要大粒度得多,不再是用来做过程式程序设计的一个函数,而是用来描述一个完整的业务流程。

比如用户的整个在线购物流程:从首页到专题到商品详情到购物车到生成订单到支付到查快递到收货确认到申请退货退款等。

可以看到这样的一个流程,横跨多个系统、模块,而且有多个出口(随时可以放弃进入流程的下一步),像竹篾一样以脑图划分的系统和模块纲编织了起来,经纬交错,形成完整的业务逻辑网。

画流程图是非常耗时耗脑的工作,我们一般会把业务流程分一下优先级,只为骨干业务流程画图,如果是自己做产品,建议产品经理还是要把所有的业务都画上流程图,一方面是为下游服务,另一方面也是对自己想法的很好的反思,经常会发现自己想法的“幼稚、不合理”之处,对产品设计能力的提升是很有帮助的。


脑图和流程图,更多的是为项目经理自己服务,方便自己评估项目的规模,以及自己团队的成本和风险,最终作出报价。

但对于一些野心比较大的客户来说,这还是不够的,因为就简单如“用户注册”这4个字,他的定义和你的定义可能差别很大。这个时候,还需要画原型图。

原型图又叫线框图,通过简明的方式来做软硬件系统的交互设计,让人对系统有一个直观的认识,也可以进一步确认需求的细节。

显然的,原型图要更加耗时耗脑,所以大部分外包厂商是不愿意为尚未收款的客户画原型图的。不过我们公司很不喜欢签订有风险的协议,所以我们一般都会做完若干主要界面的原型和客户确认后,才会把这三种图作为合同的附件一起签订下来。


虽然这三图可以有效地厘清用户的需求,但这通常都指望不上客户,需要项目经理自己动手,所以项目经理会很累的,而且企业对项目经理的要求也会提升,用人成本也就上升了,所以最好有能够让客户自己动手的方法。

作为一家优秀的外包服务厂商,我们当然找到了方法。这就是我说的三图一表中的一表:用户故事表。

用户故事表,User Stories,当然不是我们的发明。这个来自敏捷开发的项目管理方法,我们创造性地用在了用户需求的挖掘上。

我们用 Excel 编制了一个简单的表格,只有3列:角色、活动、商业价值。这源自用户故事的三要素:

  1. 角色:谁要使用这个功能。
  2. 活动:需要完成什么样的功能。
  3. 商业价值:为什么需要这个功能,这个功能带来什么样的价值。
  用户故事通常按照如下的格式来表达:
  英文:
  As a <Role>, I want to <Activity>, so that <Business Value>.
  中文:
  作为一个<角色>, 我想要<活动>, 以便于<商业价值>
  举例:
  作为一个“网站管理员”,我想要“统计每天有多少人访问了我的网站”,以便于“我的赞助商了解我的网站会给他们带来什么收益。”
  需要注意的是用户故事不能够使用技术语言来描述,要使用用户可以理解的业务语言来描述。

然后我们根据一个企业午餐预订的小系统为例,编写了一个很粗糙的示例,给客户理解这个表格。是的,必须得粗糙,我们不能指望客户能够理解到用户故事的意义所在,所以甚至我们也不会给客户说到“用户故事”这个术语,而只是简单告诉他有个需求表得填一下。

只要客户能平和地配合,来回修正两三次用户故事表,你就会发现你已经可以很好地画出脑图和关键业务的流程图,拿着这两个图,就可以吸引到客户讲述更清晰的需求啦。


搞明了客户的需求当然不会容易,但奈何情长纸短,我也只能在这里提提,具体怎么应用,还要用到什么图(比如时序图也非常有用),还是得大家自行下下苦功了。

编辑于 2018-01-18

文章被以下专栏收录