当你在开评审会(例如产品概念评估、需求评审、设计评审、代码评审、测试评审、产品发布评审)时,通常会检查出评审项目的一些缺陷。评审项目的作者对于这些暴露出的缺陷当然会感到不自在。

  出于通常的礼貌,一旦在特定领域发现了三四个问题,不要再过高、过深地批评了。如果你需要指出再多的条目,可以将其写下来,让被困扰的人随后能仔细看到这些要点。否则这些事情会招致对方恼羞成怒。由于被评审人成了众矢之的,在效率上会极大地影响评审的后续进展。

  对于评审,有下列一些有效的办法:

  确保对评审项目的关注,而评价不是针对生产或创造评审项目的人或单位。换句话说,评审应针对事物、方法,而不是针对人。

  避免用“你”、“你的”这类个人化的评价。

  设法表达你要求修改的原因是想达成什么目标:确定修改与市场策略有关,基于一般的架构原则,抑或是公司或部门的目标?

  评审应关注改善评审项目的方法,不仅仅因为没有遵循某个编码指导原则,而是修改后为什么有用。评审项目的人不仅需要知道怎样把事情做得更好,还要知道为什么这种改进是有用的。

  找机会说出已做出的工作的积极成分。大多数人被指出暴露的缺陷后,都会非常想要辩解,而找到工作的好的方面能够软化这种态势。所有与会者都应明白,目标是创造的工作成果,每个人都要求用同样的标准—这是集体的努力。

  确保会上的每个人都参与进来。以局外人的身份参加会议是在浪费公司的时间。

  模仿你在寻求的行为。拿出当评审你的工作,且结果是“很好,继续干吧”时的行为。目标是创造的工作成果并持续改进它。换句话说,不是关于你的事,而是关于如何奋力争取的事。

  举止文雅:倘若角色互换,作为被评审人,你希望别人怎样给你反馈意见?

  任何问题都应记录在案—不只是你感兴趣要追踪的事,还包括其他人提出的记录。如果确有一大串条目需要引起注意,可能随后还要再进行一次评审。