1 背景
最近在微信群里，有一些关于用户故事书写的讨论，其中有一些观点
- 用户故事的格式不用完全按照标准格式那样，拘泥于形式。
关于格式这一点，不在这里讨论。
- 用户故事的 "So that" 必要性不大。
必要性不大的几个理由:
a) 企业已经运作很多年, 赚了很多钱了. (So that 强调的价值, 不大。)
b) 百人级别的产品总监，焦点在哪？ (So that提不起他们的兴趣?)
c) 现实时间点问题:
1) 决策启动时，故事还没写呢, So that放的地方都没有。
2) 后面故事写出来了，决策者总时间不够，不会都看。
d) So that 的东西众所周知
e) So that 陷阱：复述结果而非价值
eg:
作为 购书者
我要 根据作者姓名模糊查询书籍
这样(so that) 可以根据模糊记忆查询到需要的书籍
作为 一个用户
我要 用手机号和验证码登录系统
这样 我便可以快速登录系统
(or 这样 我可以在忘记密码时可以用验证码登录)
这么写 PO 自己都发觉
2 为何 So that 必须写？
2.1 价值信息传递
从大规模到小团队，价值信息是从上而下，逐层分解、细化而传递的。
So that 承担的, 便是价值信息的载体。省略 So that, 意味着价值信息传送链断裂。
2.2 为下一个级别的故事分解，提供边界。
Epic -> Theme -> Implementable
即使在高层次故事(战略 Epic) 大家对价值都心知肚明了，省略了，下一个层级的故事分解，由于缺乏上一个层级的价值信息，便容易分解偏了。
尤其在 Implementable 级别，没有 So that, 开发人员就容易变成码农了。
活干出来就行咯，有没有什么价值？ 咱也不敢说，咱也不敢问。
2.3 为用户故事的优先级排序，提供依据。
在敏捷的世界里，对用户故事进行排序，又是一个众所周知的事情。
那么，排序的依据是什么？相信都能回答 价值
那么， 价值 在哪？不就是 "So that" 咯。
那么，"So that" 都不见了，排序的依据是否就会是 "感觉" "难易度" 了呢？
2.4 为用户故事的预期与实际效果对比，提供度量方式。
So that 表达的是外部价值，如 "So that 可以提升用户转化效率",
那么当这个故事上线后，我们就需要获取数据来验证，是否用户转化效率是否提升了？提升了多少？ 与预期是否发生偏差，偏差的愿意是什么。为下一步的改进提供依据。
2.5 为开发人员提供更多信息，避免实现的僵化。
没有明确的外部价值的，可能导致开发人员在实现时，产生不同的行为。
见后面。
3 "So that" 如何写? 又是如何影响开发团队的思考的？
"So that" 关注的应当是外部价值，而不是 "是什么" "做什么"。
还是用上面的例子
作为 购书者
我要 根据作者姓名模糊查询书籍
这样(so that) 可以根据模糊记忆查询到需要的书籍
这种写法，完全符合用户故事标准，开发会怎么思考？
通过SQL进行检索，把结果呈现出来。
三下五除二，搞定。
But，这个故事，我们如何验证它的价值？ HOW?
验证模糊查询的正确性？验证查询的速度？查询的次数？
如何赚回开发这个功能的成本？
如果换成另一个写法呢？
作为 购书者
我要 根据作者姓名模糊查询书籍
这样(so that) 方便我找到要的书籍加到购物车
开发在面对这个故事的时候，除了知道他需要实现查询和呈现，还能知道潜在的，需要记录更多一些信息，以便于后期分析用户购物车的行为。
故事的价值验证，也转变为，购物车(or订单)中的书籍，
- 有多少是用户通过作者姓名检索后加进来的？
- 这个功能对成交贡献的提升有多少？
- 是否还需要添加更多的查询条件？
- 查询速度是否影响了预期？
.....
用户故事的三段，前面两段都比较好写，可以说稍为引导一下谁都能写。最后的 So that 才是最难的部分，有多少PO在这一步被憋出内伤来啦 ;-)
但是，但是，So that 部分，才是评价一个PO是否合格的标准。
说了那么多不写So that的理由，其实只有两点:
1. 不愿写
2. 不会写
