5．评审工作完整性
评审工作的完整性很重要，遗漏重要的部分可能造成不可估量的损失，这方面的建议主要有以下几条。
① 规划好应该评审的不同的部分、角度和层次。
② 不同的人员评审覆盖不同的部分或角度。
③ 大规模的软件可分物理或逻辑部分进行评审。
④ 要考虑软件系统的泛一致性，要兼顾前后左右系统和标准。
⑤ 要考虑各阶段工作成果的可追溯性，上下游的作者可互相评审，如设计人员评审需求，分析人员评审设计。
⑥ 需求和设计变更是难免的，要给出需要进行“变更评审”的准则，注意必要的评审。
麦肯锡系统思维的结构化思路核心概念Mutually Exclusive Collectively Exhaustive（MECE）对我们评审工作的完整性具有深刻的指导意义。
评审工作就应该在整体思维下做到没有遗漏，没有重复。但是为了更好地利用有限的资源条件，要有优先级并突出重点。
6．关于组内评审的建议
不拘形式，随时评审（检查和走查）。同一个项目团队的成员如果作为安排比较方便，可以随时对需求或设计进行讨论。
安排团队内部不同人员可从不同层次和角度评审不同的部分，无法覆盖的部分或比较薄弱的部分一定要请求公司安排资深技术人员进行评审。
组内评审的缺点之一是评审的水平问题，受项目组内水平限制，有些潜在的问题可能发现不了。
组内评审的缺点之二是团队成员可能存在不愿提问题的心理，特别是在分析或设计人员是项目经理或资深技术人员的情况下。
不同的项目可以采用不同的评审策略，但组内评审都是必需的，只是形式可以灵活随意。如定制开发需求的评审策略可以是：用户评审→组内评审→组外非正式评审→正式评审；定制开发设计的评审策略可以是：组内评审→组外非正式评审→正式评审；产品研发的评审策略可以是：产品组内评审→项目组内评审→组外非正式评审→正式评审。
当然，（正式的）组内评审也可不单独进行，而是与“组外评审”同时进行。
相关链接：
