主题：【整理帖】评审相关知识

评审的形式
1．人

如果就参加评审的人员而论，有以下几类评审形式。

① 同行评审（Peer Review）：也翻译为“同伴评审”或“同级评审”或“对等审查”等。由软件开发文档的编写者的同事对软件文档进行系统的检查，以发现错误和检查修改过的区域，并提供改进的建议。

② 独立评审：安排一些人对成果进行个别检查，以单独完成对成果的评审，评审人员相互之间暂时不进行讨论。

③ 组内评审：项目团队内部组织的对成果的评审。

④ 相关项目成员评审：相关项目成员可以分为横向和纵向两类，所谓横向，指与本项目同时进行的项目的成员；所谓纵向，指历史上已经开发与这个系统有关的软件系统项目的成员。在必要时，也可以请规划中即将建设的软件项目的成员参加。横向和纵向可以是针对同一个用户而言，主要是为了在客户的业务上进行统一的规划设计，如统一的用户账号管理及统一的用户信息代码管理等；也可以是针对公司内部而言，这主要是在软件的技术和设计风格上进行统一的规划。以充分利用软件复用技术来提高效率和易维护性，充分考虑各系统之间的接口、兼容性和界面一致性。

⑤ 企业内评审：也可以称为“项目组外评审”，是企业内部抽调必要的力量进行组织的，有条件时也可请用户参与。相关项目成员评审是企业内评审的一种特例。

⑥ 邀请专家评审：在特殊情况下或为了特殊的目的，管理层或用户邀请专家对阶段成果进行评审。这些专家可以是软件技术方面的专家，也可以是与客户业务密切相关的行业业务专家，如国家某个行业信息规划人员和行业标准制定人员等。

⑦ 用户评审：以用户为主的评审，一般是把文档交给用户检查，或以用户为首组织的评审会议。一般情况下，每份需求文档都要经过数次的用户评审，尽可能地得到最终的确认。而设计文档则视情况而定，一般较少进行用户评审。

⑧ 第三方评审：用户委托第三方机构进行评审，如监理机构、检测机构和专家验收组等对需求设计文档或其他工作成果进行评审。

2．对象

如果就评审的对象完整性而论，有以下几类评审形式。

① 整体评审：在文档整体完成后，对需求或设计文档的整体进行评审。当文档比较大而难以进行整体评审时，可分而治之，分多次进行“部分评审”。

② 物理部分评审：不同评审人员对某一成果的某些物理部分内容进行评审，如按照文档章节、功能划分或模块划分等。

③ 逻辑部分评审：分阶段检查某一成果是否具有某个所期望的特性，或不同评审人员对某一成果的某些特性（如可读性或可维护性）要求进行评审。

④ 迭代评审：迭代开发模式中分阶段对部分内容进行评审，每一部分评审通过后即可作为下一阶段相关部分工作的基础，每一次迭代都包括需求、分析、设计、实现和测试活动。同时每次迭代都建立在前一次迭代工作的基础上，每次迭代都会生成更加接近最终产品的可执行版本。

⑤ 回归评审：原来的评审发现问题需要整改并再次进行的评审，以检查问题是否已经得到修改，同时检查是否出现新的问题。

3．环境

就评审的环境或使用的工具而论，有以下几类评审形式。

① 临时检查：在需要的情况下临时检查文档、评审人员与作者随时对文档中的问题进行讨论。这是评审中最不正式的一种，可以快速听取评审人员的意见。主要为了解决当前的某个特定问题，或对某个特定问题进行确认。临时检查也翻译为“专案评审”（ad hoc）或“随时评审”，可以及时沟通，及时发现问题。但要注意适度，在必要时进行。

② 工具评审：通过安装在网络环境上的管理工具软件将项目阶段成果提交给评审人员阅读，评审人员利用工具阅读文档后填写意见（如Domino.Doc）。

③ 邮件评审：通过邮件将项目阶段成果发给相关人员进行评审，评审人员通过邮件反馈意见。

④ 会议评审：相关人员集中在一起开会对项目阶段成果进行评审，这是最常用的形式。所以当提到“评审”时，很多人就会自然地联想到开会。

