|
一、平衡计分卡项目管理者联盟文章
现在很多人在讨论敏捷开发的绩效管理，实际上我觉得在创造敏捷开发的绩效管理方案之前，应该先看一看其他体系，有什么可取之处。毕竟软件界的绩效管理，不但现在没有成型的方法，就连能够简单的试试一下的方案，都很少见。项目管理培训
平衡计分卡，把绩效分为4个象限，客户，收入，学习与成长，内部流程。可以认为客户和收入，是对外的绩效，另外两个则是对内的绩效。还可以认为，收入和内部流程，是短期绩效，而客户和学习与成长是长期绩效。内外长短，形成了4个象限。
反观，我们平时说的软件绩效，比如用代码行来表征生产率，用千行代码缺陷率来表征质量，用工时来决定收入和奖金，其实都是一种内部的，短期的绩效评估方法。项目管理者联盟
即使我们使用了项目收入，功能点这些对外的数据，也只能表明，我们在对外绩效管理有了突破，但还不能说对长期绩效进行了管理。因此可见，我们软件开发的绩效管理，还有很长的路要走，还有很多视野需要去开阔。项目经理圈子
在后续的文章中，我会尽量分析一下，软件界可以使用的，内部，外部，长期，短期的绩效管理度量指标，供大家参考。当然更重要的是，如何对这些指标加以改善，这才是我们真正话题的核心。项目管理者联盟
二、不要过早进行绩效考核项目管理者联盟文章
很多企业喜欢刚刚建立绩效管理制度，马上就使用它进行考核，这种情况是不好的。因为，人们在刚刚接受一种新的度量体系的时候，往往对其中某些事物的定义还不够规范，不同的人认识还不一定是一致的。talent.mypm.net
在这种情况下贸然进行考核，使得人们会倾向于向对自己有利的方向理解和解释这些定义，而不是向客观事实的方向。这就在一段时间里引发大量的争议，而且永远找不到正确答案。项目管理论坛
建议的操作模式是这样的：先建立度量体系，并告诉大家，半年之后将使用新的度量体系进行绩效考核。那么在半年之内，大家就会认真的去理解，这些度量体系的定义，并且充分地透明地度量出自己和其他团队的结果来。在这段时间里，组织应该帮助那些绩效不好的团队进行相应的改进，以便在正式度量的时候，获得好的绩效。项目管理论坛
真正生效的时候，后进的团队已经获得了一些改进，也充分认识到，只要持续改进绩效还会不断上升，因此反对的力量就会小很多。项目管理者联盟
三、防范反向绩效项目管理者联盟
很多绩效考核的方法看似非常合理，非常直接，但是却有可能产生反向绩效。项目管理论坛
比如说，有的时候我们希望提高生产率，因此会度量每一个迭代按时完成率。看似大家一定会为了按时完成，而不自觉地提高生产率，但其实不然。要保证按时完成每个迭代的最简单最直接的方法，并不是提高生产率，而是预留缓冲时间。但是这种做法，非但没有提高生产率，反而降低了生产率。项目管理者联盟
其很久以前敏捷开发曾经有一个分支叫做DSDM，动态软件开发方法。在这种方法里有一种概念，叫做MoSCoW，分别是英文，Must，Should，Could，Would not的缩写。项目管理者联盟
它提供一种新型的度量方法：第一，每个迭代必须保证60%的任务按时完成(Must)，这样就保证了迭代的可交付性;第二，所有迭代的平均值，应该是80%(Should)，而不是60%，这个平均值可以认为是平均的生产率。为了要达到80%的平均值，由于在某些迭代只能完成60%，团队必须在另外一些迭代中，超过甚至远远超过80%(Could)。blog.mypm.net
这样，我们在保证每个迭代能够按时交付的前提下，同时也保证了总生产率没有受到负面的影响。项目管理者联盟 blog.mypm.net
|
