用户故事中“Why”的两个常见错误

普通项目文档和敏捷项目文档的差别
2019年5月30日
写好敏捷文档,让需求分析人员(BA)失业
2019年5月31日

前言

Preface


上一篇文章里我分享了用户故事中Why部分的设计原理,以及由此导致的敏捷项目文档和普通项目文档的区别。

用户故事格式虽然简单,但是这个Why写起来却不简单。我在上一篇文章中吹牛,说敏捷文档写好了成本节省50%,收益提升50%,里外就是100%的增长。但是如果对敏捷项目做一个访谈,问一下需求文档改成用户故事后带来了多大好处,大部分的回答可能是“换了一个格式而已”。别说100%的增长,10%都没看到。产生这种情况,往往是因为掉到了下面两个常见的坑:

  • 你以为写完了Why,但你写的不是Why
  • 你以为的Why,不是客户的Why

我们每个坑举些例子,详细看一下。

你以为写完了Why
但你写的不是Why


沿用上一篇文章中的案例,我们截取其中的“用户注册功能“,为它创建一个用户故事。 很多人认为下面这样的用户故事是完整了:
“作为制造商,我需要一个带有注册功能的网站来吸引用户注册,这样我可以积累潜在买家的信息。”这看起来是符合用户故事格式的,但其实并不是。

“积累潜在买家的信息”,仍然是What,还不是Why。它只是“带有注册功能的网站来吸引用户注册”这个功能带来的结果,而且

“积累潜在购买者的信息“能给客户带来什么好处呢?我们从前面的文章中知道,积累了一些用户数据后,客户新产品上线的时候就能推送给这些人了,从而缩短潜在买家了解他们新产品的时间。

这个用户故事可以提炼成:

“作为制造商,

我需要一个带有注册功能的网站来吸引用户注册,这样我可以积累潜在购买者的信息,

以便新产品上线后推荐给他们,缩短他们了解新产品的时间。”

我们对比一下,就会很容易发现,左侧用户故事的What,描述的其实是一个结果,相比右侧的用户故事, 他缺少来自用户视角的“价值”描述。我们上一篇文章说过,Why是一个参考线,帮我们制定出合理的What。Why写的好不好,取决于它多接近痛点和价值, 越接近用户的价值,对设计和研发的指导意义越大。

基于左侧不完整的用户故事,我们接下来能做的是去问PO注册时要采集哪些用户信息,然后按照PO给的列表实现—与我们在普通项目中能做的并没有什么不同。

这种做法,我们叫做“完成客户交代的事”。

而看到右侧的用户故事后,我们能知道,注册时填写的信息是为了服务于新产品发布,用来缩短潜在客户了解产品的时间。那么下面这些思考就很容易发生:

这种做法,我们叫做“为客户创造最大化价值”。

所以如果你真的拥有从客户视角出发的Why,那么你的思路一定会得到拓宽,能构建出更符合客户利益的What。相反,如果你写的Why,只不过是What的输出结果,那么跟普通项目需求文档并没有什么区别。

再举一个随便在网上搜到的用户故事的例子:

“作为招聘网站注册用户(Who),我想要查看最近3天发布的招聘信息(What),以便于我看到最新的招聘信息”(Why)

这个用户故事也很常见,看起来似乎正确,但其实也缺少真正的Why

“看到最新的招聘信息” 只是一个功能的执行结果而已。这个结果对用户来讲,应该带来什么好处呢?找工作的人最希望迅速的定位到跟自己经验匹配的职位,以及自己可能感兴趣的职位,而不是在一堆无关的招聘信息里浪费时间翻来找去。

所以这个用户故事可以加工一下,变成下面这样会更有意义:

“作为招聘网站注册用户(Who),我想要查看最近3天发布的招聘信息中跟我的工作经验相匹配的职位(What),以便缩短我找到心仪职位的时间。(Why)”