⑤ 远程会议评审：不仅在主会场进行评审，而且通过视频及音频与外地的评审人员进行实时在线沟通。这是会议评审的一种特殊形式，可以突破空间的限制，对于项目团队成员或评审人员有出差在外的项目是一个比较经济的形式。

4．效力

① 正式评审：得出是否批准通过的正式结论。

② 非正式评审：不具否决权的“评审”，也可以称为“评阅”，主要是为了讨论，收集意见和建议，不做是否批准通过的结论。

正式评审或非正式评审都可以通过会议、邮件及工具的各种形式，也可以是整体评审、部分评审或迭代评审。当然正式评审最好是整体文档完成后的评审，批准主要是针对整个文档的，但迭代开发的例外。

③ 观摩培训式评审：一般是一种会议形式，主要是为了培养新人。在评审会议召开时，可安排一些不同角色新人来旁听。他们不对评审的工作负责，而是以学习评审技术，体验评审工作为目的。

评审的作用和目的
在团队开发中，充分的沟通是非常有必要的，沟通的方式之一就是通过文档。不论评审的效果如何，发现多少问题都可以让相关人员了解需求与设计。而通过相互之间的讨论，澄清一些模糊的认识，进一步理解文档的含义。评审不但是软件开发活动中一个重要的质量控制机制，而且也是一个重要而有效的沟通方式。通过评审可以利用企业内部各种优秀成员的智慧，为软件开发寻找最佳的解决方案。

评审的作用和目的主要是尽早发现潜在的问题，尽早纠正缺陷，控制纠正成本的滚雪球效应。本阶段造成的错误如果能够及时地发现，或者在后面越早的阶段发现，就能够及早发现潜在的风险，及时做好防范的对策，做到未雨绸缪。

评审的过程不仅是为了发现问题，而且为了便于跟踪及改正，还应当对问题进行记录。特别是需要对问题的真实性进行确认，剔除可能是误解、似是而非或不必采纳的建议性问题。正如著名软件大师Gerald M Weinberg在《你的灯亮着吗？》所说：“一旦我们知道问题是什么，那么该问题的解答或解决对问题本身来说就是一件微不足道的事情。”确实，人们经常会把一些表面的现象当成问题，而不知道根本的问题是什么？不知道真正的问题出在哪里？这样解决问题时就很有可能头痛医头，脚痛医脚。

具体来说，评审最直接的作用和目的当然是要改进需求与设计文档本身，为下一阶段工作提供正确的基础，并通过评审的过程提高相关人员的总体分析设计及文档写作水平。当然，写需求或设计等技术文档，并不等于会“做”需求分析和设计。因此有些刚参加工作的新手急于找一些模板或样例照葫芦画瓢，把文档完成就说“我会做分析”、“我会做设计”，其实只是刚起步而已。而评审不仅能够看出文档本身的问题和水平，也可以看出分析设计的过程和水平。

评审的作用和目的还在于强化开发人员的责任感，这是基于“把关效应”。即分配工作任务时，是否事先声明设置检查点，直接关系到工作任务完成的质量和效率。日本软件开发企业非常重视用验证与确认来强化开发人员的责任感。

丰富行业业务经验和评审经验并改进评审流程，使项目进度安排更加合理也可以作为评审的作用和目的。

当然，评审的最终目的无疑是提高软件质量，减少各种无形损失。

评审的必要性
软件阶段评审是软件质量管理中较重要的措施之一，做得好可以及时有效地发现一些错误。对于评审的必要性相信读者都有一定的认识，但是认识未必是一致的，这里列举一个社会新闻中的典型事例来说明。

前一阵子在电视上有一条新闻，为了防止长途客车上的抢劫与盗窃，有关单位在福州开往漳州的大巴上安装了摄像头监控装置。记者为此采访了一些乘客，大部分的乘客都表示这是一个防抢防盗的有力措施，必将有效控制日益猖獗的车上抢劫与盗窃行为。然而也有少数乘客提出了反对意见，他们认为小偷只是少数，安装摄像头监控让他们的个人隐私暴露无遗。有时想和女友亲热一下都要被人监视，没有必要为少数犯罪分子来侵犯大家的隐私权。

