用user story来代替prd，不仅清晰直观，还能提升团队的沟通效率；玉米大人分享一些写故事和切故事的方法及注意事项。

我跟用户故事的渊源

记得13年初有参加过敏捷咨询师Daniel Teng一个工作坊，导师给我们布置的任务就是每组从自己日常生活的痛点出发，自由发散的去想一个创意点；之后团队成员自己分角色扮演不同的用户类型，上去讲故事；然后从故事里抽离出产品需求，根据需求在卡片上画低保真的原型；每个团队依次把原型卡片贴在白板上，按用户体验流程去讲；最后大家投票评选出公认的价值点高的产品。

当时只觉得整个过程很有趣，并没有真正放在心上。我真正开始写用户故事，是在去年使用快速迭代的开发方式后，每次完成几个独立的用户故事，快速上线给用户验证，及时发现问题，快速调整。使用下来不仅不用写长长的prd文档了，团队沟通效率更高了，用户和公司高层都能更快的看到我们的产品的更新迭代。

论讲故事的重要性

什么是用户故事？

用户故事（user story）是从敏捷开发scrum中提出来的。是从用户的角度来描述用户渴望得到的功能，它是一个独立完整的、可直接上线交付的、有一定业务价值的最小粒度的产品。

举个微信的栗子：

微信1.0上线了楼层式的单人会话，用户可以在手机上给好友发送文字和照片，以实现在手机端即时免费聊天的目的。1.2版本上线了多人会话，用户可以在手机上发起一个群聊，并邀请相关好友入群，以实现在手机上展开小群组的讨论的目的。这2种会话方式 是针对同类用户的不同场景，每个故事都是相对独立的，又给用户完整的体验，当然业务价值也是显而易见的。

用户故事的价值体现：

告别prd，通过讲故事来提升团队效率

早些年我们写需求文档，前面几页都是标准的模板，关于项目背景、目标、风险等的描述。但现实中开发要么不看文档，要么打开导航，直接跳着找跟自己相关的，漂一眼界面原型图和大概流程，就开干了；而且在需求评审会上，把这10p+的prd文档讲完，没个2小时真搞不定。

上图是我们之前写的prd模板↑

我们写prd的目的是什么？告知团队成员我这个需求的背景或者问题是什么、用户群体有哪些、要实现的目标是什么，解决方案是什么；这些都可以通过一个个短小精悍的用户故事来阐述。

故事+意义=品牌，通过故事来触达人心

不但产品需求可以通过讲故事来简化，后续的营销也离不开故事。记得17年底的时候，顺丰官网的大banner是个微视频，一个老父亲小心翼翼的把户口本递给顺丰小哥，小哥双手接过并微微点头；画面一转，看到一对新人满脸笑容的拿着户口本和结婚证从民政局出来。然后配合顺丰的slogan“承诺，为每一份托付”。

怎么写故事

用户故事的颗粒度

敏捷中有提到epic，即史诗级的故事，然后才是user story，其实故事粒度还可以更大，大到为什么做这个产品。在梳理产品需求的时候可以由粗到细，先列出粗颗粒的epic，然后切分成小颗粒的user story，用户故事一定要切分的够细，最后是进行分组和排序，产出用户故事地图，也就是我们常见的迭代版本清单。

写故事四字法：起承转合：

其实我们小时候写作文也是用的这个方法，先介绍故事的主人翁及故事背景，然后在这样的背景下，主人翁想要什么或者想达到什么样的目的【前面都是起】，但是现实中遇到了哪些问题或困难导致很难实现目的【承】，后来他做了什么事或者哪些努力【转】 ，最终历尽千辛万苦实现了目标【合】。

接下来我们结合产品经理梳理需求的思路来提炼重点：

主人翁---user（角色）

故事背景---scene（场景）

想要什么或者想达到什么样的目的---Want（目的）

遇到了哪些问题---defect（问题/不爽）

他做了什么事或者哪些努力---Action（行动）

举个栗子：

小c的工作需要经常出差，有次忘记定酒店了，当时已经很晚了，跑了一天也很累，晚上还要发工作汇报邮件，小c想快速的找个最近的酒店安顿下来。当他在手机上找酒店的时候，还要点开详情页，去看看当晚还有没有空房，有些有空房的价格又高出很多，最后还要到酒店设施里确认下有没有wifi。于是小c就背着电脑包在马路边盯着手机找了好久，找到酒店后我还要把酒店地址贴到百度地图里，最终跟着导航找到了酒店。

用户故事的标准模板：

As a , I want to , so that .

作为一个xxx（某类用户），我要xxx（做一件事），从而达到xxx（某一结果或动机）。

套用这个模板的示例：作为出差在外却没有预定酒店的人，我要找到我现所在地点步行距离内的经济酒店，从而能够睡觉休息、上网处理邮件。

这里有提到角色，其实角色就是交互设计里经常提到的用户画像persona，后面我会单独一章来分享我对persona的理解。不过在之前的文章《产品设计中数据观点和用户画像--课程内容整理》中，有一小部分是对persona的描述，感兴趣的可以先看下~

总结：

个人觉得四字法更适合粗颗粒的史诗级故事，而故事模板更适合细粒度的用户故事。或者说四字法更适合需求梳理初期，可以直观的看到用户使用场景和痛点，而痛点就是我们要解决的问题，而故事模板则更适合技术团队沟通。

如何切故事

为什么要切分故事？

其实user story就是被切分后的epic。在实际项目中，越是高优先级的故事，颗粒度要越小，描述越具体，这样做的好处是：小的故事大家在理解上不容易产生偏差，而且更容易完成，故事越大不确定性就越大（比如外部依赖，前置关联，临时需求插入，团队人员请假等）。

如何切故事？

按工作流程：比如请假流程，可以把简单的首尾故事先切分出来，创建请假单，审批请假单，然后中间各个环节的审批流转作为独立的故事。

按功能操作：比如一般的后台报表都有增删改查的功能，可以按增删改查来切分。

按功能类型：比如接在线支付，微信、支付宝、银联可以拆分为3个故事来完成，当然每个下面还可以再切。

按内容范围：比如酒店详情页，先支持查看酒店基本信息和价格，再支持查看周边交通，地图位置等。

按用户需求层次：把性能和稳定性方面的考虑拆分成独立的新故事；

（说明：这些切分方法部分来自于Richard Lawrence，想了解更多切分方法的可以自己去看下）。

注意事项

从用户是视角来讲故事；

把握好用户故事的粒度：

自己在前期梳理故事，或者给高层讲故事时，故事粒度可以粗一些；但是给技术团队讲故事，粒度要足够细，足够具体。

故事并不是越多越好：

一般一个迭代5-10个故事，维护2-3个迭代周期的故事就可以了，让那些价值不高的故事从你的待办清单里消失吧~（数据仅供参考，具体还要看迭代周期的长短和团队资源的配比，我这个是5天一个周期，2个开发人员的工作量，当然我的故事拆的非常小）。

要有验收条件：

即符合什么要求的故事才算可交付的，也是给测试人员一个测试依据。

写在最后

关于用户故事我也是最近1年才开始使用，踩的坑还不够多，写这篇文章前我又把相关的书和资料都看了一遍，修修改改的写了1整天，希望有经验的小伙伴可以一起交流探讨~~~