评审的作用与重要性

会议不欢而散，老Q觉得要找小M好好谈一下。老Q开门见山地告诉小M，评审的目的是尽早发现问题。这次评审会不但流程不符合要求，而且一团和气的讨论方式也完全达不到发现问题的目的。

老Q举了个例子：假设有个需求理解的缺陷，如果在需求阶段发现，修改一下可能只要一个小时；但到了设计完成时发现这个缺陷，因为涉及的人员、文档增多，估计至少一天；而等到代码都编写完成时再发现这个缺陷，连改带测没有十天八天肯定完不成。如果缺陷没被发现到了生产系统中了呢？就不是工作量的问题了，那损失将难以估计。在质量管理的理论中，缺陷每延迟一个阶段被发现，修复的代价就要乘上十倍。

最后，老Q真诚地说：“真正的评审看似在找茬，其实却避免了将来的麻烦。现在找的茬越多，以后的麻烦就越少。你说，如果我现在草率地让评审通过，是帮你还是害你？”

听老Q这么一说，小M终于理解了老Q的用心。表态支持老Q关于重新评审的意见，但他也提醒老Q，项目组里很多同事对于评审的看法和小M原来的理解差不多，都认为是走走过场。建议老Q先给大家做一次评审培训，让大家统一思想；然后，再组织一次“真正的评审”，给大家做个示范。

老Q听后欣然答应，精心准备了些资料，找了个时间把项目组的同事们召集在一起便侃侃而谈：

IT系统在能够真正运行前，需要很多前期的分析、设计工作，这些工作决定了系统最终能否正常运行。但由于这些工作大都落在纸面上，验证其正确性不那么直观，所更多依靠一些有经验的专家通过书面审核的方式来确认工作是否达到要求，这就是我们常说的评审。(www.xing528.com)

有一些人认为等系统开发出来，运行一下不就知道有没有问题了。有就再修改修改，不评审也一样能能完成工作。这想法也不能算错，只是这种方式就像小孩子搭积木，随手往上搭，到某个时候会塌下来，然后需要重新再搭一次。但如果是实际IT系统的建设，恐怕就没有重来一次的机会了。为了不至于在最后一刻倒塌，过程就要不断评审。这样才能让项目的每一步质量都有保障，降低后面返工的风险。

平时一堆人给你挑刺提意见你可能不太乐意，但这时只有这样做才能找出存在的问题，体现评审的价值。所以，要想让评审发挥作用，真正该苦恼的不是挑出了很多毛病，而是有毛病没被挑出来。

中国人讲究和为贵，相互挑毛病的事轻易不愿做；“事不关己，高高挂起”，因此很多评审会请了专家、评审了半天也提不出一两个一针见血的问题来。这样的评审会流于形式，开和不开一个样，时间长了大家对评审的观念就是走过场！这次评审结论是不通过，希望以此为转折点改变大家对评审的观念。

老Q有理有据地谈了一番，同事们心服口服地纷纷称是。小M也庆幸有老Q这么一位铁面无私、尽心尽力的搭档帮他把住了关。项目组都非常愿意配合老Q重新评审，让评审真正起到作用。