《构建之法》（十一）

绩效管理

本书前面讲了怎样衡量软件工程师的能力,  工程师如何成长, 如何证明自己的成长, 等等. 这些都是在一个独立的, 不受外界干扰的空间中做出来的判断。 我们假设一个有能力的工程师, 到了另一个团队, 仍然是一个有能力的工程师。

如何衡量个人在团队中的绩效?

如果一个工程师能够成长，他/她就应该在团队中发挥较大的作用。但是一个团队中的每一个人都有各自的努力和作用, 如何衡量个人在团队中的绩效呢? 即是从管理者的角度出发如何管理一群人的绩效。  

在软件工程这门课中, 几个学生组成一个小组, 干活多的人和干活少的人都得到一样的 “团队成绩”, 这似乎不利于调动积极性。为了团队中不为成绩而发生间隙。就需要各种方案了。

在小学期的时候，小组团队作业中，老师会想办法让成绩具有起浮性，或者演讲或提交作业时要求明确组员的分工所做的内容。这也是一种方案吧。即书上说的 根据工作量来算就好了！但这种方法可能只适用于学校作业吧，老师一看就知道各部分的工作量和质量了。

但也许就如书上所说，在IT行业会出问题，容易 重视“量的管理”，“质” 则次之。

 

那如何衡量个人在团队中的绩效?看了几个团队都有自己的点子，一帮学生临时组成一个团队, 用什么方法评比并没有重大的影响， 大不了在期末成绩上少一两分。 但是软件公司的团队就不同了, 不合理的绩效考核不但影响各人的收入, 而且会影响人员的士气, 流动, 后续的合作和产品质量,不能不慎重。   

那比啥呢？比资历?大锅饭?比效率? 背靠背评比?比不犯错误? 还是比如何区别对待?

 

为了更客观地反映员工绩效的不同的因素,  有些公司实施过二维的评价体系:

完成任务维度: 主要由团队成员和直接经理商量年度目标, 直接经理有较多的自由度决定 好/中/差.  例如大部分成员都可以得到 “好”这一评价。

团队贡献维度: 还是严格根据人员百分比, 评出团队中最好的20%, 中间的70%, 和最需要改进的 10%.

 

具体怎样才能最有管理绩效问题，看完这章我也没有得出具体结论。只能说在不同的团队，仁者见仁智者见智吧。