你一定聽說過這樣的一句話——每天不是在開會，就是在開會的路上，
這句話其實是對會議多情況的一種調侃，但同時這句話里也帶有一些對開會反感，
不過請大家想一想，為什么我們會反感一些會議？很大一部分原因是這些會議冗長且毫無結果，效率非常低，
為了盡量減少這種情況的發生，我會分享一種專案會議當中比較重要的評審會議，讓大家告別無意義meeting，
本文主要講一下評審會議的必要性，以及如何高效開展評審會議，
什么是評審
評審，指評議和審查、審議，
為什么要進行評審
01
評審一般是集體活動，有助于從多角度提升作業產品（即評審物件）的質量，
評審的與會人，可能包括專案干系人、技術專家、業務專家、高層管理者，那么與會人的角色不同，對于作業產品的評判角度也是不同的，
例如，在實際專案中，當針對測驗設計檔案進行評審時，產品經理更關注用戶需求有沒有得到全面覆寫，開發人員更關心他們對需求的理解與測驗人員是否一致，測驗評審專家除了關注業務功能有沒有覆寫到之外，還會評審測驗設計方法是否合理，是否考慮了各個質量屬性，
02
評審會議可以提供一個貧訓，針對一些爭議點進行討論對齊，做到統一思想，
例如，評審需求規格說明書時，專案多方干系人都會在場，一方面可以圍繞每條客戶需求做好澄清，另一方面，各評審人員可以從各自的專業角度出發，提出需求存在的問題，或者檔案沒有闡述到的方面，
比如一款APP，產品經理在需求評審會上講解關于用戶注冊/登錄的需求，
測驗人員由于具備APP使用方面的豐富的經驗，會提出針對這個需求的更細節方面的問題：
- 用戶是先注冊再登錄還是登錄即注冊
- 是否既支持驗證碼登錄又支持密碼登錄
- 驗證碼的有效期是多久
- 用戶登錄一次的鑒權保存的時間是多久
- 是否要做用戶取消注冊的入口等等
隨后，針對這些新提出來的需求點，與會人會盡量達成一致，會上無法統一觀點的，記錄會議紀要，會后倍訓，
03
作者自己很難發現自己的作業產品的問題，
曾經在一本書上看到這樣一個觀點，我覺得非常有道理：因為你記得你的工序，所以，你會認為你的作品是正確的，
其實，這是人在輸出產物時候特定的思維方式和輸出流程導致的，不管輸出的是什么，你的程序通常都是：想出一個思路，然后按照這個思路一直理下去，最后把思路實作為成果，
所以，你的思維方式一直是正向的、順序的，并且你對整個程序太熟悉了，熟悉到你認為一切都是正確的，這其中當然也摻雜著對自己的“寶貝”的偏愛，
這個時候，評審的作用就體現出來了：找一些毫不知情的人來提意見，因為他們不清楚產品的輸出程序，也不會摻雜私人感情，此時他們的評價就是客觀的，
另外，大家一定也有過同樣的經歷，你剛寫出來的東西，怎么看怎么順眼，但是過了1-2兩個月再次閱讀，你可能會發現很多不合理的甚至是錯誤的地方，
04
評審是一種靜態測驗，性價比高，
這項活動可以使問題提前暴露，且測驗成本較動態測驗低，修復成本也低，
例如，如果在需求評審階段，就識別出來客戶要求支持兩種支付繳費方式：微信和支付寶，而需求檔案中只提到了微信支付，此時，只要更新需求檔案即可，
但是如果到了編碼階段才識別出來，那么，會造成編碼返工，甚至架構調整，如果再晚一點，到測驗階段才發現此漏洞，會導致更大量的返工，并且對專案進度造成更明顯的影響，從而極有可能導致專案的失敗，
試想一下，如果再晚一些，等到版本發布給用戶去使用之后，由用戶提出來，影響會怎樣？損失的是什么？
可見，評審階段修正錯誤的成本有多低！
那么，到底什么情況下需要啟動評審活動，評審有哪些型別呢？下面只舉一些常見的例子，
評審的型別
01 作業計劃評審
主要包括專案計劃、開發計劃、測驗計劃等，
02 設計檔案評審
概要設計、詳細設計、測驗設計，
03 代碼評審
版本開發代碼評審、自動化工具代碼評審，
04 管理評審
版本發布評審、缺陷評審、風險評審，
如何更好的開展評審
評審本身可以看做是一種特殊的會議，想要更加高效，那么會前充分的準備、會上高效的評審、會后嚴格的倍訓都是非常重要的，
下面列舉了對評審成功進行至關重要的幾個因素，
01
評審物件作者已完成初稿(具備評審條件的初稿)，
和軟體產品一樣，如果評審物件沒有達到入口條件，僅僅是個半成品，會浪費評審相關人員的時間，甚至影響專案進度，
02
評審主題、評審目的已明確，
評審主題和目的不明確，則會出現在評審會議上漫談一些與評審物件無關的話題，浪費時間，
比如，一個評審軟體產品是否能夠發布的決策會議，在不清楚評審目的的情況下，可能會出現開發和測驗在討論bug的產生原因，偏離會議主題，
03
確定好評審時間、地點，以及與會人、組織者、主持人、紀要人，
與會人名單不準確，會出現評審會上一些重要關鍵人員不在的情況，
紀要人不明確，會導致會上的重要資訊沒有得到及時記錄，從而形成低效會議，甚至是無效會議，
04
會議材料提前下發給與會人，并預留足夠的時間進行獨立評審，
一個草草組織、無充足時間瀏覽會議材料的會議，可想而知是什么樣的，
與會人直到會議開始才第一次見到相關檔案，評審時，經常停下來理解檔案想說什么，這樣的會議，就像盲人摸象，簡直就是在浪費時間，
05
正式評審會議上，評審主持人具備足夠的組織協調和溝通解決能力，保證會議秩序，控制好會議效率和效果，
下面是測驗資料，對于做【軟體測驗】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你！
最后： 可以在公眾號：傷心的辣條 ！ 免費領取一份216頁軟體測驗工程師面試寶典檔案資料，以及相對應的視頻學習教程免費分享！，其中包括了有基礎知識、Linux必備、Shell、互聯網程式原理、Mysql資料庫、抓包工具專題、介面測驗工具、測驗進階-Python編程、Web自動化測驗、APP自動化測驗、介面自動化測驗、測驗高級持續集成、測驗架構開發測驗框架、性能測驗、安全測驗等，
學習不要孤軍奮戰，最好是能抱團取暖，相互成就一起成長，群眾效應的效果是非常強大的，大家一起學習，一起打卡，會更有學習動力，也更能堅持下去，你可以加入我們的測驗技術交流扣扣群：914172719（里面有各種軟體測驗資源和技術討論）
喜歡軟體測驗的小伙伴們，如果我的博客對你有幫助、如果你喜歡我的博客內容，請 “點贊” “評論” “收藏” 一鍵三連哦！
好文推薦
轉行面試，跳槽面試，軟體測驗人員都必須知道的這幾種面試技巧！
面試經：一線城市搬磚！又面軟體測驗崗，5000就知足了…
面試官：作業三年，還來面初級測驗？恐怕你的軟體測驗工程師的頭銜要加雙引號…
什么樣的人適合從事軟體測驗作業？
那個準點下班的人，比我先升職了…
測驗崗反復跳槽，跳著跳著就跳沒了…
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/325547.html
標籤：其他