用户故事中“Why”的两个常见错误
普通项目文档和敏捷项目文档的差别
2019年5月30日
写好敏捷文档，让需求分析人员（BA）失业
2019年5月31日前言
Preface
- 你以为写完了Why，但你写的不是Why
- 你以为的Why，不是客户的Why
我们每个坑举些例子，详细看一下。
你以为写完了Why
但你写的不是Why
“积累潜在买家的信息”，仍然是What，还不是Why。它只是“带有注册功能的网站来吸引用户注册”这个功能带来的结果，而且
“积累潜在购买者的信息“能给客户带来什么好处呢？我们从前面的文章中知道，积累了一些用户数据后，客户新产品上线的时候就能推送给这些人了，从而缩短潜在买家了解他们新产品的时间。
这个用户故事可以提炼成：
“作为制造商，
我需要一个带有注册功能的网站来吸引用户注册，这样我可以积累潜在购买者的信息，
以便新产品上线后推荐给他们，缩短他们了解新产品的时间。”
基于左侧不完整的用户故事，我们接下来能做的是去问PO注册时要采集哪些用户信息，然后按照PO给的列表实现—与我们在普通项目中能做的并没有什么不同。
这种做法，我们叫做“完成客户交代的事”。
而看到右侧的用户故事后，我们能知道，注册时填写的信息是为了服务于新产品发布，用来缩短潜在客户了解产品的时间。那么下面这些思考就很容易发生：
这种做法，我们叫做“为客户创造最大化价值”。
所以如果你真的拥有从客户视角出发的Why，那么你的思路一定会得到拓宽，能构建出更符合客户利益的What。相反，如果你写的Why，只不过是What的输出结果，那么跟普通项目需求文档并没有什么区别。
再举一个随便在网上搜到的用户故事的例子：
“作为招聘网站注册用户（Who），我想要查看最近3天发布的招聘信息（What），以便于我看到最新的招聘信息”（Why）。
这个用户故事也很常见，看起来似乎正确，但其实也缺少真正的Why。
“看到最新的招聘信息” 只是一个功能的执行结果而已。这个结果对用户来讲，应该带来什么好处呢？找工作的人最希望迅速的定位到跟自己经验匹配的职位，以及自己可能感兴趣的职位，而不是在一堆无关的招聘信息里浪费时间翻来找去。
所以这个用户故事可以加工一下，变成下面这样会更有意义：
“作为招聘网站注册用户（Who），我想要查看最近3天发布的招聘信息中跟我的工作经验相匹配的职位（What），以便缩短我找到心仪职位的时间。（Why）”
根据原来没有改动的用户故事，交付团队可能给出一个普通的职位信息列表。
根据第二个用户故事，在澄清细节的时候，就有可能浮现出下面的讨论：
从而获得__的结果”。
这背后还是input/output思维，并没有更进一步的去同理心客户。
如何纠正这种行为，我有两个非常有效的建议：
方法一：
写完用户故事之后，对Why的部分，做一下 “5 Why分析法”，这样你或许会对What是不是合适的What，以及你做的事是否真的对客户有价值，有一些全新的看法。
方法二：
Step 2 – 基于收获，思考what可以进行哪些改进式创新，有没有颠覆式创新的可能。
你以为用户的Why
不是用户真的Why
我可以通过网站搜索服务器型号，快速查看相应型号的服务器信息，（what）
节省了搜索服务器信息的时间。（why）
”
“节省搜索服务器信息的时间”，确实是用户可以获得的价值，所以这个用户故事看起来是完整的。
但是我向团队提了一个问题–
好在他后来答应我回去把这条用户故事的“Why”拿去跟“Who”验证一下，结果了解到的情况是，在这个行业里面，服务器的型号有限，更新换代也比较慢。采购人员都很专业，对现有市场上的型号非常熟悉，不需要检索以及查询信息页面，检索功能对他们节省时间的需要改善有限。
在敏捷研发的时候，我们希望PO充分了解客户和项目之后，给出准确的Why，但是现实情况下，很多项目只有一个大概的需求，剩下的用户故事都是由需求分析人员（BA）和团队里一些有经验的人来撰写和完善。这种时候，撰写者难免需要一点经验和假设。但是你最终要做的，是验证。将“Why”拿去跟同一用户故事里的“Who”确认。
缺乏对Why的验证而进行的开发，就做不到“把不必要做的工作最大化”这条原则。即使写对了用户故事，最终的收益跟普通项目也没什么区别。
业务分析人员，或者需求分析人员，是一群让人又爱又恨的人。他们能帮交付团队澄清需求的细节，对项目成功至关重要。但是遇到“能力不行”的需求人员则可能导致返工，客户抱怨交付物不对等等问题，给项目带来的伤害反而大于其作用。
很多团队都抱怨过需求分析人员，但是职场是一个讲究
“you can you up， no can no bibi”
的地方。下一篇文章，我就打算跟大家聊一下，如何利用敏捷文档的一些巧妙设计， 越过不称职的需求分析人员，skip bibi，直接up。
