上个月帮一家公司进行管理诊断，一谈到同行评审，PM眼睛都放光：

“要召开评审会议，要提前发材料给干系人独立评审，流程繁琐。”

“执行同行评审的人，认为这些都是‘额外的工作’，根本不花时间提前看材料，独立评审形同虚设，就导致评审会议时，需要花费大量时间解释和说明。有时候一个问题大家意见不一，说着说着时间就没谱了，还没法有结论。”

“最要命的是，公司有个技术砖家老William，拿着鸡毛当令箭，常常拖着不签字。进度延误PM背锅不说，为了让他签字还得软磨硬泡的。”

“另外，需求、设计、编码和测试每个阶段都有产出要评审。像需求和设计，评审流程复杂点是应该的；但像代码什么的，也搞得跟需求和设计的评审一样，就太浪费工作量了。”

……

同行评审作为保障软件质量的两大环节之一（另一大环节，请参阅《Bug or Bomb? 缺陷还是炸弹？》），其在软件项目管理中的普遍性已无需多言。可做着做着，都走了样。今天我们延续之前的讨论，想要做好同行评审，便要从它的过程下手——程序步骤、方法和人。

过程三要素 之 程序步骤

我们先看一下，一个比较完整的同行评审的程序步骤。

上面提到的那家公司，也大致上是按照这个程序来的。PM觉得流程繁琐，主要是针对第三步 - 独立评审，以及第五步 - 同行评审会议。

独立评审，要求干系人在同行评审会议前，按照评审准则独立进行审查、识别出问题，从而提高同行评审会议的效率。

案例中的公司这一块做得很水。其主要诱因有两种：

第一种可能：同行评审的过程，在管理制度上没有得到保证，使得相关工作没能定义到干系人的职责中去。那么，每次有同行评审的时候，干系人自然会认为这不属于自己的“本职工作”而是“额外工作”。没有责任的约束，没有绩效的压力，如何能上心？

第二种可能：同行评审流于形式，没有实质作用。那么，这种情况下，即使干系人明确知道这是自己的本职工作，也不会加以重视。因为在他们眼中，同行评审是“既不重要，也不紧急”的工作。

同行评审会议，要求在主持人的主导下召开；工作产品的“作者”就独立评审提出的问题予以回应——要么沟通清楚，让问题不再是问题，要么接受问题，加以修改；为了跟踪问题的处理结果，改善同行评审的过程，还需要记录问题和相关数据，经由全体参与人员的确认，成为后续工作的参照和依据。

案例公司有个砖家拖着不签字，不管主观上他是出于什么原因；客观上，我们应该反思同行评审在程序步骤的设计时，是否有足够的宽容度，来应对极端情况；以及在评审方法的选择与应用上，是否可以有效推进与控制。

通过上面的分析我们可以看出，管理想要落地，第一要在制度层面加以保障，让管理措施与既有的工作过程、人员职责相融合。第二要在程序步骤的设计上有足够的宽容度，来应对不同的实际情况。说到这儿，就不得不提裁剪了。裁剪除了要依据程序步骤中设计的裁剪指南，还要依据不同的评审方法。

过程三要素 之 方法

很显然，不可能一套方法走天下。到底应该如何为工作产出选择适合的评审方法呢？一般来说，开发过程各个阶段的关键工作产品，均需要同行评审。

同行评审是项目开发过程对中工作产品评审的统称，它包含的类型更是多种多样，比如技术评审、结对编程、审查、审计等。这里呢，结合IEEE的评审标准，主要讨论以下三种类型。

根据项目的生命周期模型，在项目的计划中，为不同的工作产品明确相应的同行评审方法，据此对标准同行评审程序步骤进行裁剪。举例来说：

过程三要素 之 人

无论流程多完美，亦或方法多超前，如果人不理解、不执行，那问题就大了。在同行评审中，主要有4种角色：

让“扮演”这些角色的人员胜任各自的工作，才能让同行评审发挥应用的作用。那么问题来了，这些角色要求怎么样的胜任力呢？从胜任力的角度出发，应该包含知识、技能与过程能力三大方面。

以主持人为例，其在同行评审中的主要工作程序步骤包括：

1. 为同行评审做好准备工作

a)  确保被评审工作产品符合同行评审启动要求

b)  协助选择和安排评审员

c)  确保评审员理解其评审职责、评审程序步骤以及评审方法

d)  安排评审会议

2. 主持评审会议

a)  确保人员到位并做好准备

b)  确保评审会议按照计划与流程执行

c)  记录发现的所有问题，并指定责任人

d)  采集过程数据，便于改进同行评审过程

3. 问题跟踪与汇报

a)  跟踪或确保他人跟踪评审问题，直到关闭

b)  将数据和结果，传达给相关的各方

这其中最为核心，也最困难的是第二项工作，所需的胜任力如下：

按照这个思路，梳理出同行评审各角色的完整胜任力，便能贯穿程序步骤、方法与人三大过程要素。使同行评审的过程得以高效执行，自然会得到同行评审的好结果，发挥其应有的作用与价值。