一个软件工程师好不好？怎么判断？

记件制？看看代码写得多不多？稍有头脑的人机会立刻反对。精妙的代码不需要长。如果要比长，本来调用一个公共库中的函数就好了，现在我就拷贝过来；本来有一个状态变量可以重用，我再加一个；&hellip&hellip程序员的法子多了。高手们全不干了，有的Bug，查要一个星期，而且每天晚上都得查到凌晨两点，改起来就一行，这老兄一定跳起来了。所以记件制不行。

记时制？每天八小时上班，太容易了。比加班，谁比得过毛头小伙子啊！而且，你知道我加班干什么？白天我可以天天上网，晚上干点活。或者我加班就打游戏，老板反正不在。时间长了，就变成了大锅饭。这也不行。

做技术的通常想到这儿就没什么法子了。人力资源专家通常这个时候跳出来了：KPI嘛！

KPI全称是Key Performance Index，就是大家每年每季度或每个月要填的表格：

考核项权重得分
工作量
30%

工作质量
30%

工作态度
10%

沟通能力
10%

合计

作技术的组长和经理们，虽然一头雾水：这根本就没解决我的问题吗！不过，至少我知道该怎么干了。上去三下五除二给它填完了。加班多的，工作量打满分；打游戏的，工作态度全扣了&hellip&hellip

这法子实施容易，而且总的来说，至少组长经理们觉得是公平了。老板看他们同意了，也乐得消停。

但是，这种方法也有很大的问题。最大的问题是把人看死了：好人永远是好人，落后永远是落后。时间一长，论资排辈，老人把权，企业失去动力。

这种方法是以组织结构为中心的考核：组长给组员打分，经理给组长和打分，总经理给经理打分。大概是绝大多数有考评的单位的主要方式。

改变这种情况有什么方法吗？较好的方法是从以组织结构为中心的变为以项目为中心的考核。抽象的说，就是在每个项目中考核每个成员的评分，此评分是根据技术指标来衡量的；每年每季度每月的考评分就由个人参与的在项目中的总分来决定。通常来说，这种评分方式，适用于所有经理以下的人员的考评。而经理的考评，则可以按照MBO的方式，即Manage by Objective来管理。

这种考评方式，能够极大激发基层员工的动力。因为考评结果是在各个项目中得分的总和，他们会乐意参加更多的项目。考评分用技术指标决定，如工作量用完成的功能点来衡量，工作质量用每千行代码Bug数衡量，技术人员会认为这很公平，从而有动力更努力。

这种考评方法，也要求管理层有一种开放的管理态度：从&ldquo我要管&rdquo到&ldquo我来评&rdquo的转变。开放，第一，体现在允许员工内部自由流动。很多基层或中层组织和经理都有一种不愿意放人的倾向，从而使得一些内部员工不能到他喜欢和胜任的岗位上去，最后选择离开公司。与其这样，不如让他们自己在公司里寻找机会，同时也承担转岗的后果。第二，相信被充分信任，授权而责任明确的员工会努力完成自己的工作。这比保姆式管理要好的多。以前遇到一个能力很强的组长，经常比喻他做项目是就像两手护着一圈鸡蛋，稍不留心，鸡蛋就漏了，以示他的手下多么不济；后来这个组长走了，项目的后续版本却还是正常发布，没见那个鸡蛋打掉了。

当然，这种管理方法最大的要求是具备良好的信息化管理。比如，代码应该有统一的代码库管理，而不是只保存在程序员个人手里；Bug也要存在缺陷管理库中，不是只是去跟程序员讲一下。每个项目结束时，每项统计指标的计算也是烦琐的工作，需要人力和耐心。

除了信息化管理外，各级组织结构上的经理和组长的认可也是很重要的。因为他们在员工的评价的主导权上有所削弱，甚至这种评价方法出来的结果和他们的影响不一致。只是需要和他们讨论：也许要改变的是个人的成见，而不是评分。