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说明理由,若理由合理则不扣分。

  1. 遇到了非常大的坑,在群里询问以及向PM汇报之后仍未解决,可以申请延期或暂时不实现相关功能,按当前完成度给予一定分数;
  2. 由于个人原因(如修复bug)导致未能完成任务,获得的任务分每拖延一天乘以70%(若修复bug不影响其他工作,不扣分);
  3. 对于用户发现,且未事先进行说明的bug,视严重程度给予相应开发人员扣分,此扣分和第3条相互独立,可以叠加。
    用户发现bug扣分参考:
总扣分 严重程度
0 不注意就不会发现的问题,给予警告
5 一般功能性问题,局部影响用户使用
10 严重影响用户使用
20 相当严重的问题,甚至对接下来的开发造成影响

1.3 发现bug得分

发现影响用户使用的bug,第一发现者可获得5分奖励(不能是自己负责的功能)。

2. 最终贡献分

通过3中的计算方法,可以得到每名成员的得分,我们根据每名成员的得分比例分配最终的贡献分。
公式表达如下:

假设第x名成员得分为Ax
成员x贡献分 = Ax / ∑A * (6 * 50)

posted @ 2017-11-30 01:20  hotcode5  阅读(172)  评论(0编辑  收藏  举报