根据原来没有改动的用户故事,交付团队可能给出一个普通的职位信息列表。

根据第二个用户故事,在澄清细节的时候,就有可能浮现出下面的讨论:

你看,来自用户视角的“why“,才能指导我们更好的讨论需求的细节。我经常看见大家的实际在写用户故事的时候,试图遵循用户故事的格式去写,但实际写出来的的格式,只是

“作为__角色,  可以做__操作,

  从而获得__的结果”。

这背后还是input/output思维,并没有更进一步的去同理心客户。

如何纠正这种行为,我有两个非常有效的建议:

方法一:

写完用户故事之后,对Why的部分,做一下 “5 Why分析法”,这样你或许会对What是不是合适的What,以及你做的事是否真的对客户有价值,有一些全新的看法。

方法二:

在时间有限的前提下,为了训练团队理解和辨别“Why”的能力,Scrum Master可以每个月花1小时的时间,组织一个Why工坊,从Backlog里挑选1-2个用户故事做下面两件事:
Step 1 – 对User Story的Why的部分进行5 why 分析,然后引导团队思考收获。 

Step 2 – 基于收获,思考what可以进行哪些改进式创新,有没有颠覆式创新的可能。

这个工坊每个月做一次,一般坚持半年之后,就能发现团队中的工程师思维的人们(不仅包括工程师本人,也包括部分分析,设计人员)在做设计交付的时候,更加能够从客户的角度出发,并且设计交付能力大大提高。

接下来我们看一下用户故事书写中第二个常见的问题:

你以为用户的Why
不是用户真的Why


辅导的一个团队,要为IBM做一个针对欧洲某小国用户的服务器销售网站。他们需求分析人员的一个用户故事是这样的:
作为x国的服务器购买者,(who)

我可以通过网站搜索服务器型号,快速查看相应型号的服务器信息,(what)

节省了搜索服务器信息的时间(why)

“节省搜索服务器信息的时间”,确实是用户可以获得的价值,所以这个用户故事看起来是完整的。

但是我向团队提了一个问题–

用户以前是怎么查询服务器信息的?我们这个搜索功能,相比他们以前的查询方式,能够节省多少时间?需求分析人员说,他倒没有跟客户深入了解过这一部分,但是凡是在线销售的网站,都有这样的搜索功能呀,而且都是为了快速定位节省检索时间啊,这都已经是个默认的上网用户的习惯行为了

好在他后来答应我回去把这条用户故事的“Why”拿去跟“Who”验证一下,结果了解到的情况是,在这个行业里面,服务器的型号有限,更新换代也比较慢。采购人员都很专业,对现有市场上的型号非常熟悉,不需要检索以及查询信息页面,检索功能对他们节省时间的需要改善有限。

在敏捷研发的时候,我们希望PO充分了解客户和项目之后,给出准确的Why,但是现实情况下,很多项目只有一个大概的需求,剩下的用户故事都是由需求分析人员(BA)和团队里一些有经验的人来撰写和完善。这种时候,撰写者难免需要一点经验和假设。但是你最终要做的,是验证。将“Why”拿去跟同一用户故事里的“Who”确认。

缺乏对Why的验证而进行的开发,就做不到“把不必要做的工作最大化”这条原则。即使写对了用户故事,最终的收益跟普通项目也没什么区别。

业务分析人员,或者需求分析人员,是一群让人又爱又恨的人。他们能帮交付团队澄清需求的细节,对项目成功至关重要。但是遇到“能力不行”的需求人员则可能导致返工,客户抱怨交付物不对等等问题,给项目带来的伤害反而大于其作用。

很多团队都抱怨过需求分析人员,但是职场是一个讲究

“you can you up, no can no bibi”

的地方。下一篇文章,我就打算跟大家聊一下,如何利用敏捷文档的一些巧妙设计, 越过不称职的需求分析人员,skip bibi,直接up。

评论关闭了。