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

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

如果一个工程师能够成长,他/她就应该在团队中发挥较大的作用。但是一个团队中的每一个人都有各自的努力和作用, 如何衡量个人在团队中的绩效呢?  我们看看别的行业的例子:

一群人把一堆砖头从A地搬到B地。

一个剧组排演话剧     (有导演, 有主角, 有配角, 有舞美设计, 有灯光师, 角色能随意替换么?)

一群画家集体创作 “百里长江图”     (你画一个局部, 我画一个局部, 如何构成一部好作品?)

一群医生/护士轮流值夜班     (有人值班一个晚上抢救了几个病人, 失败了几次;也有人值班时没人来求医, 谁好?)

一群老师教课     (有人讲得难, 有人讲得容易, 有不同的课程, 谁最有效率?)

一群编辑在出版社里出书     (有人碰到好题目, 有人碰到不靠谱的作者, 有人的书叫好,有人的书叫座, 有人的书冷门但是有热情,  谁是好编辑?)

一群学生做软件工程项目

 

这篇博客讲的是从管理者的角度出发如何管理一群人的绩效。  一群人在一起做事, 事成之后, 就有排座次, 论功劳的问题 - 在有些团队里, 事成之前就为功劳的事吵翻了 现代软件工程 10 绩效管理_软件工程师 

软件团队如何做人员的绩效管理? 这个问题较难回答, 因为所有人的工作被集成在一个软件产品中, 互相依赖, 产品功能被用户赞扬或批评, 都不能简单地完全对应于某一个人的工作。 有些功能看起来好, 有人会说 - 因为这个很容易…  有些功能用户不喜欢, 当事人会说 -

“换别人来做, 可能还不如我呢.” 或者,

“这是底层的问题”, 或者

“PM 根本就没设计好” 或者

“测试人员没有好好测!” 当然, 还有 –

“用户太蠢了"。。。  

 

在软件工程这门课中, 几个学生组成一个小组, 干活多的人和干活少的人都得到一样的 “团队成绩”, 这似乎不利于调动积极性。 为了解决这个问题, 我给每个团队一些浮动的分数 - 相当于基本工资之外的奖金, 大家决定怎么分这个“团队贡献”的奖金。

 

有人会说, 根据工作量来算就好了!这会出问题 - 以前我写过:

今天一个做技术推广的朋友说他的老板非常重视“量的管理”,“质” 则次之。

这使我想起偶尔看到一本书中的一段回忆文字,虽然不是 IT 行业,但是有异曲同工之妙:

“。。。他是多年在联合国工作的资深外交人员,对议事规则相当熟悉,不断要求上台发言。... 他在代表团内始终是副代表代理常任代表,而他的待遇则依照在联合国内发言时间的多寡做决定。 …他每天游走于联合国大厦各会议室间,进门后即登记发言,随即静听先登记各代表发言内容,他不需准备,轮到他时即席演说,最少三十分钟,随即到次一会议室照样发言,…第二天将有关速记纪录中他的发言辑录起来,月底向祖国报销,根据发言数量由政府核发薪资
十月二十五日下午,大会中他将这项技术发挥尽致,多次依照议事规则相关条文要求发言,每次发言必长,引起与会代表极度反感。”

另外在软件行业, 如何衡量工作量这本身就是一个大问题.

  1. 根据每人代码量, 每天统计进度? 有大牛报告 - 今天我重构了原来的代码, 删掉了原来的2000 行多余的程序, 那我今天的贡献是 负的两千?!

  2. 注释, 空行算么? 如果算的话, 移山公司的果冻同学就高兴了, 他每天快乐地写注释, 边写边说 - 今年旅游的机票钱有了!

  3. 根据目标码大小? 那我们不能用库函数了?

有人建议按照角色来定位, 例如有猪, 鸡和鹦鹉等, 问题是大多数鹦鹉都说自己是鸡, 剩下的觉得自己是猪, 而且分量很重!  

有人建议根据工作时间来衡量,  这规定一宣布, 大家都开始比谁走得晚,  另外,  我周末的时候一直在想工作上的事, 这算工作时间么? 

在统计技术支持人员的绩效时, 有些公司主要考虑他们接到用户电话后处理问题的时间长短。这时有聪明的员工往往拿起电话后, 说: "你好!” 然后马上挂断电话。 顾客们虽然摸不着头脑, 但是技术人员的 "与顾客通话时间" 则大大降低。 这样的 “好” 绩效, 最后对公司有利么? 

看来似乎所有的衡量方法都有致命的空子可以钻。 在 <人件> 这本书中, “衡量劳动生产率” 和 “UFO” 是放在同一个小标题下的. 然而, “任何一种衡量方法都比完全不量要好” - 书中说。

这次《现代软件工程》上课的几个团队都有自己的点子:

第一组(seven):  我们可以按照以上的9级来分,但是对于我们而言,大家在很大程度上都是同一级的劳动者....所以我们可以更加细分同一级的排名,比如将整个任务分为等量的小任务,每个人负责其中的一个,而最终大家的排名可以通过完成这样任务的个数来决定。关于如何评价是否完成“任务”,可以通过功能性、是否准时来评价;而且当整个工程完结的时候,我们可以做一个review,包括功能、性能和代码的评价,然后大家之间讨论互评。

 

第二组(霸王):  

对于浮动分数,可以通过每个职位对于团队的贡献来添加。队友之间根据各自的贡献给出排序,最后汇总得分。

第三组 (铷铯):

一群学生做软工项目 (PM, Dev, Test),   PM:0.3(n*30)分,   DEV: 0.5(n*30)分   test:0.2(n*30)分

 

第四组 (take it & go):

在团队合作中每个成员的贡献度不仅仅取决于他的工作量,而且还取决于这份工作对团队的意义有多大。我认为贡献度的计算应遵循如下公式:

贡献度 = 工作量 × 工作的影响力 × 工作的不可替代性

这个等式给我们的评测提供了一个方向。与直接估计贡献度相比,分别估计三个分量显得更可操作,准确性也更高。

          //评点: 如果大家都想做 “不可替代的工作”, 怎么办?

第五组(banana):

关于管理体系,可以天花乱坠的说很多,但实际和理论会差的很远,我们并不能完全按照一个专业团队去执行。
大四是一个美好休闲的时光,很难要求大家训练有素地执行进度,我们只能尽可能友情提示大家一起干一些事,但我觉得做完整个工程应该没有问题。