Beta阶段团队成员贡献分分配规则
Beta阶段团队成员贡献分分配规则
Alpha阶段贡献分分配有些负责,在这里进行一些修改:
对任务完成得分部分进行了简化
对发现bug的惩罚措施进行了修改
移除了优化得分,不鼓励修改他人代码
移除了帮助加成,剔除主观因素
1. 得分细则
1.1 任务完成得分
L=预期任务量(1~8):在布置任务的时候预计所需时间,不再更改
D=难度(0.0~2.0):由于难度产生的时间变数,由之前会议商讨决定,遇到坑的时候及时在群里求助,可以更改
下面是难度系数(D)的评定参考:
评价成绩 | 效果 |
---|---|
0.5 | 基本没有技能需求,不需要太多思考 |
1.0 | 需要一些技能基础,难度适中,或需要较大思考 |
1.5 | 坑很多,解决费了不少时间,需要较强的问题解决能力 |
2.0 | 小组成员里其他人做不到,只有老司机才能驾驭 |
E=完成度(0.0~2.0,默认为1.0):1为正常,有缺陷适当扣除,有亮点适当增加,根据后期补全情况可以更改 |
下面是完成度(E)的评定参考:
评价成绩 | 效果 |
---|---|
0.8 | 基本完成功能,但是很简陋,部分细节未能达到预期要求 |
1.0 | 完成得一般,要求的功能都实现了,但是还有优化的空间 |
1.2 | 完美完成,无可挑剔 |
最终的得分要根据完成度、预期任务量和难度三方面评定,即
任务完成得分 = E * L * (1 + D) * 5
举例:
A君接了一个任务量为6,难度系数为1的任务,但是在实际编码中发现这里面的坑比想象中的要大许多,经过和PM商议,将难度系数调整为1.5。
由于要赶在DDL之前提交任务,做得比较仓促,虽然要求确实都满足了,但是还欠缺完美,完成度为1.0,那么A君的最终得分为:
1.0 * 6 * (1 + 1.5) * 5 = 75
1.2 任务遇到问题:
注:任务延期需要向PM说明理由,若理由合理则不扣分。
- 遇到了非常大的坑,在群里询问以及向PM汇报之后仍未解决,可以申请延期或暂时不实现相关功能,按当前完成度给予一定分数;
- 由于个人原因(如修复bug)导致未能完成任务,获得的任务分每拖延一天乘以70%(若修复bug不影响其他工作,不扣分);
- 对于用户发现,且未事先进行说明的bug,视严重程度给予相应开发人员扣分,此扣分和第3条相互独立,可以叠加。
用户发现bug扣分参考:
总扣分 | 严重程度 |
---|---|
0 | 不注意就不会发现的问题,给予警告 |
5 | 一般功能性问题,局部影响用户使用 |
10 | 严重影响用户使用 |
20 | 相当严重的问题,甚至对接下来的开发造成影响 |
1.3 发现bug得分
发现影响用户使用的bug,第一发现者可获得5分奖励(不能是自己负责的功能)。
2. 最终贡献分
通过3中的计算方法,可以得到每名成员的得分,我们根据每名成员的得分比例分配最终的贡献分。
公式表达如下:
假设第x名成员得分为Ax
成员x贡献分 = Ax / ∑A * (6 * 50)