需求評審會議親歷記

最近參加了一次需求評審，整理了整個過程如下：

評審組構成：

由epg的組長擔任評審會議主持人，評審組成員有12個人，6個開發人員，包括專案經理，都是專案組內部的人員，1個測試人員，4個epg成員,1個外部諮詢顧問。

準備工作：

（1）提前1天發了會議通知，沒有為評審組成員準備檢查單。

（2）有2個人提前進行了準備，閱讀了被審查文件，但是只找出了2-5個問題

（3）qa提前進行了文件與標準符合性的檢查。

啟動階段：

（1）原計畫9點開始，9點15分才正式開始，有3人遲到。

（2）主持人首先宣布了會議規則：

n 手機震動：在過程中有人不符合規定

n 同時只能1個人發言

n 評審組成員可以隨時中斷閱讀者閱讀文件

（3）主持人宣布會議議程

（4）指定了記錄員

評審階段：

（1）pm逐字讀文件

（2）過程中有參與人員手機振鈴，沒有打到震動

（3）專家提問，和作者、pm進行討論

（4）閱讀者在閱讀時發現描述有問題

（5）專家對文件中的術語不理解，進行溝通術語的含義

（6）專案組內部的成員對同乙個需求有不理解的地方

（7）記錄員有時候參與討論，沒有記錄問題

（8）會議中有人長時間外出打**

收尾階段：

（1）記錄員宣讀記錄的問題，評審組成員發現有2個問題記錄的不準確，遺漏乙個問題，有乙個問題是理解問題不是缺陷，有1個問題是待定項，需要繼續研究。

（2）諮詢顧問公布度量資料、點評本次過程的優缺點

（3）主持人宣布會議結束

度量資料：

（1）評審規模：需求規格說明書 12頁

（2）（3）

參與人數：12人

（4）評審工作量：15小時

（5）發現的問題個數：15

（6）評審效率：平均每小時發現1個問題

（7）其他：有2個專案組成員沒有發現問題，測試人員沒有發現問題

諮詢顧問的點評：

（1）事先沒有給專家準備檢查單，可能是造成本次評審效率低的原因之一。

（2）評審組成員沒有提前進行的個人評審，可能是造成本次評審效率低的原因之一。

（3）評審組成員沒有按時參與會議，耽誤了3個人時的工作量，該時間沒有統計在評審工作量中，否則評審效率更低。組織應該建立守時的文化，應有獎懲措施。

（4）沒有給專家分配明確的角色，可能是造成本次評審效率低的原因之一。

（5）會議中有**響，未打到震動。

（6）在會議中專家可能提出不切實際的需求，專案組的成員需要進行判斷。評審需要安排專家參與，如果參與者不是專家，決定權應掌握在專案組手中。

（7）記錄員要詳細記錄缺陷的位置，並清楚的描述問題。對記錄員應進行事先的培訓。

（8）閱讀者逐字逐句讀文件，速度太慢，pm沒有很好的控制會議效率。看的速度高於讀的速度，閱讀者應講要點，而不是通讀。需要在評審開始時對參與的人員與閱讀者進行培訓，並在會議中及時控制節奏。

（9）參與人員比較多，有的人沒有對評審結果有貢獻，以後可以考慮減少參與人員，提高評審效率。

（10）本次評審屬於走查，不是正式的審查。

需求評審會議親歷記

最近參加了一次需求評審，整理了整個過程如下 評審組構成 由epg的組長擔任評審會議主持人，評審組成員有12個人，6個開發人員，包括專案經理，都是專案組內部的人員，1個測試人員，4個epg成員,1個外部諮詢顧問。準備工作 1 提前1天發了會議通知，沒有為評審組成員準備檢查單。2 有2個人提前進行了準備...

需求評審會議如何召開

需求評審會議如何召開 需求評審會的目的，是為了讓相關人員，對產品的需求方案達成共識，讓boss提前知道完成專案所需的資源投入等等 由於相關人員較多，需要討論的問題也較多，所以會前對會議的全面準備，反覆預演練，是乙個產品對於每個需求評審會，都一定要做到的 1.評審會前 會前較為必要的是複雜問題或容易有...

Scrum評審會議

會議目的 scrum 團隊在會議中向終端使用者展示工作成果，團隊成員希望得到反饋，並以之建立或變更 backlog 條目。基本要求 sprint 複審會議允許所有的參與者嘗試由團隊展示的新功能。構成部分 有可能發布的產品增量，由團隊展示。會議輸出 來自終端使用者的反饋。障礙 backlog 的輸入。...