由以上事例可见，对于某些问题的防范措施的出台的必要性并不是大家都有共识，而是会有各种不同的声音。对一件事情有不同的声音是正常的，我们也没有必要以对错来评判，每一种意见都要考虑才能更好地做到适度管理。

在质量管理方面，每次出台一项措施也会有不同的声音。这些措施包括检查、评审、测试和验收等，必然会给辛勤劳动的一线人员带来一些不便，给公司增加预防成本。但采取必要措施而增加适当的预防成本还是很有必要的，只是要遵守适度控制和具体问题具体分析的原则。当然质量管理不是监视，更不是对付坏人，而是针对工作中可能发生的错误。

为了进一步说明评审的必要性，我们引述美国著名的认知心理学家诺曼（Donald A. Norman）先生在其《设计心理学》中的一段精辟的论述：“每一项新技术问世时，新一代的设计人员总会重蹈覆辙。从过去的错误中吸取经验教训不是技术人员的专长。他们总是展望未来，而不愿回顾历史，因此重复出现同样的错误。”（这个观点是不是有点打击技术人员，不知读者是否认同他的观点？技术人员可要争口气！）

中国人说：“人非圣贤，孰能无过。神仙打鼓，也会出错”。老外说：“It’s a human error!”。所以人都可能有错，而且有些错误较容易逃过自己的眼睛。特别是有些人，比较容易看到别人的错误，却难以看到自己身上的错误。其原因不外乎思维定势（即思维习惯和心智模式等）、学识局限（没有谁是万能的），以及无意疏忽（老虎也有打盹时）。

Karl E.Wiegers在《软件同级评审》中说：“如果你没有时间采用同级评审来提高产品质量，则将需要更多的时间去纠正测试人员或客户发现的缺陷。……评审的最主要障碍来自开发人员没有意识到他们已经犯了多少错误，因此他们也看不到查找或减少错误的必要性。”

所以为了有效地提高软件质量，我们很有必要用他人的眼睛来审视自己。邀请不同背景的评审人员从不同的角度检查，弥补个人的不足，及时发现并解决自己发现不了的错误，即使是两次发现同一个错误总比把它漏掉好。需求与设计评审就是在进行下一步工作之前“互相用他人的眼睛来审视自己”，必然会提高项目的成本。而这种成本是质量成本的一部分——预防成本，其目的是减少失败成本（包括返工、维护、变更、重新测试、满意度下降、形象损坏，以及顾客流失造成的损失）。

工作建议：
如下评审工作建议主要在效果的保证、工作的导向、人员心理、避免盲目信任，以及保证完整性等方面。

1．保证评审效果

没有效果的工作还不如不做，所以做一件事情首先要考虑如何保证效果。

要保证评审的效果首先应当保证资源，不但要保证评审的资源应当是质量合格且数量充足的，也要保证被评审的资源，使他们能及时地拿出“不冒烟的”阶段成果，及时地修改错误。

应当在公司层面结合行政管理与人力资源管理，建立保证评审效果的保障机制。

评审与评价相结合将更能保证效果，虽然要区分评审和评价的区别，使管理人员不会不恰当地使用评审数据。但如果评审发现的问题的修改情况不与对项目团队或被评审人员的评价挂钩，评审的效果就会大打折扣。所以应该先评审后评价，评价是针对评审效果和最终成果的评价。也许在评审的过程中发现很多问题，但是这些问题如果都已经改正了，就应该给与鼓励，而不是以原来的文档有多少错误来评价这个项目或文档作者。

很重要的一点在前面也已提到，应当做好评审规划、评审准备并分清职责。评审规划和评审标准提前通知相关人员，评审人员应该带着问题进入评审会议。军事上说“不打无准备之仗”，外国人说“Haste makes waste”，古人说“磨刀不误砍柴工”，都指必须做好准备工作。

评审效果取决于评审人员的素质和投入，所以应当根据项目情况确定评审级别并挑选评审人员。避免“盲人给盲人引路”，必要时邀请行业业务标准制定人员参与评审。

