文/秋之川
这是《落叶》文集里第 312 片落叶，希望你能喜欢，不为别的，只为这份坚持。
第六章 天哪，我怎么可能了解所有的需求？（中）
我经历了什么
之前做了一个 To-Check-list，并开始使用它来管理需求文档的阅读计划，
应用之后的效果还不错：
- 首先解决了忙乱的问题，不再一会 A，一会 B，又一会 C 了，因为都从大脑里腾到 To-Check-list 了，空间都让给理解需求了；
- 也不会不知道从何开始阅读了，因为开始前就已经把所有需求按优先级和模块划分好了，哪天看那几个都也计划好了；
- 每当看完一个需求，把阅读进度更新为100&时，都特别有成就感，看着一个个需求被标注成100%，觉得越来越轻松；
不到三天，我就将十几个需求都阅读完毕了，记录了一些测试注意事项，还找到了不少需求问题，都通过钉钉发给了产品经理，他答复说，他会先收集，然后等需求评审的时候再一一解答。
我又在想，接下来的需求评审会议，我需要准备些什么呢？之前老大喊我参加需求评审，我主要也就是做下面三件事：
- 听开发在评审会议上提的一些问题，以及和产品经理的讨论内容，是否有需求文档没有提到的或从需求文档表面看不出来的一些注意事项和测试重点；
- 针对我在阅读需求文档时发现的问题，注意听产品经理的解释；
- 除了听，还是听；
现在既然要了解所有的需求，那在参加需求评审时，肯定就不能仅仅是听了，肯定还会有其他的事情需要注意，我得去跟老大取取经了。
这回，老大听完我的问题，并没有直接就告诉我需要做些什么，而是反问了我几个问题，让我先好好思考一下，等有了自己的答案之后，带着答案再去听他讲。
- 需求评审的意义是什么？
- 需求评审的作用有哪些？
- 什么样的需求评审才有作用？
- 怎么样才能让需求评审发挥作用？
我收获了什么
我不再把需求看成一个一个的独立个体，而是会按功能模块去划分，将同一个功能模块，或者相邻功能模块的需求划为一块，然后去勾勒需求块之间的脉络，去分析需求块之间的关系：独立、交互、依赖等等，依据这些关系，我再决定我的阅读顺序。
我也不再只着眼于当前项目的需求，我会结合着相关模块是否已经存在历史数据，来考虑是否存在数据兼容性问题，我也会根据是否为修改已有功能模块，来考虑是否跟之前的用户行为习惯和某些功能有冲突。
当任务突然变多的时候，不能忙乱，更不能慌张焦虑，我们应该多利用跨界的思想和方法，将其他领域里一些比较好的方法或工具稍作改造，尝试着去使用，往往会得到意想不到的收获。
将需求分块，并做成 To-Check-list 去计划性阅读，用到了 GTD 的方法，借用了清单这种工具，还利用了微习惯这种思想。
《告诉你如何从执行测试到管理测试》带你迈出第（6）步！，点击这里可查看完整地图
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
网友评论