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

上一篇 / 下一篇  2012-08-16 08:55:29 / 个人分类:测试经验

51Testing软件测试网+B&sv5]q6s

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

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

51Testing软件测试网t1YK"tx9xrGf

  对于评审,有下列一些有效的办法:51Testing软件测试网*A,O)U+wUs

51Testing软件测试网 X Zsn7rd/Vr N9e2B

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

5R7OiB"y7S@!L V%vL.{.m0

3I4m@0CKq6Fn3E0  避免用“你”、“你的”这类个人化的评价。

E6db+q6S_fj$le ~051Testing软件测试网2_K'dI4R

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

X}&iSWq"B/L6T0

7[ _3uP2N-l'^0  评审应关注改善评审项目的方法,不仅仅因为没有遵循某个编码指导原则,而是修改后为什么有用。评审项目的人不仅需要知道怎样把事情做得更好,还要知道为什么这种改进是有用的。51Testing软件测试网#qd$ki;uJ(C

YK.V.E P%a5j0  找机会说出已做出的工作的积极成分。大多数人被指出暴露的缺陷后,都会非常想要辩解,而找到工作的好的方面能够软化这种态势。所有与会者都应明白,目标是创造优秀的工作成果,每个人都要求用同样的标准—这是集体的努力。51Testing软件测试网0F$n1ND y&A8s:tb'D

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

kQ&PeXd6A/MU0

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

0L4P Bn'\$Ep051Testing软件测试网2uZuYF+Ep

  举止文雅:倘若角色互换,作为被评审人,你希望别人怎样给你反馈意见?51Testing软件测试网0Z&}*o-wx\p

51Testing软件测试网cCo1XK)En

  任何问题都应记录在案—不只是你感兴趣要追踪的事,还包括其他人提出的记录。如果确有一大串条目需要引起注意,可能随后还要再进行一次评审。51Testing软件测试网;wqzc v {-J ?7A


TAG:

 

评分:0

我来说两句

Open Toolbar