评审事先应该建立入口和出口准则，评审开始应当符合入口准则，评审的结束应该符合出口准则。

如果文档不容易理解，结合原型演示进行评审会起到更好的效果，特别是对于有用户参与的评审来说。

适度评审，分清缺陷与建议。缺陷是一定要修改的问题；否则会造成质量问题或成本及进度问题；建议可以采纳，也可以不采纳，项目组视情况而定。因为建议可能“镀金”，所以评审人员应当尽可能不提“镀金”的建议，同时也要在评审中指出需求或设计中出现的“镀金”问题。当然，对于“镀金”问题也要一分为二地看。有的“镀金”可能会形成产品的一些“亮点”，同时在成本上增加的投入又比较少，可以考虑保留。但对于投入成本太高，又不会有什么效果的就应当放弃。对于一种方案是否“镀金”，不同的人会可能有不同的看法。因此评审也要综合考虑ROI投资回报率，因为企业存在的目的就是赚取利润。

要注意评审工作不管采用什么形式，形式只是手段，关键看效果和效益。

问题：如何看待编码快完成才进行文档评审，这样的评审是否走过场？

个人观点：由于项目条件的复杂性，编码快完成时文档才完成，这样的情况还是比较常见的。很多人因此就认为这时候评审是形式主义，走过场。“编码都编完了还有必要进行文档评审吗”？甚至有些人对于文档的必要性都提出了质疑。

确实，在开发过程中，由于口头沟通比书面沟通来得方便快捷，所以先以口头沟通方式使读者完成软件编码是常有的事。但笔者认为如果条件允许的话，还是很有必要尽可能早地在软件交付之前进行评审。一是因为这时候评审还是可以帮助发现潜在问题的，纠正还来得及；二是可以帮助对软件的评价提供某些方面的依据；三是为后面的软件维护工作留下一份合格的文档。

2．注意评审工作导向

现在都讲“以人为本”，什么是以人为本？每件事情都是人做的，特别是软件开发离不开人。人的素质决定了成果的质量，所以人的素质是最重要的因素。每件事情是为了特定的人群做的，工作成果是否符合这部分人的需求很重要，所以人的需求也是最重要的因素。

因此评审中的“以人为本”是指人的素质与人的需求是最重要的，这里的“人”包括了与软件系统相关的所有的人—项目团队、企业、用户和软件的社会受众等；素质包括与项目相关的人的素质，在这里特别强调的是评审人员的素质；需求最主要是用户的需求，但也包括组织和项目成员的需求。

因此评审工作应该以人性导向、用户导向、成本导向和社会导向。

Jesse Liberty在《Clouds to Codes》中强调：“不要让客户离开你的视线，他们不关心你的技术是否先进。”在《客户驱动编程》中的一句话应该引起“技术导向”的人员的思考：“软件开发的目标不是创建伟大的软件，而是帮助客户创造财富，有人买才是开发软件的惟一目的。”

软件大师温伯格也说：“如果不明白自己在做什么，技术是毫无价值的”（在此不是宣传技术无用论，而是提醒人们要从技术中去发现人的需求，从人的需求出发去开发技术）。“质量就是对相关人员的价值”，比如对企业的价值是赚取了利润，对用户的价值是服务了社会，对项目团队成员的价值是学习了新的技术、经累了经验并获得了相应的报酬。

Donald A. Norman在《设计心理学》中提到“诺曼门”的概念，那些因为设计不周而难以打开的门、令人迷惑的电灯开关被称为“诺曼门”或“诺曼开关”。依此类推，难以使用的软件可以称为“诺曼软件”。作者感叹世界上有太多的东西在设计和制作过程中根本就没有考虑或是毫不在乎用户的需要，称某种产品为“诺曼门”，实际是承认了该产品的制作者没有关注用户的需求。每当一项新技术被开发出来，公司便把过去的技术抛开，让工程师制造出新颖、前卫且功能众多的产品，结果是用户不断陷入迷惑。要设计出以人为中心并方便适用的产品，设计人员从一开始就要把各种因素考虑进去，协调与设计相关的各类学科，用户需求应当贯穿在整个设计（软件开发）过程之中。

