不要在缺陷上招致恼羞成怒
作者:网络转载 发布时间:[ 2012/8/15 14:41:08 ] 推荐标签:
当你在开评审会(例如产品概念评估、需求评审、设计评审、代码评审、测试评审、产品发布评审)时,通常会检查出评审项目的一些缺陷。评审项目的作者对于这些暴露出的缺陷当然会感到不自在。
出于通常的礼貌,一旦在特定领域发现了三四个问题,不要再过高、过深地批评了。如果你需要指出再多的条目,可以将其写下来,让被困扰的人随后能仔细看到这些要点。否则这些事情会招致对方恼羞成怒。由于被评审人成了众矢之的,在效率上会极大地影响评审的后续进展。
对于评审,有下列一些有效的办法:
确保对评审项目的关注,而评价不是针对生产或创造评审项目的人或单位。换句话说,评审应针对事物、方法,而不是针对人。
避免用“你”、“你的”这类个人化的评价。
设法表达你要求修改的原因是想达成什么目标:确定修改与市场策略有关,基于一般的架构原则,抑或是公司或部门的目标?
评审应关注改善评审项目的方法,不仅仅因为没有遵循某个编码指导原则,而是修改后为什么有用。评审项目的人不仅需要知道怎样把事情做得更好,还要知道为什么这种改进是有用的。
找机会说出已做出的工作的积极成分。大多数人被指出暴露的缺陷后,都会非常想要辩解,而找到工作的好的方面能够软化这种态势。所有与会者都应明白,目标是创造的工作成果,每个人都要求用同样的标准—这是集体的努力。
确保会上的每个人都参与进来。以局外人的身份参加会议是在浪费公司的时间。
模仿你在寻求的行为。拿出当评审你的工作,且结果是“很好,继续干吧”时的行为。目标是创造的工作成果并持续改进它。换句话说,不是关于你的事,而是关于如何奋力争取的事。
举止文雅:倘若角色互换,作为被评审人,你希望别人怎样给你反馈意见?
任何问题都应记录在案—不只是你感兴趣要追踪的事,还包括其他人提出的记录。如果确有一大串条目需要引起注意,可能随后还要再进行一次评审。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11