【分享】评审工作建议!

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

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天把文档发给评审人员，保证评审人员有足够时间阅读，不强迫评审进度。在会前通过非会议形式如邮件评审、随意评审来消除大部分问题。

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

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

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

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

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

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

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

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

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

对审核员来讲，必须做到几点：
公平，公正……