lizhenqiu blog

不问自取 是为贼。版权费买是60一张，罚是500一张，我觉得很合理。如果你偷用被发现了才交钱，交的还和那些自觉守法的一样多，那谁还去买？

人错了，就什么都错了。

如何考核程序员绩效

　　某软件公司的业务是制作互联网应用系统，老张是该公司开发项目经理。由于程序员工作难以量化，公司对程序员的评价一直是由开发经理根据感觉得出的。老张希望进行一些改进，于是在老总的支持下，制定了程序员的周汇报机制：程序员每周五下班前提交周报，填写每日的工作情况。但在试行的两个月中，老张发现每个程序员都填得很简单，而且几乎没人能在周五记得周一的事情，根本不能为量化考核提供依据。在发现这种情况之后，老张强调不能简写周报，否则退回，但仍然收效不大。

　　程序员们有自己的理由，认为工作难以量化，比如同样是做两个功能模块，有复杂的有简单的，总不能去统计代码行数。所以，填写工作周报纯属浪费时间，没有任何意义。

　　于是，周报成了摆设，老张还是不能了解程序员的详细工作进度。面对日渐推后的项目进度，老张决心要改变这种情况。

老张应该如何去改变这种情况？


案例分析


　　本案例看起来是关于绩效考核的，但是从更深层来看是关于软件开发整体管理水平的。软件开发项目延迟现象非常严重，在中国更是如此。大家都知道其主要原因是软件开发的项目管理问题，这也正是软件开发中最困难的。近几年来，软件工程、CMM、软件蓝领等概念在中国炒得沸沸扬扬，但是目前还没有见到明显效果。更令人担忧的是，在我国的软件公司，通过CMM评估往往是仅仅用来宣传的，而没有真正起到规范企业开发流程的作用。即使是用友、东软等通过CMM3级评估的国内顶级软件公司也是如此。( 栏目合作单位：项目管理者联盟www.mypm.net)


各抒己见


老张

　　老张的考核方式存在问题，工作报表容易引起程序员的反感。对于脑力劳动成分高的科研技术类项目，应该实行结果管理而不是行为管理，比如上文有些程序员提到代码的自动化、模块的难易等。因此，最好实行目标管理，事先对每个程序员的工作进行规划，将每个可考核的功能完成时间设为考核时间，然而采用积分制进行程序员水平整体考核。

AllanYu

　　我认为，对项目组成员的任务安排的合理化程度才是最重要的。跟技术人员的一些冲突是不可避免的，但是一定要控制在一个“度”内，如果是和大部分的项目相关人员都发生冲突，那作为项目经理就要自己反思了。至于高分、低分的问题，关键还是由项目经理根据对项目组成员的任务安排的合理化程度来决定。

papachong

　　由此带来的问题还包括：项目经理如何进行考核，对其综合素质如何进行评分。如果是认真负责的项目经理，则会导致跟技术人员的一些冲突，如果是管理水平一般的项目经理，则会做好好先生，都是高分。

lucy

　　考核是为了激励，要基于如何激励来设计考核制度。这样单单用工作报告肯定是不行的，摆明了是在监工，当然技术人员不乐意接受。你换个角度，如果你是程序员，你希望公司如何激励你、考核你？

Lear

　　作为项目经理，首先应该对自己搞的这个项目比较了解，在此基础上将该项目分成几个子项目，然后将各子项分给各个程序员，并定下时间限制，具体工作由程序员自主进行，同时配合一定的奖惩措施。并且平时还应该和职员多交流，对他们的情况有大致了解，特别是对那种有较高号召力的职员。

sam_zxh

　　作为部门经理，首先应该了解业务，了解员工的工作能力情况，这样才可能制定出合理的进度计划，然后根据员工的个人能力派工。


专家点评：项目管理要有科学方法


　　在本案例中，老张试图加强项目管理的努力是值得肯定的，但他应该注意加强项目的沟通管理，并改进项目的计划、监控、考评等工作。

■ 加强沟通：项目的成功需要全体成员的努力，项目管理的成功也同样离不开项目团队的积极参与。项目沟通是项目管理的重要内容，有效的沟通能使项目团队的认识一致，并努力实施计划、共同推进项目。项目经理应做好沟通计划，加强沟通工作，让团队积极参与计划、监控、考评等项目管理工作；

■ 改进计划：项目计划应尽可能由项目团队共同制定，以确保计划的科学性，并充分调动项目成员的积极性。在制定进度计划时，除了要合理安排任务的人力、排序、历时外，还应注意按阶段对任务进行科学的粒度划分；

■ 有效监控：对项目实施情况进行及时有效的进度监控，需要建立一整套反馈、检测的程序和制度，并根据任务的重要性、难度等因素合理安排监测周期。此外，还要注意结合详细严密的进度计划和科学的考评激励体系，并做好沟通工作。

■ 考评与激励：科学有效的考评和激励是项目成功的关键要素。在进行绩效考评前，应针对项目特点，设计好考评指标和权重，并注意编制合理、可操作的考评标准与规范，从而建立起科学、可行的绩效考评与激励体系。考评体系要有团队成员参与制订，并根据实际情况不断优化。

专家介绍

　　郜宝林，资深IT人士，清华大学软件工程硕士。主持和参与过银行、证券、保险、信托、财务公司及商业、制造业等行业近百个企业信息系统的建设，长期担任国内著名软件公司中高级管理职位，目前负责主持研发面向金融行业的解决方案。

身为程序员，对于绩效考核，我更多的是关注：制度的透明性和执行程度。很多公司，都是有制度的，但是 制度之外的“人治因素”却又很明显。导致很多程序员都是“听天由命”。

我想考核的话最后的结果很重要。对程序员进行过程式的绩效考核难免会太浪费精力，而且弊多余利，因为很多时候程序员是做创造性的工作，所以不能用制度给予他们束缚，给他一个任务最后看结果就好。

主观评价本质上是属于非量化的考核方法，无论怎么改进都是无法成为量化的考核方法，国内最大的问题就是非量化的考核方法成为了唯一的考核方法，这就造成了考核没有成为团队的助益的后果。最好的考核方法是必须包含量化的考核方法，甚至应该占到一半的水平。

绩效考核这个东西很多时候还是主观意识的结果。

工作量的分解，难度的评估，是另外一件事。

事实上依靠人来评估有时会有失公正。
我假设存在一种“机器M”，M可以对程序员开发的代码进行客观公正的度量，以测算程序员的绩效值。
一种反例：一名负责内核开发的程序员A，编写了1万行关于线程的代码，A为此参考了大量的操作系统开发资料，包括windows、linux等等。
程序员B负责开发搜索引擎实现算法，编写了1万行关于优化搜索的代码，B为此的设计了数学模型，并将模型通过大量数据加以验证模型的正确度，通过多次失败后才最终修正模型。
M在对程序员A、B进行测算绩效时，将无法有效核准他们的差异，因为M缺少经验，M不可能知道所有领域的开发难度，以及开发时的时间损耗，有些开发并非总是成功。故此反证：M不存在。

由此可知，考核程序员的标准需要什么？需要“领域经验”，领域外的主管无法评估领域内的程序员，这是一个客观存在的事实。