前段时间，公司签了年终奖确认。觉得公司发放年终奖完全是凭主观发放，没有事实依据，由此产生了对如何发放年终奖的一些想法。
奖金发放作为激励员工最直接的手段，往往也是让管理人员最难抉择的，而且很多公司，都是带有大部分直接主管主观意识评定的。在我看来，这是最不可取的，因为奖金作为激励手段，初衷应该是鼓励员工继续发扬往年优秀的部分，并识别和看清自身（或者整个团队甚至部门或公司）的短板，并在来年采取有效的方案或措施进行改进，为自身(或部门或公司)改进提供风向标，这样才能做到自身水平的不断提高，为公司创造更大的利益。所以奖金的方案必须是公平公开并且是透明的，而不是不可议论的。至于薪资，可以作为一个保密项，但是奖金比例是完全可以透明，并由直接主管作为桥梁来沟通并指出不足。
至于奖金的考核方案，我先举个栗子，假设某团队是以敏捷开发作为管理框架的，评估工作量以故事点作为标准。这里说一下以故事点作为评估工作量的单位。在实际工作中，一个团队可能有初级、中级、高级的开发人员，他们的技术水平是不一样的，但是如果是对同一个功能点进行功能的评估，假设需求理解都是一致的情况下，他们完成该功能的时间应该是会不一致的，所以以时间作为评估标准是很不可取的。但是，他们完成不同功能的评估的故事点应该是一致的。我们来几张图标说明会更清晰。
对于三个功能，他们评估的故事点可能是这样的：
他们评估的人天数可能是这样的（这里为了演示，将他们的比例误差设置为0，即都是按一定比例估算的，实际上应该会有一些误差，但是趋势应该是一致的）：
上面俩张表可以看出，对于能力不一样的人，他们评估的人天数肯定是不一样的。你可以假设一个小学生，跟一个大学生搬砖，同样是100块砖，比较他们完成的时间。那么我们如何在做绩效考核的时候，能够排除这些能力因素，或者说，能够达到多劳多得，并且为调薪提供一个比较公平客观的依据，并能不断让开发人员认识到自己的不足并采取改进措施呢？
我认为，敏捷大法不仅仅适应于项目管理，同样适用于人员的管理。我的方案是，在每个迭代结束时做Sprint Retrospect会议的时候，不仅仅针对团队，同时可以收集一些数据，例如：本次迭代完成的故事点数、测试bug数、代码注释率、代码简洁渡(这个比较难，能力上提高了的话，代码自然会简洁)，同时，针对个人在这几方面的数据进行分析，找到自己的薄弱点，采取措施(最好是可量化的)，将每次迭代的数据都记录到信息发射源。当然，对于表现优秀的，可以采取一些奖励措施，比如说荣誉墙，涂鸦墙，甚至是调休奖励。下面，我们看一下我们收集到的故事点的信息：
我们将这些数据制成图表：
图表就能看出，每个人每个月(或每次迭代)完成的故事点数的趋势，很清晰的可以看出哪些人在进步，进步最大的员工是哪位。也可以以此来作为调薪的依据。
我们再将上面的表格做一些修改：
我们将所有的月份的故事点加起来，就是这一年完成的故事点总数，再将团队内所有人员的故事点，取比值，以小李的故事点为基数，小李的故事点比值为1，老张的未423/270=1.566，小陈的是350/270=1.296，同样，我们将薪资比例计算出来。这样，我们就可以用这些比例来确定奖金和调薪幅度等。还是如上例子，我们假设年终奖的基数是3个月，那么小李应该得到的奖金应该是1*3*15000，老张应该得到的是1.56*3*30000，小陈应该得到的是1.296*3*24000。这里我们是以故事点(即工作量)这一单一维度来计算的，我们也可以结合其他指标加权来计算这个年终奖。
我们再看一下调薪比例，我们可以用故事点数比值/薪资来确定调薪，这样就将能力与当年的表现结合起来了。如果格局再高，同样也可以通过制定部门年度目标或季度目标，来考核部门并确认部门奖金比例。
本文写得有点啰嗦，大家可以发表自己的一些看法。
