团队个人贡献分分配规则
概述
最近比较流行OKR，即目标与关键成果法，这是一种定义和跟踪目标及其完成情况的管理工具和方法。在执行上和GitHub的Issues比较相似，正好符合我们团队的管理方式，可以较好地进行实践。目前任务贡献核定遇到了几个问题：
1. 优先级中包含了顺序因素：实际上优先级可以反映任务的轻重缓急，也就是任务的**难度**和**紧急度**，但是由于在优先级中加入了任务间的顺序因素，无法很好地反映以上两点。比如，`吃饭喝水`和`上厕所`在一天的生活中都是十分重要的，优先级应该基本一致，但是由于加入了顺序因素，`吃饭喝水`的优先级肯定是高于`上厕所`的。如果需要进行公平的贡献评定需要分割每个因素，也就是用不同指标标注任务的`难度`、`紧急度`、`预估时长`以及`关联任务执行顺序`，由于指标较多，制定每个任务的指标将变得异常麻烦。
2. 预计时长估计困难：由于对各个同学的个人实力不是很了解，而且很多情况无法指定量化详细的指标，每个人实际工作时长和预估时长差异较大，任务成果质量和预估时长的工作量不符合。并且有些人可能会刻意谎报任务时长，造成贡献评定中对时间的因素的核定无解。目前只能默认各个组员是在诚实的情况下反馈工作时长。
3. 任务评价中PM个人倾向影响较大：团队其它组员和PM没有上下级隶属关系，而大部分任务质量的评价就好像语文问答题一样，是一项相对开放的问题，其它组员对PM主观评价可能会出现较大的争议。但是暂时没有更好的客观评价方式，如果对每一个任务进行**选择题**般精确的指标指定是不可能的，一是PM对每个执行者的执行细节不是完全了解；二来这样做工程量巨大，需要花大量时间调研，极可能比任务的执行还要慢很多。
在参考前序团队的团队贡献分配计划后，以三个因素来评定团队贡献值，即工作成果评分、实际工作量（时长和编码量、难度等综合商定）和完成系数，这样较为客观地从各个方面反映了每个阶段任务完成情况。
评定方式
计算公式
Issue评分 = ((Issue个人评分×0.4+IssuePM评分×0.6)×0.5+(周个人计划工作量/周团队实际工作量)×0.5)×完成系数
参数解读
- Issue个人评分：对自己Issue完成结果的评分，范围为0~1。
- IssuePM评分：PM对执行人Issue完成结果的评分，范围为0~1。
- 周个人计划工作量：每周为一个评分阶段，即这一周的个人计划工作量。
- 周团队实际工作量：每周为一个评分阶段，即这一周的团队工作总量。
- 完成系数：任务进度检查时完成的百分比。
注：这里由于每天都有且只有一个任务，实际上任务布置的先后顺序基本与任务优先级一致，因此优先级在这里效果不明显，不予采用。
这也是与前序团队不一样的地方。
总贡献计算
每周结束为Issue评分时刻，也就是说整个软工工作周期一共有8个评分时刻，每个人的Issue评分会进行累积。目前团队有5个人，也就是总共有250分的团队贡献总分，α和β阶段分别占125分，每个阶段的贡献值=125×(个人Issue累积评分/团队Issue累积评分)。最后将两个阶段的贡献值加合便是整个软工项目的团队贡献总值。
Issue制定Tips
- 发布频率：每2天制定发布一次团队Issue。
- 标签制定：目前Issue有3个任务标签，分别是
size、priority和deadline。size即工作量，分5个级别，deadline是截止时间，一般为两天后。发布Issue后，如有异议，执行者在12小时之内对PM进行反馈，过时无效。 - 任务详情制定：任务详情是执行Issue的概述纲领，需要仔细阅读。发布Issue后，如有异议，执行者在12小时之内对PM进行反馈，过时无效。