我们不妨把需求和设计评审工作中涉及的“人”分为如下4类。

① 客户、用户、老板和社会受众：我们说以用户为导向，用户是第一位的，但老板才是项目真正的“客户”。而客户的需求也有可能符合某些“标准”，也有可能他们不了解某些标准或不愿意遵守某些标准，因此无论是评审人员还是项目团队都要在这几个方面进行平衡。

② 文档作者：他们在完成文档后一般具有成就感和自豪感，同时又担心被奚落。因此对他们的建议就是应信任并能够尊重评审人员，虚心接受意见。

③ 项目下游人员：设计、编码、界面、测试、实施并维护，他们也兼有评审的职责，应积极提出意见。不能事不关己，高高挂起。

④ 评审人员：应当尊重作者的辛勤劳动，言词谨慎，要有根据。

不论是文档作者还是评审人员、下游人员都应当防止以技术为导向，避免为了学习新技术而不管软件系统需求是否需要这些技术，也不考虑这些新技术有多大风险。

3．注意各种心理问题

在心理上最常见的是面子问题，被评审人员把他人对文档的意见认为是个人批判而紧张拘谨，这是人之常情。而造成的双方急于辩护，敌视或对抗在心理学上称为“知觉防御”，即对不利于自己的信息回避并否定。

另一问题就是评审人员做好好先生。也可能是能力不足，不提问题，只会附和。亚里士多德说：“我们很容易回避批评——不说什么、不做什么、不存在什么”。知错而不发言是道德问题。

各方应该针对工作成果中的问题，而不是针对作者，互相尊重，以减少双方挫折感。

戴明14点之一：“驱除恐惧，所有同事必须能大胆发言，提出问题或表达意见”。

Cosgrove说：“不愿意为设计书写文档的原因，不仅仅是由于惰性或者时间压力；相反，设计人员通常不愿意提交尝试性的设计决策，再为它们辩解”。通过设计文档化，设计人员将自己暴露在每个人的批评之下，他必须能够为其书写的一切进行辩护。如果团队架构因此受到任何形式的威胁，则没有任何东西会被文档化（引自《人月神话》）。

不知道这些大师有没有夸大这种现象。

程序员既不愿写文档，也不善言谈。在软件工程学术上基于不同的假设出现了不同的软件开发过程模型，主要分为轻量级和重量级。因为项目成员不愿意写文档，所以有轻量级过程强调项目团队成员之间、项目团队与用户之间的充分随时的沟通；因为项目成员不善言谈，所以有重量级过程，强调“把要做的事情写出来，按写的去做，把做的事情记录下来”。这有点像管理学中的X理论和Y理论，似乎是分别基于性恶说和性善说的假设。

注意“金鱼缸效应”，一些新建的办公系统软件为什么受到抵制？在各种“金”字头的的工程建设中，政府部门为了有效了解各类业务的办理情况，提高业务透明度，开发了相应的办公系统软件，然而使用初期这些办公系统却在基层使用单位受到了冷遇。因为透明度提高了，一些工作疏忽或作弊很容易被发现，统计数字也真实了，难以“随心所欲”。这就是金鱼缸效应：“人人都喜欢把鱼放在金鱼缸，但人人都不愿意做里面的金鱼”。

Jesse Liberty在《Clouds to Codes》中说：“程序员认为他们是周围人群中最聪明的”，这里的程序员实际上泛指软件开发人员。因此不论是评审人员，还是被评审人员，都应该秉持谦虚、谨慎、尊重、感恩，以及协商的学习态度，避免过于自负、情绪化或有伤害的言辞。评审过程中要心态客观，眼光专业，对事不对人，重在讲道理。各方都应当把评审工作作为帮助，而不是批评。评审会议主持人要及时地限制各方的不良态度，但不限制评审人员有根据地指出问题，也不限制对方对问题进行解释。

在软件开发项目中既要考虑管理、风格、设计等各方面的一致性，又要考虑独特性；既要考虑使各项工作具有规范性，又要保护项目团队成员的创造性；既要讲究原则性，又要讲究灵活性；既要讲究管理上的可控性，又要保护员工的积极性。而质量管理、项目管理工作应该做到以上4个方面的平衡。

