這是《落葉》文集里第?324?片落葉，希望你能喜歡，不為別的，只為這份堅持。
第十章 為什么需求評審總是那么的耗時費力呢？
在經歷了幾天的思考、答題、學習、討論和整理之后，終于迎來了第一次需求評審會議，我一個人去參加了這次會議，因為產品經理說，這次主要是針對需求的概要、優先級和技術可行性，所以不需要所有具體執行人參與。
參加完這次算是需求初評會議之后，我發現，除了我之前從老大那和書本上學習到的東西之外，還對之前老大在管項目時的一些任務安排有了不一樣的認識。原來有時候會奇怪老大為什么不在需求初評之前就分配任務給我們呢？
現在自己參與了，才大概明白了一些，在沒有開始評審之前，我根據需求的概要和初稿，對那些需求只是有了自己的認知和理解，但并不全面，也不一定正確，那時候如果就將任務分配掉，可能在模塊關聯性和測試量上并不合理。
所以，通過需求初評會議了解了關于需求背景、商業價值、優先級，以及討論需求可行性時提及的技術方案，可以對需求的功能模塊或業務分類，以及大概的測試復雜度和工作量有個基本的認知，基于這些，就可以相對合理地做任務分配了。
分配完任務，我簡單設定了一個時間節點，讓各個需求的任務責任人開始閱讀需求初稿，同步地，我也會將陸續完稿的需求文檔轉發給相關責任人，讓他們按照前面說的需求評審檢查表做一輪測試，將問題及時反饋給對應的產品經理。
當需求文檔完稿之后，產品經理通常會立即召開正式的需求評審會，這時候一般不會只開一個會議，而是會拆成幾個會議，所有具體的需求負責人都需要參加。這些個會議，老大要求我都要參加，具體的需求文檔的問題或不清楚的地方，如果會議前沒有弄清楚，具體的負責人都會帶著去參加評審，在會議中問清楚。而對于會議中沒有討論清楚或得到解答的問題，包括在會議中碰撞出的一些新問題，相關需求責任人要在會議之后持續跟蹤，直到弄清楚為止。
而我做為項目的測試負責人，參加所有的需求評審，一方面是為了了解熟悉所有功能性需求細節，另一方面主要是針對一些非功能性需求，去明確一下相關的測試必要性和可行性，比如兼容性測試、性能測試、安全測試等等。同時，這些對后續評審所有的測試設計都非常有幫助。
另外還有兩點特別需要注意:
1. 在需求評審會中，有關業務邏輯遺漏較多或對不清晰的地方爭議較多時，一定要堅持要求復評，因為產品經理往往會為了省事，在會后補充一下，就直接把更新后的需求文檔發給項目干系人了，而新補充的那些內容，可能因為沒有經過會議評審，而導致每個人都有不一樣的認知和理解。
2. 需求評審會里大家提出的所有問題，都得要求產品經理記錄下來，一一解答或澄清，并在需求文檔里修訂或標注出來，在復評的時候快速回顧一下。盡可能地把問題都在需求評審階段給弄清楚了，這樣可以大大減少在提測之后，發現產品經理、開發和測試對于某個需求點的認知和理解都不一致，而把大量的時間浪費在重新討論需求，決定是否要修改當前的實現，或者說判定某個 Bug 是不是 Bug這類事情上。
《告訴你如何從執行測試到管理測試》帶你邁出第（10）步！，點擊這里可查看完整地圖
作者簡介：14 年測試 + 11 年項目管理 + 11 年團隊管理 = 一個測試老兵
