這是《落葉》文集里第 312 片落葉，希望你能喜歡，不為別的，只為這份堅持。
第六章 天哪，我怎么可能了解所有的需求？（中）
我經歷了什么
之前做了一個 To-Check-list，并開始使用它來管理需求文檔的閱讀計劃，
應用之后的效果還不錯：
- 首先解決了忙亂的問題，不再一會 A，一會 B，又一會 C 了，因為都從大腦里騰到 To-Check-list 了，空間都讓給理解需求了；
- 也不會不知道從何開始閱讀了，因為開始前就已經把所有需求按優先級和模塊劃分好了，哪天看那幾個都也計劃好了；
- 每當看完一個需求，把閱讀進度更新為100&時，都特別有成就感，看著一個個需求被標注成100%，覺得越來越輕松；
不到三天，我就將十幾個需求都閱讀完畢了，記錄了一些測試注意事項，還找到了不少需求問題，都通過釘釘發給了產品經理，他答復說，他會先收集，然后等需求評審的時候再一一解答。
我又在想，接下來的需求評審會議，我需要準備些什么呢？之前老大喊我參加需求評審，我主要也就是做下面三件事：
- 聽開發在評審會議上提的一些問題，以及和產品經理的討論內容，是否有需求文檔沒有提到的或從需求文檔表面看不出來的一些注意事項和測試重點；
- 針對我在閱讀需求文檔時發現的問題，注意聽產品經理的解釋；
- 除了聽，還是聽；
現在既然要了解所有的需求，那在參加需求評審時，肯定就不能僅僅是聽了，肯定還會有其他的事情需要注意，我得去跟老大取取經了。
這回，老大聽完我的問題，并沒有直接就告訴我需要做些什么，而是反問了我幾個問題，讓我先好好思考一下，等有了自己的答案之后，帶著答案再去聽他講。
- 需求評審的意義是什么？
- 需求評審的作用有哪些？
- 什么樣的需求評審才有作用？
- 怎么樣才能讓需求評審發揮作用？
我收獲了什么
我不再把需求看成一個一個的獨立個體，而是會按功能模塊去劃分，將同一個功能模塊，或者相鄰功能模塊的需求劃為一塊，然后去勾勒需求塊之間的脈絡，去分析需求塊之間的關系：獨立、交互、依賴等等，依據這些關系，我再決定我的閱讀順序。
我也不再只著眼于當前項目的需求，我會結合著相關模塊是否已經存在歷史數據，來考慮是否存在數據兼容性問題，我也會根據是否為修改已有功能模塊，來考慮是否跟之前的用戶行為習慣和某些功能有沖突。
當任務突然變多的時候，不能忙亂，更不能慌張焦慮，我們應該多利用跨界的思想和方法，將其他領域里一些比較好的方法或工具稍作改造，嘗試著去使用，往往會得到意想不到的收獲。
將需求分塊，并做成 To-Check-list 去計劃性閱讀，用到了 GTD 的方法，借用了清單這種工具，還利用了微習慣這種思想。
《告訴你如何從執行測試到管理測試》帶你邁出第（6）步！，點擊這里可查看完整地圖
作者簡介：14 年測試 + 11 年項目管理 + 11 年團隊管理 = 一個測試老兵
