第一稿尝试理解需求
最近团队承接了一项工作，是将原有的工作流进行优化，界面交互也做了一些改动。相对来说这项工作由于涉及到了很多的操作细节，与格式界面交互细节，PM准备了长长的文档交给团队。
交流过程中对文档又做作了很多补充。最后团队拆出来5个用户故事。一个是流程优化，一个是编辑报表，三个是其中一个界面的三部分细节。
团队在做的过程中遇到了很多的困难，尤其是其中遇到很多代码中的潜规则，每走一步都非常困难，总是爆出一堆BUG。
看到团队这么挣扎，于是要来了需求文档和界面原型，仔细看了几遍。感觉优化的点非常多，涉及流程修改、升级、导入导出、自动校验、多个界面调整、报表格式控制等等。纷繁复杂，不一而足。
于是尝试着将主要的优化点用卡片总结出了，经过分类汇总，逐步看出了一点规律。所有这些优化点都是在为客户生成报表。都遵循着相同的顺序，显示报表（新增或编辑）、设定报表条件、设置报表格式、生成报表、报表保存。
这样的顺序，自然而然的就可以应该用户故事地图的方式来组织所有的优化点。果不其然，这样按用户的业务操作顺序分类后，之前非常繁杂的优化点都可以放到这些顺序操作下面。作为这个大步骤下的一个可用功能。一下子，世界就清爽了很多。
再接下来，就非常容易给给个优化点排列优先级了。对于这个大需求来说，但凡涉及到操作流程改变得都是最基础需要调整的，这些作为第一个迭代要开始的。其他的功能，不影响主流程的，锦上添花型的，放在第二个迭代开始，最后一个迭代，完成一些支持功能，例如升级、导入导出等等。
只要有流程优化的地方就可以尝试使用故事地图来组织所有的优化点。之间的关系清晰，一目了然，轻松排序，便于指导开发工作。
网友评论