現象1：沒有遵循2/8原則注意評審的重點
要評審的對象內容需要有側重點，一般按照2/8原則確定主要內容進行評審，而不要泛泛地對整篇文章進行處理。
現象2：就某個文檔而孤立地評審該文檔，沒有對照已有的成果和標準
需求和設計是軟件開發項目的中間文檔，前面會有一些約定輸入，也可能會要求遵守相關標準。除非是對這些輸入的內容已經了如指掌，可以敏感地發現互相之間的不一致性；否則一定要考慮仔細對照相關的輸入。
就某個系統而評審該系統，沒有考慮相關系統。當客戶或企業已經開發了多個軟件系統之后，系統之間的相關性必須是考慮的因素，這些相關性包括數據之間的關系、業務之間的關系、用戶管理、系統管理的一致性，操作習慣和界面的關聯性和軟件復用等。
現象3：會議上過多地討論問題如何改正
評審的目的主要在于定位問題，一旦正確地確認了問題，大多數都能很快找到解決方案，對于一時無法給出解決方案的問題可以在評審后研究討論。
因此，一般的同行評審會建議如果在一個問題上超過3分鐘，可以做出結論并到下一個問題；如果評審專家之間有不同意見，做出記錄，得到結論并到下一個問題。
當評審專家討論起解決方案時，主持人可以要求他們在會后討論。
現象4：評審與評價混淆
評審的目的是指出具體問題以便改進，評價是給最終工作結果及人員工作績效下結論。不能把這二者混為一談，尤其是把評審結果作為評價個人能力的指標時，對評審活動的進一步開展很不利。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
