前一阶段接触了一个新的移动App团队，跟大多数移动App团队一样，工作压力特大。闲来无事，就看看他们的Backlog吧，结果我发现他们“忙”的原因了。

我在Backlog里面发现了很多类似于下面的“故事”：

• XXX页面重构
• XXX详情页
• XXX app 首页品类分类 入口
• XXX app 首页导购模块
• XXX app 个人中心重构
• XXX页面增加YY标签
• XXX页面增加活动入口

我同时也看了一下引用文档，其实也就是团队PRD（产品需求文档），里面内容跟上述“故事”长得很像。比如：

XXXX模块

• 需支持灵活配置
• 城市拓展
• 分类名称调整（可支持二级分类）
• 排序调整
• 预留标志位

当前排序

• 第一类城市：分类1、分类2、分类3、分类4、分类5、分类6、全部分类
• 其他城市：分类1、分类2、分类3、全部分类

其实这个Backlog里面的“故事”根本不是故事，原因就是我们这些“故事”全部是解决方案，而好的用户故事是关于问题的。从我们上面的那些故事里面，我们很难了解这些故事是为了解决哪些业务问题，目的是什么。甚至哪怕是亲手写这些“故事”的“PO”同学们，两个星期之后也不会记得这些用户故事是为了解决哪些业务问题了。

接下来跟测试同学坐在一起好好比较、分析了我们的App和竞争对手的App后，渐渐明白了这些故事的业务目的。原来所有这些故事全是在“抄”竞争对手的功能。再花一些时间比较一下两个App，发现竞争对手缺失能够比我们更好的解决客户问题。

• 竞争对手App上，提供了各种主题的搜索入口，因此我只要很少几次Click，就可以迅速的定位商家。
• 竞争对手定位比我们的App准，而且针对地域推荐的商家也更符合客户的需求。

接下来，我做了一个思维导图，不完全的列出了竞争对手的实现所解决的业务问题：

• 如何更方便的找到商家
• 如何发现未知的可能感兴趣的商家

这两个问题还是比较大，所以我把问题做了一下切分，然后很容易就可以写成用户故事的格式了。

• 作为消费者，我希望通过主题搜索商家，从而可以让我可以快速找到想找的商家。
• 作为消费者，我希望看到的主题是根据我的消费习惯相关，从而可以让我可以快速找到商家。
• 作为消费者，我希望在搜索结果比较少的时候，给我提示或者推荐，帮我去发现喜欢的商家。

我们的用户故事应该描述的是如何跟竞争对手一样或者更好地解决客户问题。如果只是简单地从界面去抄袭，很难比对手更好地解决问题，原因很简单，对手明白他做一些的原因，这样的设计考虑到它自己的一些因素，而我们无从得知，只能猜或者从表面上去抄，根本没有办法超越他们。只有了解了目的、要解决的业务问题，我们才能够提出更好的、更便宜、更符合点评实际情况的解决方案。PO也应该多从问题角度，去发现竞争对手已经解决的问题，甚至还没有解决的问题，鼓励团队去创造性地解决问题。