4．注意信任的副作用

同事之间相互信任是人类的本性，也是人类交互中的不可缺少的部分。诺曼先生在《情感化设计》中提醒：盲目的信任造成错误。

人数多时产生的盲目信任，当更多人参加一个任务的检查时，安全性会降低，这称为“旁观者淡漠”。因为检查的人越多，每个人对其他人就有依赖心理，责任心就会降低，每个人完成的任务就越不仔细。当有更多的人负责时，信任起到了妨碍的作用。

在评审工作中由于盲目信任造成的对评审效果的影响情况是较普遍的，最常见的是组内评审中出现的盲目信任，还有就是对资深技术人员的盲目信任和对上级的盲目信任。

当一个人质疑另一个人的工作成果时，会被认为含有缺乏信任的意思。但我们应该学会习惯于把质疑作为一种尊重的标志，而不是缺乏信任的象征，评审就是要有怀疑一切的态度。

5．评审工作完整性

评审工作的完整性很重要，遗漏重要的部分可能造成不可估量的损失，这方面的建议主要有以下几条。

① 规划好应该评审的不同的部分、角度和层次。

② 不同的人员评审覆盖不同的部分或角度。

③ 大规模的软件可分物理或逻辑部分进行评审。

④ 要考虑软件系统的泛一致性，要兼顾前后左右系统和标准。

⑤ 要考虑各阶段工作成果的可追溯性，上下游的作者可互相评审，如设计人员评审需求，分析人员评审设计。

⑥ 需求和设计变更是难免的，要给出需要进行“变更评审”的准则，注意必要的评审。

麦肯锡系统思维的结构化思路核心概念Mutually Exclusive Collectively Exhaustive（MECE）对我们评审工作的完整性具有深刻的指导意义。评审工作就应该在整体思维下做到没有遗漏，没有重复。但是为了更好地利用有限的资源条件，要有优先级并突出重点。

6．关于组内评审的建议

不拘形式，随时评审（检查和走查）。同一个项目团队的成员如果作为安排比较方便，可以随时对需求或设计进行讨论。

安排团队内部不同人员可从不同层次和角度评审不同的部分，无法覆盖的部分或比较薄弱的部分一定要请求公司安排资深技术人员进行评审。

组内评审的缺点之一是评审的水平问题，受项目组内水平限制，有些潜在的问题可能发现不了。

组内评审的缺点之二是团队成员可能存在不愿提问题的心理，特别是在分析或设计人员是项目经理或资深技术人员的情况下。

不同的项目可以采用不同的评审策略，但组内评审都是必需的，只是形式可以灵活随意。如定制开发需求的评审策略可以是：用户评审→组内评审→组外非正式评审→正式评审；定制开发设计的评审策略可以是：组内评审→组外非正式评审→正式评审；产品研发的评审策略可以是：产品组内评审→项目组内评审→组外非正式评审→正式评审。

当然，（正式的）组内评审也可不单独进行，而是与“组外评审”同时进行。

7．关于网络评审的建议

网络评审可包括电子邮件或其他通信工具或网上管理工具，电子邮件或网上管理工具是一个很好的“异步”评审工具，而QQ、MSN或其他聊天工具可以达到“同步”的效果，弥补异步的不足。

应该注意及时收发邮件，养成及时收邮件的习惯。在条件允许的情况下，应该每天收取邮件，同时应该注意及时反馈意见。

对于疑问及时沟通，身在异处的多个人要共同讨论问题还是不很方便。因此可以通过回复邮件、网上聊天和电话方式及时沟通，澄清疑问。

发送邮件后最好再通过电话等其他通信方式提醒和确认收件人接收邮件，对于使用网上管理工具的也可通过类似方式提醒和确认。

网络评审的好处一是基本不受地区限制，很多公司的业务扩展到全国或全球，网络评审的使用率将越来越高；二是可以让评审人员提前阅读，做好正式评审准备；三是附带保存了评审记录；四是不像会议评审那样同时要花费众人的时间，特别是在会议跑题时。

