專案中的評審分成了技術評審和管理評審。
技術評審分成了正式審查、組內評審、書面輪查、個人複查。
管理評審分成會議評審、會簽、審批。
實際上，要想做好一場評審會議，真的不是一件容易的事情。我早期參加專案的時候，要麼成了乙個需求討論會，要麼就是設計討論會議，或者乙個有領導參加的評審會議完全成了領導個人的脫口秀。嗯，確實非常痛苦！太浪費時間了。但是你會發現乙個共性的問題就是本應該是在會議前就要溝通清楚的問題或者事情，全部放到會議上說。
我們做過一次頭腦風暴，然後做了親和圖處理，總結了評審工作中的遇到的問題。不要總是抱怨你的團隊專家太少，或者找不到相關的專家，主要還是評審的準備工作做得不足。
你要想想要召開一場評審會議要準備哪些事情呢？
第一，要留足夠的時間給評審專家，不要匆匆開會。
第二，你要做好一張基礎的checklist**，讓每個評審專家按順序檢查，你要把發現的問題進行梳理和分類、總結。發現的問題要記錄是哪一頁，第幾行發現的。
第三，你要把不在檢查表中的專家發現問題進行收集，另外你要區分好什麼是問題，什麼是建議。這點很重要，問題必須改，建議的實用性強可以納入要改的內容，否則這就不用提了。
第四，你要在會議前就把這些問題都發給作者預熱，對沒有提出清楚的問題在會議上澄清和再解釋。已經識別的問題，要做好改不改的結論，有爭議的問題提交給專案經理。
最後你再召開會議，大家把問題過一遍，是否還有其它問題，最後給與通過不通過的結論，要改的問題修改後再提交，找提問題的人驗證一下即可。
基於評審驅動的專案管理
從人本角度看，專案管理由評審驅動，不是由需求驅動。評審的本質是利益爭鬥的過程，評審的結果是多方利益妥協的結果。需求是業務層面的概念，沒有談及專案管理的本質。專案管理是管理的一種，管理的本質一定是人。如何執行？先看幾個問題 1 評審的生死點？敝以為 決定評審生死的是評審結果對專案組成員的約束力 權威性...
專案管理（配置管理 評審 變更）
專案管理的內容 配置管理,評審,變更 三個內容都是不可缺少的.屬於公共的流程.配置管理 核心是版本管理 類似於 圖書管理員 但是配置管理是通過平台來操作的.配置管理所使用的 工具 svn,git 配置管理所管理的 內容 軟體 程式 需求文件,測試用例 的版本 專案中所有的 專案中用到的所有工具 所有...
在困難專案中進行評審問題
在困難專案中進行評審問題 專案執行過程中，整個網路系統技術方案由系統組提供，軟體組負責軟體子系統技術方案，軟體 實現，軟體測試 由於系統組缺乏經驗，專案中決定引入評審 在評審過程中要求軟體組參與 原因為軟體組可盡早了解系統方案 有利於解決人力資源的問題 其立意是好的，不過在實現上效果很差 原因如下 ...