不要在缺陷上招致恼羞成怒

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

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

r(d@0b;T&Ml?0　　对于评审，有下列一些有效的办法：51Testing软件测试网o bc+}F5Iwf&j

　　确保对评审项目的关注，而评价不是针对生产或创造评审项目的人或单位。换句话说，评审应针对事物、方法，而不是针对人。51Testing软件测试网CX F m$Xo~a

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

　　设法表达你要求修改的原因是想达成什么目标：确定修改与市场策略有关，基于一般的架构原则，抑或是公司或部门的目标？51Testing软件测试网p!dE3G(` {,H,o

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

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

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

4Be m%D8j0　　模仿你在寻求的行为。拿出当评审你的工作，且结果是“很好，继续干吧”时的行为。目标是创造优秀的工作成果并持续改进它。换句话说，不是关于你的事，而是关于如何奋力争取优秀的事。51Testing软件测试网u};WJ F Zx

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

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