Patricia Wallace在《Internet心理学》提到网络沟通在心理学意义上的优缺点。

优点之一是互相看不到对方，没有面子问题，评审人员可以直接说出问题，避免个人之间的冲突；优点之二是写电子邮件或在网上管理工具填写意见一般比口头发言会经过更多（更成熟）的思考。

缺点之一是写电子邮件或在网上管理工具填写意见比口头发言麻烦，要多花很多时间；缺点之二是缺乏会议评审中的那种气氛，激励与会人员共同协作来解决问题；缺点之三是如果没有及时的提醒或确认，评审人员在事情比较多时对这项工作的优先级认识不同，可能会没有投入时间来进行评审。

因此网络评审应当和随时评审和会议评审相结合，在前期准备阶段通过网络使大家对评审对象有一个深刻的理解，结合随时评审解决一些容易解决的问题，最终通过较为正式的会议评审全面地把文档过一遍。

8．关于会议评审的建议

会议之前要做好各项准备工作，没有准备的会议一般是不会成功的。为了做好会议评审的准备，应该提前3~5天把文档发给评审人员，保证评审人员有足够时间阅读，不强迫评审进度。在会前通过非会议形式如邮件评审、随意评审来消除大部分问题。

为节省时间，会议时间应尽可能短，参与人员尽可能少。

正式评审意味着要有批准意见的记录，而正式评审不一定必须通过开会这种形式，即正式评审≠会议评审。对于一些项目来说，如果其他形式的评审能够起到比较好的效果的话，会议评审不是必需的。

会议评审主持人应当做好协调工作，面对面的沟通尤其应当注意心理因素。文档作者应当虚心接受意见、避免争论、不找借口并且不固执己见；评审人员提出的问题应当有根有据，对事不对人、言辞谨慎，有疑问要及时澄清。

为了提高会议效率，要有一个安静的环境。主持人应当随时使大家注意力集中，避免发生跑题。

关于形式与内容的问题，我们以结婚仪式为例。形式的重要性在于向各方宣示这一事件具有重要意义，引起大家重视，包括引起新郎新娘的重视。但仪式一过，新娘就脱下婚纱，不用一辈子穿婚纱。后面的日子不必天天都如此庄重，才有轻松的气氛，这说明了内容比形式更重要。

另外，结婚仪式的例子也说明了评审准备或其他形式的与会议评审之间的关系。在结婚仪式上如果主持人问新娘“您愿意嫁给新郎吗？”新娘不出意外会说“愿意！”，而不会说“我还要再考虑一下”或“不，还有些问题没有解决”。

厦门每年召开贸易投资洽谈会，每次都引进数千个投资项目，数百亿美元的外资。但这些成果都不是在这几天的会议中就能达成的，而是经过了很多会前会和会后会。这个盛大的聚会只是一种形式，原来谈好的项目在这里进行签约。在这里，新认识的朋友需要进一步的沟通，新找到商机需要在会后进一步的落实。曾仕强先生说：“会而不议，议而不决”。会而不议是说大部分的事项会前已经议好，问题已经基本解决，不需要等到正式开会时再来讨论。会上只要宣布结果，可以大大缩短会议的时间；议而不决是说如果会议上大家对一些事情还有争议，则最好是不要急于形成什么结论。这样一是避免仓促做出决定；二是可以保护双方的面子，容易做好协调工作。

要注意的是做好会议记录，即评审记录和评审报告。为了保证记录的正确性和完整性，应该指定能够理解的人做记录，在记录时最好能说明每条意见的提出人。评审记录和报告要说明问题解决负责人、跟踪人和问题解决时间，并且应当及时发给相关人员签字确认评审记录和报告作为跟踪依据。

最后还要根据评审记录跟踪落实问题的改正，评审会议的成功≠评审成功。只有有效地发现“所有”缺陷，并修改了所有问题才是“评审成功”。


评审相关知识

收藏了，多谢楼主分享

嗯 学习了
谢谢楼主

所述内容，比较通俗，容易理解~~感谢楼主~

感谢楼主~