如何看待项目开发过程中基于度量结果的绩效考评

收到一位网友的E-mail，询问如下的问题：<br>”不少资料里面都提到"开发的度量结果不应成为奖惩的根本依据". 但我们实际的项目组在操作时,免不了会根据度量结果来评价一个开发人员的绩效,例如SRS文档的缺陷率有无达到质量目标?等等. 也有的人支持根据有效的度量数据来考核开发人员的工作绩效. 不知道你是怎么看这个问题的?“<br><br>遂总结了一下自己的理解：<br>"开发的度量结果不应作为奖惩的根本依据"的根本原因在于<font size="4" style="color: rgb(255, 0, 0);"><span style="font-weight: bold; font-style: italic; text-decoration: underline;">"质量天生具有的不确定性"</span></font>。因此，没有人可以肯定开发过程中达到了质量目标（如SRS缺陷发现缺陷率）软件的质量就会好。 <br><div>
<br>如果仅以过程中的质量目标达成情况来衡量开发人员的绩效是片面的<wbr></wbr>，会抹杀一部分责任心很强员工的积极性，比如一位员工<wbr></wbr>，不管是SRS、HLD、CODE、UT等等在检视或测试的过程中<wbr></wbr>发现的缺陷都是最少的，谁能说他的质量不好或者绩效不好<wbr></wbr>，很有可能他是团队中质量最好的一位。<br><br><font size="4" style="font-weight: bold;"><span style="text-decoration: underline; font-style: italic; color: rgb(51, 51, 255);"> 过程中的度量，如SRS缺陷发现率的作用主要是用来牵引项目组在进<wbr></wbr>度和质量保证活动投入工作量（如检视／单元测试等）中进行均衡<wbr></wbr>，防止项目组盲目的追逐进度。</span></font>如果某个模块的质量目标没有达标，需要分析相应的检视或测试活动的<wbr></wbr>工作量投入情况，看看是否由于工作量投入不足引起的<wbr></wbr>，对于工作量投入不足造成的情况，必须打回。<br><br>衡量项目成员绩效还有很多其他的方法，其基本的原则应该是鼓励员工<wbr></wbr>对于质量的责任心，如：<br>1、收集每位成员参与检视活动发现的缺陷情况，进行相应的排名<wbr></wbr>，鼓励积极参与检视活动 <br>2、评比文档或代码检视缺陷发现率最少的模块或个人（质量最好的那个）<wbr></wbr>，评比不建议直接看数据，因为对于一个尚未成熟的团队大家在反馈检<wbr></wbr>视意见时有时存在比较随意的情况，可以采用直接让大家评比的方式<wbr></wbr>。这样做可以鼓励大家在提交检视时进行充分的自检<wbr></wbr>，而不是完成一个半成品就甩给别人去帮忙查找错误。<br><span style="color: rgb(0, 0, 255);">3、或者更为简洁或更有效的做法（我自己的做法）是要求项目经理亲</span><wbr style="color: rgb(0, 0, 255);"></wbr><span style="color: rgb(0, 0, 255);">自查看每篇文档，自己评判，如果一个项目经理没有看过大家的文档仅</span><wbr style="color: rgb(0, 0, 255);"></wbr><span style="color: rgb(0, 0, 255);">仅依靠质量目标的达成情况来衡量大家的成绩，是一种对团队对质量极</span><wbr style="color: rgb(0, 0, 255);"></wbr><span style="color: rgb(0, 0, 255);">不负责任的做法。不过要说服这样的项目经理刚开始有些困难</span><wbr style="color: rgb(0, 0, 255);"></wbr><span style="color: rgb(0, 0, 255);">，不妨一边不停的在他耳边说（最好是有其他的优秀的项目经理作例子</span><wbr style="color: rgb(0, 0, 255);"></wbr><span style="color: rgb(0, 0, 255);">），一边自己看项目组的文档，拿出实际情况给他看</span><wbr style="color: rgb(0, 0, 255);"></wbr><span style="color: rgb(0, 0, 255);">，这样做还有一个好处，就是QA比PM更清楚项目组文档或代码的质</span><wbr style="color: rgb(0, 0, 255);"></wbr><span style="color: rgb(0, 0, 255);">量状况，在和更高级的领导一起交流时QA会比PM更显得有理有据</span><wbr style="color: rgb(0, 0, 255);"></wbr><span style="color: rgb(0, 0, 255);">，久而久之这位对团队质量状况以及成员都不了解的项目经理自己都会</span><wbr style="color: rgb(0, 0, 255);"></wbr><span style="color: rgb(0, 0, 255);">惭愧的。 QA以旁观者的身份和项目经理一样，有挖掘优秀项目成员的义务。</span><br>4、将最终结果（遗留缺陷密度）也纳入进来，以结果为导向<wbr></wbr>，任何人都没有什么好说的。即使短期内过程质量目标没达标的项目成员会受些委屈<wbr></wbr>，但最终他会得到肯定。<br>以上的几点最好一起用。<br><br><span style="color: rgb(255, 0, 0);">质量好坏的最终责任在于项目组本身，不是QA。</span><br>QA的目标始终有些悲哀，我理解的终极目标是：让QA从项目组消亡<wbr></wbr>。消亡不是被项目组赶走，而是树立项目组自己的质量意识以及相应的<wbr></wbr>方法，在项目组达到不需要QA也可以自行良好的运作的时候<wbr></wbr>，QA就可以撤退了。所以，在一个好的项目组中作QA<wbr></wbr>，远不如在一个较差的项目组作QA，所学到的东西多<wbr></wbr>。当整个开发组织的所有项目都不需要QA也可以良好运作的时候<wbr></wbr>，我们QA就可以考虑转行了，呵呵，不过好像还比较遥远！ <br><br>作者：fasiondog<br>来源：<a href="http://blog.csdn.net/kongdong/">http://blog.csdn.net/kongdong/</a><br>
</div>