团队贡献分分配规则
1.得分参考
在看过绩效管理部分的章节后，我们认为贡献度 = 工作量 × 工作的影响力 × 工作的不可替代性很具有参考价值。在讨论过后，我们找到了量化工作量，工作影响力，以及工作的不可替代性的一些指标。
以完成时间来衡量工作量，对于前端来说，“某个功能”指的是做完某个页面。而对于后端来说，则是具体到每一个接口的实现。对于测试组来说，则是完成对某一项功能的测试完成，并且反馈给开发组。
以完成度来衡量工作的影响力。完成度有两个影响指标，测试组在对功能进行测试的时候找出了BUG并且将其反馈给开发组，那么修复这些BUG所要花费的时间便是第一个指标。第二个指标则是对项目进度的影响。
以难度来衡量工作的额不可替代性。在开例会的时候确定各项任务的难度。
2.得分细则
团队中每个人的基本分为50。
难度评分：
| 难度等级 | 描述 | 分值 |
|---|---|---|
| A | 十分简单，不需要太大的思考便能完成 | +1 |
| B | 功能较为复杂，实现起来需要一定的思考 | +2 |
| C | 功能复杂，需要反复尝试才能实现 | +3 |
| D | 没有人有这方面的经验，需要花费长时间学习新东西 | +4 |
| E | 功能十分复杂，需要一些其他成员没有掌握的专业知识，例如重构数据库 | +5 |
具体每项任务的难度由每日例会讨论决定，如果在例会讨论的时候错误估计了任务的难度，在与PM沟通过后可以适当增加难度等级。
完成度评分：
在测试组测试完成之后，向开发组报告所有发现的BUG。从报告BUG之日开始，到修改完毕某功能所有BUG之日截止。每多过半日，便-1分。如果需要花费3天以上修改功能的BUG，并且没有用正当的理由与PM说明拖延的原因，则认定该成员因个人原因而导致项目的整体拖延，则额外减分。
其他评分：
对于PM来说：每有一次没有按时完成博客则-1分，每帮助一次开发组或者测试组完成任务则+1分。
对于测试组来说：在测试完所有BUG之后，获得额外的5分。若测试阶段完成之后，用户或者团队其他成员每发现一次新的BUG，则-1分。