银行客服绩效管理的最佳方法 (zt)
粗略看了一下，对软件公司的绩效考核同样有很大参考意义。
Tuesday, March 16. 2010
Monday, February 2. 2009
如何量化考核软件开发人员绩效
软件人员管理，一向被认为是一件难题。尤其是年中年底的评价问题，涉及到加工资，发奖金，稍有差池，就会民怨沸腾，来年是该走的不走，不该走的全走了。
在开始一个软件项目之前，公司领导要与该项目主管对需要完成的工作内容、时间期限、考核的标准达成一致。项目主管把任务进行分解，和每个软件开发人员对各自所需完成的工作内容、期限和考核标准达成一致，特别是各个模块之间的接口，并形成一份完整的“任务说明书”。在期限结束时，主管根据每个开发人员的工作状况及原先制定的考核标准来进行考核。为了避免到最后才发现问题过多、难以收拾，可以在开发期间设置几个考核点，设置相应的阶段性目标，根据完成目标情况给出考评的分数。
开发人员应具有较强的事业心、责任感和较深厚的基础理论知识，并不断提出新的思想和观念，为创造新产品和新技术提供条件。通常研发一个软件项目所需的时间较长，我认为按项目的里程碑或项目来安排对软件人员的考核，若项目周期超长也可在年中和年末进行考核，以目标管理(Management By Objectives， 简称为MBO）为原则设定KPI (Key Performance Index)，考评分用技术指标决定，如工作量用完成的功能点来衡量，工作质量用每千行代码Bug数衡量，技术人员会认为这很公平，从而有动力更努力。
根据客户关注点确定考核指标， 同时将客户的满意度与做为考核的衡量标准， 一个项目完成后，公司不要把该项目的奖金一下子全发给软件人员，可以留下30%～40%待一年后发放，给客户一年的时间发现问题，软件公司可根据问题的大小从余下奖金中相应扣除。
用下面的七项指标对开发人员进行绩效考核评定：
1. 工作态度
2. 软件质量 (bug的等级和个数，回归次数，重要模块系数)
3. 工作难易度 (功能性，可靠性，易使用性，高效性，可维护性和可移植性，功能点数，复杂度)
4. 工作效率/能力 (完成百分比，工作经验)
5. 主动性
6. 沟通能力
7. 程序规范程度
1) 非常及时，随时都可以查阅任意相关文档；
2) 非常规范，较及时，随时可以查阅近期文档，文档编写滞后3天以内；
3) 较规范，较及时，一般可以查阅近期文档，文档编写滞后3～6天；
4) 较规范，但不及时，常常难以查阅，文档编写滞后6天以上；
5) 不规范，不及时，常常难以查阅，甚至没有编写相关文档。
代码应该有统一的代码库管理，而不是只保存在程序员个人手里；Bug也要存在缺陷管理库中，不是只是去跟程序员讲一下。每个项目结束时，每项统计指标的计算也是烦琐的工作，需要人力和耐心。
微软公司对软件人员的绩效考核每半年进行一次，先由员工自己为这半年来的业绩做一个评估，打一个分数，然后放到网上，等待部门经理签字、打分。没有经过部门经理打分、签字的信息呈红色; 经理打完分后，如果员工认为经理的评价比较符合事实，再进行最后的确认，确认后信息变为绿色，业绩考核的过程就完了。此外，部门经理打分的同时还要为每位员工制定下个半年的目标。如果员工对经理的评价存有异议，便可以拒绝确认，更高层经理及人力资源部的人员看到后，会与员工沟通，直至查到员工拒签的原因。
也有些知名的IT公司已将软件开发人员的绩效评估建立形成了一个体系，每年有年度的绩效考核，开发部门有开发成本考核。从每年12月开始到第二年1月份的两个月期间，公司上上下下都认真地做绩效考核，因为晋升调薪需要这个依据。考核完后，经理要跟员工面谈，将考核结果告诉他。考核的关键是评估后的沟通，这比评估更重要。让员工知道他的不足在哪里，优势在哪里，员工自己要提出想法。考核后排在后5％的员工要内部下岗，实际上是降工资，留岗观察。
在开始一个软件项目之前，公司领导要与该项目主管对需要完成的工作内容、时间期限、考核的标准达成一致。项目主管把任务进行分解，和每个软件开发人员对各自所需完成的工作内容、期限和考核标准达成一致，特别是各个模块之间的接口，并形成一份完整的“任务说明书”。在期限结束时，主管根据每个开发人员的工作状况及原先制定的考核标准来进行考核。为了避免到最后才发现问题过多、难以收拾，可以在开发期间设置几个考核点，设置相应的阶段性目标，根据完成目标情况给出考评的分数。
开发人员应具有较强的事业心、责任感和较深厚的基础理论知识，并不断提出新的思想和观念，为创造新产品和新技术提供条件。通常研发一个软件项目所需的时间较长，我认为按项目的里程碑或项目来安排对软件人员的考核，若项目周期超长也可在年中和年末进行考核，以目标管理(Management By Objectives， 简称为MBO）为原则设定KPI (Key Performance Index)，考评分用技术指标决定，如工作量用完成的功能点来衡量，工作质量用每千行代码Bug数衡量，技术人员会认为这很公平，从而有动力更努力。
根据客户关注点确定考核指标， 同时将客户的满意度与做为考核的衡量标准， 一个项目完成后，公司不要把该项目的奖金一下子全发给软件人员，可以留下30%～40%待一年后发放，给客户一年的时间发现问题，软件公司可根据问题的大小从余下奖金中相应扣除。
用下面的七项指标对开发人员进行绩效考核评定：
1. 工作态度
2. 软件质量 (bug的等级和个数，回归次数，重要模块系数)
3. 工作难易度 (功能性，可靠性，易使用性，高效性，可维护性和可移植性，功能点数，复杂度)
4. 工作效率/能力 (完成百分比，工作经验)
5. 主动性
6. 沟通能力
7. 程序规范程度
1) 非常及时，随时都可以查阅任意相关文档；
2) 非常规范，较及时，随时可以查阅近期文档，文档编写滞后3天以内；
3) 较规范，较及时，一般可以查阅近期文档，文档编写滞后3～6天；
4) 较规范，但不及时，常常难以查阅，文档编写滞后6天以上；
5) 不规范，不及时，常常难以查阅，甚至没有编写相关文档。
代码应该有统一的代码库管理，而不是只保存在程序员个人手里；Bug也要存在缺陷管理库中，不是只是去跟程序员讲一下。每个项目结束时，每项统计指标的计算也是烦琐的工作，需要人力和耐心。
微软公司对软件人员的绩效考核每半年进行一次，先由员工自己为这半年来的业绩做一个评估，打一个分数，然后放到网上，等待部门经理签字、打分。没有经过部门经理打分、签字的信息呈红色; 经理打完分后，如果员工认为经理的评价比较符合事实，再进行最后的确认，确认后信息变为绿色，业绩考核的过程就完了。此外，部门经理打分的同时还要为每位员工制定下个半年的目标。如果员工对经理的评价存有异议，便可以拒绝确认，更高层经理及人力资源部的人员看到后，会与员工沟通，直至查到员工拒签的原因。
也有些知名的IT公司已将软件开发人员的绩效评估建立形成了一个体系，每年有年度的绩效考核，开发部门有开发成本考核。从每年12月开始到第二年1月份的两个月期间，公司上上下下都认真地做绩效考核，因为晋升调薪需要这个依据。考核完后，经理要跟员工面谈，将考核结果告诉他。考核的关键是评估后的沟通，这比评估更重要。让员工知道他的不足在哪里，优势在哪里，员工自己要提出想法。考核后排在后5％的员工要内部下岗，实际上是降工资，留岗观察。
软件人员绩效考核新思路－从以组织为中心到以项目为中心
软件人员管理，一向被认为是一件难题。尤其是年中年底的评价问题，涉及到加工资，发奖金，稍有差池，就会民怨沸腾，来年是该走的不走，不该走的全走了。
一个软件工程师好不好？怎么判断？
记件制？看看代码写得多不多？稍有头脑的人机会立刻反对。精妙的代码不需要长。如果要比长，本来调用一个公共库中的函数就好了，现在我就拷贝过来；本来有一个状态变量可以重用，我再加一个；……程序员的法子多了。高手们全不干了，有的Bug，查要一个星期，而且每天晚上都得查到凌晨两点，改起来就一行，这老兄一定跳起来了。所以记件制不行。
记时制？每天八小时上班，太容易了。比加班，谁比得过毛头小伙子啊！而且，你知道我加班干什么？白天我可以天天上网，晚上干点活。或者我加班就打游戏，老板反正不在。时间长了，就变成了大锅饭。这也不行。
做技术的通常想到这儿就没什么法子了。人力资源专家通常这个时候跳出来了：KPI嘛！
KPI全称是Key Performance Index，就是大家每年每季度或每个月要填的表格：
一个软件工程师好不好？怎么判断？
记件制？看看代码写得多不多？稍有头脑的人机会立刻反对。精妙的代码不需要长。如果要比长，本来调用一个公共库中的函数就好了，现在我就拷贝过来；本来有一个状态变量可以重用，我再加一个；……程序员的法子多了。高手们全不干了，有的Bug，查要一个星期，而且每天晚上都得查到凌晨两点，改起来就一行，这老兄一定跳起来了。所以记件制不行。
记时制？每天八小时上班，太容易了。比加班，谁比得过毛头小伙子啊！而且，你知道我加班干什么？白天我可以天天上网，晚上干点活。或者我加班就打游戏，老板反正不在。时间长了，就变成了大锅饭。这也不行。
做技术的通常想到这儿就没什么法子了。人力资源专家通常这个时候跳出来了：KPI嘛！
KPI全称是Key Performance Index，就是大家每年每季度或每个月要填的表格：
|
考核项
|
权重
|
得分
|
|
工作量
|
30%
|
|
|
工作质量
|
30%
|
|
|
工作态度
|
10%
|
|
|
沟通能力
|
10%
|
|
|
……
|
……
|
|
|
|
合计
|
|
作技术的组长和经理们，虽然一头雾水：这根本就没解决我的问题吗！不过，至少我知道该怎么干了。上去三下五除二给它填完了。加班多的，工作量打满分；打游戏的，工作态度全扣了……
这法子实施容易，而且总的来说，至少组长经理们觉得是公平了。老板看他们同意了，也乐得消停。
但是，这种方法也有很大的问题。最大的问题是把人看死了：好人永远是好人，落后永远是落后。时间一长，论资排辈，老人把权，企业失去动力。
但是，这种方法也有很大的问题。最大的问题是把人看死了：好人永远是好人，落后永远是落后。时间一长，论资排辈，老人把权，企业失去动力。
这种方法是以组织结构为中心的考核：组长给组员打分，经理给组长和打分，总经理给经理打分。大概是绝大多数有考评的单位的主要方式。
改变这种情况有什么方法吗？较好的方法是从以组织结构为中心的变为以项目为中心的考核。抽象的说，就是在每个项目中考核每个成员的评分，此评分是根据技术指标来衡量的；每年每季度每月的考评分就由个人参与的在项目中的总分来决定。通常来说，这种评分方式，适用于所有经理以下的人员的考评。而经理的考评，则可以按照MBO的方式，即Manage by Objective来管理。
改变这种情况有什么方法吗？较好的方法是从以组织结构为中心的变为以项目为中心的考核。抽象的说，就是在每个项目中考核每个成员的评分，此评分是根据技术指标来衡量的；每年每季度每月的考评分就由个人参与的在项目中的总分来决定。通常来说，这种评分方式，适用于所有经理以下的人员的考评。而经理的考评，则可以按照MBO的方式，即Manage by Objective来管理。
这种考评方式，能够极大激发基层员工的动力。因为考评结果是在各个项目中得分的总和，他们会乐意参加更多的项目。考评分用技术指标决定，如工作量用完成的功能点来衡量，工作质量用每千行代码Bug数衡量，技术人员会认为这很公平，从而有动力更努力。
这种考评方法，也要求管理层有一种开放的管理态度：从“我要管”到“我来评”的转变。开放，第一，体现在允许员工内部自由流动。很多基层或中层组织和经理都有一种不愿意放人的倾向，从而使得一些内部员工不能到他喜欢和胜任的岗位上去，最后选择离开公司。与其这样，不如让他们自己在公司里寻找机会，同时也承担转岗的后果。第二，相信被充分信任，授权而责任明确的员工会努力完成自己的工作。这比保姆式管理要好的多。以前遇到一个能力很强的组长，经常比喻他做项目是就像两手护着一圈鸡蛋，稍不留心，鸡蛋就漏了，以示他的手下多么不济；后来这个组长走了，项目的后续版本却还是正常发布，没见那个鸡蛋打掉了。
当然，这种管理方法最大的要求是具备良好的信息化管理。比如，代码应该有统一的代码库管理，而不是只保存在程序员个人手里；Bug也要存在缺陷管理库中，不是只是去跟程序员讲一下。每个项目结束时，每项统计指标的计算也是烦琐的工作，需要人力和耐心。
除了信息化管理外，各级组织结构上的经理和组长的认可也是很重要的。因为他们在员工的评价的主导权上有所削弱，甚至这种评价方法出来的结果和他们的“影响”不一致。只是需要和他们讨论：也许要改变的是个人的成见，而不是评分。
- mEjY 发表于2006-08-11 14:15:00 IP: 203.86.95.*
- 利用bug数来衡量也是有问题的。个人不太赞成。因为bug的数量不光只取决于开发人员，还取决于测试人员和系统环境，和项目的需求是否明确，设计是否合理有很大的关系
- jiafcat 发表于2006-09-26 15:30:00 IP: 61.233.10.*
- "工作质量用每千行代码Bug数衡量"，不赞同。代码的可维护性、可读性没有体现。我见过一大段代码被复制4、5遍，就是不提取出来一个方法的程序员。
如何考核程序员绩效(zt)
某软件公司的业务是制作互联网应用系统，老张是该公司开发项目经理。由于程序员工作难以量化，公司对程序员的评价一直是由开发经理根据感觉得出的。老张希望进行一些改进，于是在老总的支持下，制定了程序员的周汇报机制：程序员每周五下班前提交周报，填写每日的工作情况。但在试行的两个月中，老张发现每个程序员都填得很简单，而且几乎没人能在周五记得周一的事情，根本不能为量化考核提供依据。在发现这种情况之后，老张强调不能简写周报，否则退回，但仍然收效不大。
程序员们有自己的理由，认为工作难以量化，比如同样是做两个功能模块，有复杂的有简单的，总不能去统计代码行数。所以，填写工作周报纯属浪费时间，没有任何意义。
于是，周报成了摆设，老张还是不能了解程序员的详细工作进度。面对日渐推后的项目进度，老张决心要改变这种情况。
老张应该如何去改变这种情况？
案例分析
本案例看起来是关于绩效考核的，但是从更深层来看是关于软件开发整体管理水平的。软件开发项目延迟现象非常严重，在中国更是如此。大家都知道其主要原因是软件开发的项目管理问题，这也正是软件开发中最困难的。近几年来，软件工程、CMM、软件蓝领等概念在中国炒得沸沸扬扬，但是目前还没有见到明显效果。更令人担忧的是，在我国的软件公司，通过CMM评估往往是仅仅用来宣传的，而没有真正起到规范企业开发流程的作用。即使是用友、东软等通过CMM3级评估的国内顶级软件公司也是如此。
各抒己见
1x老张ing
老张的考核方式存在问题，工作报表容易引起程序员的反感。对于脑力劳动成分高的科研技术类项目，应该实行结果管理而不是行为管理，比如上文有些程序员提到代码的自动化、模块的难易等。因此，最好实行目标管理，事先对每个程序员的工作进行规划，将每个可考核的功能完成时间设为考核时间，然而采用积分制进行程序员水平整体考核。
AllanYu
我认为，对项目组成员的任务安排的合理化程度才是最重要的。跟技术人员的一些冲突是不可避免的，但是一定要控制在一个“度”内，如果是和大部分的项目相关人员都发生冲突，那作为项目经理就要自己反思了。至于高分、低分的问题，关键还是由项目经理根据对项目组成员的任务安排的合理化程度来决定。
papachong
由此带来的问题还包括：项目经理如何进行考核，对其综合素质如何进行评分。如果是认真负责的项目经理，则会导致跟技术人员的一些冲突，如果是管理水平一般的项目经理，则会做好好先生，都是高分。
lucy
考核是为了激励，要基于如何激励来设计考核制度。这样单单用工作报告肯定是不行的，摆明了是在监工，当然技术人员不乐意接受。你换个角度，如果你是程序员，你希望公司如何激励你、考核你？
Lear
作为项目经理，首先应该对自己搞的这个项目比较了解，在此基础上将该项目分成几个子项目，然后将各子项分给各个程序员，并定下时间限制，具体工作由程序员自主进行，同时配合一定的奖惩措施。并且平时还应该和职员多交流，对他们的情况有大致了解，特别是对那种有较高号召力的职员。
sam_zxh
作为部门经理，首先应该了解业务，了解员工的工作能力情况，这样才可能制定出合理的进度计划，然后根据员工的个人能力派工。
专家点评：项目管理要有科学方法
在本案例中，老张试图加强项目管理的努力是值得肯定的，但他应该注意加强项目的沟通管理，并改进项目的计划、监控、考评等工作。
■ 加强沟通：项目的成功需要全体成员的努力，项目管理的成功也同样离不开项目团队的积极参与。项目沟通是项目管理的重要内容，有效的沟通能使项目团队的认识一致，并努力实施计划、共同推进项目。项目经理应做好沟通计划，加强沟通工作，让团队积极参与计划、监控、考评等项目管理工作；
■ 改进计划：项目计划应尽可能由项目团队共同制定，以确保计划的科学性，并充分调动项目成员的积极性。在制定进度计划时，除了要合理安排任务的人力、排序、历时外，还应注意按阶段对任务进行科学的粒度划分；
■ 有效监控：对项目实施情况进行及时有效的进度监控，需要建立一整套反馈、检测的程序和制度，并根据任务的重要性、难度等因素合理安排监测周期。此外，还要注意结合详细严密的进度计划和科学的考评激励体系，并做好沟通工作。
■ 考评与激励：科学有效的考评和激励是项目成功的关键要素。在进行绩效考评前，应针对项目特点，设计好考评指标和权重，并注意编制合理、可操作的考评标准与规范，从而建立起科学、可行的绩效考评与激励体系。考评体系要有团队成员参与制订，并根据实际情况不断优化。
专家介绍
郜宝林，资深IT人士，清华大学软件工程硕士。主持和参与过银行、证券、保险、信托、财务公司及商业、制造业等行业近百个企业信息系统的建设，长期担任国内著名软件公司中高级管理职位，目前负责主持研发面向金融行业的解决方案。
程序员们有自己的理由，认为工作难以量化，比如同样是做两个功能模块，有复杂的有简单的，总不能去统计代码行数。所以，填写工作周报纯属浪费时间，没有任何意义。
于是，周报成了摆设，老张还是不能了解程序员的详细工作进度。面对日渐推后的项目进度，老张决心要改变这种情况。
老张应该如何去改变这种情况？
案例分析
本案例看起来是关于绩效考核的，但是从更深层来看是关于软件开发整体管理水平的。软件开发项目延迟现象非常严重，在中国更是如此。大家都知道其主要原因是软件开发的项目管理问题，这也正是软件开发中最困难的。近几年来，软件工程、CMM、软件蓝领等概念在中国炒得沸沸扬扬，但是目前还没有见到明显效果。更令人担忧的是，在我国的软件公司，通过CMM评估往往是仅仅用来宣传的，而没有真正起到规范企业开发流程的作用。即使是用友、东软等通过CMM3级评估的国内顶级软件公司也是如此。
各抒己见
1x老张ing
老张的考核方式存在问题，工作报表容易引起程序员的反感。对于脑力劳动成分高的科研技术类项目，应该实行结果管理而不是行为管理，比如上文有些程序员提到代码的自动化、模块的难易等。因此，最好实行目标管理，事先对每个程序员的工作进行规划，将每个可考核的功能完成时间设为考核时间，然而采用积分制进行程序员水平整体考核。
AllanYu
我认为，对项目组成员的任务安排的合理化程度才是最重要的。跟技术人员的一些冲突是不可避免的，但是一定要控制在一个“度”内，如果是和大部分的项目相关人员都发生冲突，那作为项目经理就要自己反思了。至于高分、低分的问题，关键还是由项目经理根据对项目组成员的任务安排的合理化程度来决定。
papachong
由此带来的问题还包括：项目经理如何进行考核，对其综合素质如何进行评分。如果是认真负责的项目经理，则会导致跟技术人员的一些冲突，如果是管理水平一般的项目经理，则会做好好先生，都是高分。
lucy
考核是为了激励，要基于如何激励来设计考核制度。这样单单用工作报告肯定是不行的，摆明了是在监工，当然技术人员不乐意接受。你换个角度，如果你是程序员，你希望公司如何激励你、考核你？
Lear
作为项目经理，首先应该对自己搞的这个项目比较了解，在此基础上将该项目分成几个子项目，然后将各子项分给各个程序员，并定下时间限制，具体工作由程序员自主进行，同时配合一定的奖惩措施。并且平时还应该和职员多交流，对他们的情况有大致了解，特别是对那种有较高号召力的职员。
sam_zxh
作为部门经理，首先应该了解业务，了解员工的工作能力情况，这样才可能制定出合理的进度计划，然后根据员工的个人能力派工。
专家点评：项目管理要有科学方法
在本案例中，老张试图加强项目管理的努力是值得肯定的，但他应该注意加强项目的沟通管理，并改进项目的计划、监控、考评等工作。
■ 加强沟通：项目的成功需要全体成员的努力，项目管理的成功也同样离不开项目团队的积极参与。项目沟通是项目管理的重要内容，有效的沟通能使项目团队的认识一致，并努力实施计划、共同推进项目。项目经理应做好沟通计划，加强沟通工作，让团队积极参与计划、监控、考评等项目管理工作；
■ 改进计划：项目计划应尽可能由项目团队共同制定，以确保计划的科学性，并充分调动项目成员的积极性。在制定进度计划时，除了要合理安排任务的人力、排序、历时外，还应注意按阶段对任务进行科学的粒度划分；
■ 有效监控：对项目实施情况进行及时有效的进度监控，需要建立一整套反馈、检测的程序和制度，并根据任务的重要性、难度等因素合理安排监测周期。此外，还要注意结合详细严密的进度计划和科学的考评激励体系，并做好沟通工作。
■ 考评与激励：科学有效的考评和激励是项目成功的关键要素。在进行绩效考评前，应针对项目特点，设计好考评指标和权重，并注意编制合理、可操作的考评标准与规范，从而建立起科学、可行的绩效考评与激励体系。考评体系要有团队成员参与制订，并根据实际情况不断优化。
专家介绍
郜宝林，资深IT人士，清华大学软件工程硕士。主持和参与过银行、证券、保险、信托、财务公司及商业、制造业等行业近百个企业信息系统的建设，长期担任国内著名软件公司中高级管理职位，目前负责主持研发面向金融行业的解决方案。
(Page 1 of 1, totalling 4 entries)
