IT软件公司研发线绩效管理经验

<script type="text/javascript"> </script> <script src="http://pagead2.googlesyndication.com/pagead/show_ads.js" type="text/javascript"></script>

 由于工作需要，公司特别邀请到了业界专家邓超先生来公司交流研发线绩效管理相关问题，这里记录和邓超先生交流的一些记录和自己在平时工作中的理解。

 

1、  评价员工是否表现优秀和员工奖金的发放采用不同的标准。

    员工表现是否优秀工作量不作为直接评价指标，而只作参考指标，主要关注进度指标和质量指标；

    奖金的发放则重点考察工作量指标，同时参考其他指标。

    我觉得这里讲的员工的表现比较笼统，应该是员工能力、综合素质的体现，为日后晋级做依据。奖金的发放依据多劳多得视乎没有什么异议。

2、  员工是否表现优秀，采用相对该员工岗级的考核方式，所有考核指标都要考虑岗级因素。

      

 

3、  当所有人都能达到指标要求，也就是指标体现不出差异时，该指标可不作为直接评价指标，而作为参考指标。

 

4、  不同岗位的人员不放在一起进行正态分布；少于10个人也不进行正态分布；

        这个深有体会，我们部门是全公司最特殊的部门、我们部门有开发、测试、业务、需求、策划人员，之前的绩效考核中要把这些人放在一起来按照统一的标准考核和正态分布是非常困难，比较不同的人职能不同，参考的标准也不同

 

5、  不同项目之间的平衡，包括工作量的审核、由专家委员会进行审查，专家委员会成员由部门经理、产品经理、规划经理构成。

 

6、  评价等级的划分，先依据团队的平均水平划定及格线.

 

7、  开发人员考核安排的1天工作量要求达到200行代码量（包含增加、删除、修改的代码）

        我觉得是平均开发时间，这里的200行代码应该不是有效代码。

 

8、  排工作计划时不告诉员工专家委员会评估的工作量，由员工自行认领工作并排出计划完成时间，如果员工评估的时间大于专家委员会评估的时间则要求缩短时间或换人，如果员工评估的时间小于专家委员会评估的时间则实际工作完成时间以员工评估的为准，但以专家委员会评估的工作量作为最终考核的工作量，此工作量自始至终都不向员工公布。

       这个很好我觉得，这个有点类似敏捷开发方法Scrum的Sprint planning meet（一般为一天时间（7小时）。该会议需要制定的任务是：产品Owner（业务人员）和团队成员将自己的功能模块（backlog）分解成小的功能模块,  
决定在即将进行的sprint里需要完成多少小功能模块，确定好这个Product Backlog的任务优先级。另外，该会议还需详细地讨论如何能够按照需求完成这些小功能模块。制定的这些模块的工作量以小时计算。）因为有时候，项目经理/开发经理或者专家组都好，没有比员工自己更了解自己开发能力了的，但是如果员工想忽悠领导，故意多报一些时间，不好意思有估算库做依据，最终确定的时间也会八九不离十。即使估算偏差较大，还可以修正估算库的时间。

 

9、  参加评审的人员给工作量，但要求1个小时发现至少5个缺陷。

 

10、 对需求人员的考核主要考察需求文档的缺陷率和对提单的答复工作的满意度。其中对提单答复的满意度由提单人打分。

 

11、 作为管理人员在过程中要多采用抽查方式进行监督，例如对不同组之间工作量估计的合理性和平衡性（检查 代码行）、功能测试结束时抽查部分功能点运行情况等，通过抽查以督促提高薄弱环节的工作质量和合理性。