团队成员贡献分分配规则

##1. 得分来源

1.1 对开发而言

任务量（暂时以预定时间为参考，如果实际和预定有出入，需指明原因，判断是个人因素还是任务预估有问题）

难度（开发的不确定因素量以及学习成本，通俗理解就是坑会不会很多，处理这些坑要花多少额外时间）

1.2 对测试而言

任务量（撰写测试代码所需时间）

难度（要完成该项测试需要学习哪些知识，难度怎样）

1.3 对PM而言

任务量（撰写历次博客所需时间）

1.4 扣分

用户每反馈一个bug，视严重程度，测试和负责这一块开发的开发人员各扣除一定的分数。

2. 制定中的一些思路

Q:如何衡量每一个任务对团队的贡献？

A:我认为最好的方法是用预估时长表示，每1h的任务价值为10分。

Q:如果一个任务的实际用时超过了预估时长怎么办？

A:需要说明难点，具体在哪里花费了大量时间，并说明各部分花费时间的比例，根据实际情况决定是否提高该任务的贡献值。

Q:如何保证任务按时完成？

A:领取任务的时候需提供一个预期完成时间，任务完成后立即领取新的任务。

Q:完成同一个任务，不同人带来的效果可能是不同的，如何给完成得好的同学以更高的奖励呢？

A:对于测试发现的bug，不得因为修复bug影响其他任务的预期完成时间，如果在发布前仍未处理bug或影响了其他任务的正常进行，则需要扣分。除此之外还应当考虑到完成度的问题，要给完成得更完美的同学多一些奖励。

Q:如果有bug被用户发现怎么办？

A:如果是测试人员的职责范围内，则测试和开发都要承担一定责任。

Q:对其他同学代码的优化，这部分贡献如何处理？

A:根据优化的效果，给予一定奖励。

3. 得分细则

3.1 任务完成得分

L=任务量（10~80）：所需时间

D1=预期难度系数（0、1、2）：由于难度产生的时间变数，由之前会议商讨决定，遇到坑的时候及时在群里求助

D2=实际难度系数（0、1、2）

任务量和难度系数在会议讨论的时候决定

E1=完成度自评（0~1）

E2=完成度PM评价（0~1）

下面是评价部分（E1、E2）的评定参考：

评价成绩	效果
60%	基本完成功能，但是很简陋，部分细节未能达到预期要求
80%	完成得一般，要求的功能都实现了，但是还有优化的空间
100%	完美完成，无可挑剔

最终的得分要根据完成度、任务量和难度三方面评定，即

任务完成得分 = ((E1+E2)*0.5*) * L * (1+(D1+D2)*0.25)

举例：

A君接了一个任务量为60，预期难度系数为1的任务，但是在实际编码中发现这里面的坑比想象中的要大许多，经过和PM商议，将实际难度系数设置为2。

由于要赶在DDL之前提交任务，做得比较仓促，虽然要求确实都满足了，但是还欠缺完美，自评和PM评价都为80%，那么A君的最终得分为：

((0.8+0.8) * 0.5 * 60 * (1 + (1+2) * 0.25)) = 84

3.2 任务遇到问题：

遇到了非常大的坑，在群里询问以及向PM汇报之后仍未解决，可以申请延期或暂时不实现相关功能，按当前完成度给予一定分数；

在领取任务后，临时有事，无法完成个人任务，第一次无法获得任务分，第二次不仅无法获得任务分，反而要扣除该任务任务量的30%分数作为惩罚；

由于修复测试bug导致任务延期，获得的任务分每延期一天乘以70%（若修复bug不影响其他工作，不扣分）；

对于用户发现且测试没有发现的bug，视严重程度给予扣分，此扣分和第3条相互独立，可以叠加。

用户发现bug扣分参考：

总扣分	严重程度
0	不注意就不会发现的问题，给予警告
10	一般功能性问题，局部影响用户使用
20	严重影响用户使用
40	相当严重的问题，甚至对接下来的开发造成影响

对于上表中的扣分，测试扣除60%的分数，开发扣除40%的分数。

3.3 对其他功能的优化得分：

优化属于额外工作，不能影响自己的本职任务，否则不予奖励。

评价（0~1）：综合考虑改进程度、是否有实质性用处

评价分	效果
20%	进行了细微的调整，稍微提升了用户体验
40%	进行了部分调整，大幅度改进了用户体验
60%	修复了原版的功能问题
100%	解决了重大漏洞，化解了一场可能的危机