怎样对一个产品编写完整的用户故事( 七 )
弹压容量的挖掘，在产品早期一般使用语组替换方式来进行，通过替换或者增加一句基本用户故事语句里面的种类词语（主谓宾定状补表），挖掘到弹压容量可能会有比你想的大得多，当然PM的行业经验和产品经验在这一环节帮助很大。
购物搜索网站的搜索，用户希望输入一个关键词，返回符合他预期的一系列结果。这个用户故事的弹压容量非常非常大，下面是一个大概的演示（使用语组替换）：
他是谁？
我是商铺管理员，要搜索交易记录。我是后台总管理，要搜索入驻商家。我是用户，要搜索一个活动，商铺，门类品类，特定单品，特定品牌，特定上新时间范围，特定价位。我是游客，我没有账号，我就随便看看（要允许不登录搜索？）。输入要怎么输入？
我是用户，打字输入，空格分割，支持以图找图，支持语音输入，支持指定商品相似搜索。我是物流，扫码枪输入，NFC电子标签扫货。我是商铺管理员，输入偏好查询对应感兴趣的用户群体。我是常客，条形码输入，特定型号输入找特定单品。返回要怎么返回？
对于一个活动，所有用户返回同一个结果，缓存返回。对于关键词，同样词返回同一个结果，查询返回。对于高频词，可以进行缓存然后定时更新，缓存更新返回。对于大品类，用户购买历史推荐，偏好返回。对于返回结果后，进一步询问是不是满意，提供二次筛选，延迟满足。对于秒杀，未开始返回一样的结果，开始后返回不一致结果。用什么搜索？
PC搜索。移动端搜索。WatchOs搜索，IPAD搜索等等。SIRI捷径。其他分支动作（不购买）
搜索再筛选。搜索结果分享。没结果，空页面。我们已经明白，用户故事的容量由于两个部分构成，那么在真正落实需求，进行研发的时候就应该明确这两个容量的各自作用和所处角色。
本质容量部分为我们的研发进行大方向锁定。
搜索不会变成下单，订阅不会变成注销，这始终决定了功能的外在表现是怎么个状态和形式，也锁定了基本的动作，系统大致的输入和输出关系。
弹压容量是大方向下的全部可能方案的集合。
这部分包含了需求的更多可能性，可能客户确认，可能内部落实。他们可能被划分出去成为其他故事。
弹压容量的应对策略是“压榨至0”。在研发阶段进入之前，用户故事的弹压部分要尽可能全部明确，因为弹压容量的余量越大，对于需求未来不确定性的要素就越多，沟通确认盲区也就越多，需求事故发生概率就随之变大。
以上我们已经探讨完用户故事的容量问题，接下来我们探讨一下，容量多少是合适的。
故事生命周期与细粒度的关系存在即合理，PM不会片面的因为一个用户故事大或者小，就判别其质量的好坏，因为用户故事本来就是有生命周期的。用户故事一开始可能是一个“史诗故事”，也可能一开始就已经非常非常明确可以直接进入冲刺了。用户故事是需要加工挖掘的，是需要规范的。
一个用户故事，在被加工规范的过程中是有生命周期的，会随着我们的推进，确认逐步规范，也可能会被搁置或者废弃。当用户故事越逼近开发迭代周期，故事的本质容量会越小，弹压容量也会趋近于0。
采集到的用户故事：史诗，粗泛，仅有大方向加工的用户故事：一般描述，相互依赖，有弹压空间临近开发的用户故事：精确描述，无依赖，基本无弹压空间我们一般用这两个大概原因来解释这种变化。
过大的用户故事会被不断明确而减少弹性部分，一切在开发之前，都会被尽量明确落实。一个“史诗”不好开发，而被切割成很多很多用户故事。同时，要保证进入研发冲刺阶段之前的所有用户故事，都在临界状态下保持一致的大小和格式。例如：我们希望2周迭代一次，那么到了第二周我们就应该准备好下一轮迭代的全部用户故事。这个时候，就需要保证下一轮用户故事的细粒度，大小，描述全部一致并对齐。
所有任务单元大小一致，这有助于我们衡量这轮迭代的工作量与质量保证单元清晰，无依赖，这有助于研发理解业务没有歧义保证细粒度规范，有助于利益相关方和PM评估增量价值我这里无法提供一个标准，因为不同团队，不同文化，能接受的用户故事细粒度都是不一样的。但是，按照《SCRUM敏捷开发精髓》中的指南中，产品待办列表（准备开发的用户故事）细粒度章节认为，用户故事一般是能精确到小时的工作单元。
推荐阅读
- 聪明人养花，这3种“花”怎样也要养一盆，每年能省不少医药费
- 同比■同比增长7.1%！2021年的第一个节你花了多少钱？
- “他是我第一个会说普通话的老师”：一对师生折射青海山村蝶变
- 旅行社@旅行社推出“高铁+旅游”新产品 高铁旅行说走就走！连淮扬镇高铁全线通车
- 广西鹿寨贫困户玩直播带货变身创业新星以电商帮老乡卖滞销农产品
- 黄金时间■黄金时间丨哪种产品最节水？购买产品请注意这个标识！
- 货币等各类金融产品彻底电子化会到来么
- 有必要重新开个C店吗
- 互联网怎样解决“家政服务上门速度慢”的问题
- 怎样看待从1月8号起，QQ钱包开始提现收费