[T.8] 团队项目：团队贡献分分配规则

[T.8] 团队项目：团队贡献分分配规则

项目	内容
这个作业属于哪个课程	2026年春季软件工程
这个作业的要求在哪里	[T.8] 团队项目：团队贡献分分配规则
我在这个课程的目标是	接触理解应用现代软件工程常用的开发方式，锻炼自己编写代码以及团队协作的能力
这个作业在哪个具体方面帮助我实现目标	说明团队贡献分分配方法

Part 0 前期调研、分配原则与协商方案

前期调研

在开会协商讨论前，我们阅读了课程组提供的博客文章。经过初步讨论，我们认为，一套好的分配规则应当具备以下特征：

• 客观可量化：评分标准尽量可被观测，减少主观争议；
• 激励导向：鼓励主动承担、高质量交付；
• 公平兜底：基础分保障每个按时完成本职工作的成员获得合理回报；
• 责任约束：对于长期不响应、不交付或交付质量明显不达标的情况，应当有明确的扣分机制，避免实际工作压力转嫁给其他成员。

分配原则

• 个人分数由基础分 + 贡献加分组成，成员总分上限为 100 分
• 基础分占 40 分，所有按正常流程参与项目并完成本职工作的成员均可获得
• 若成员出现未按要求参与项目、长期不响应、无合理原因拖延任务、交付结果明显不可用等情况，将从基础分中进行量化扣分
• 被扣除的基础分不直接作废，而是进入贡献加分池，由实际承担工作并推动项目完成的成员按贡献点数比例分配
• 初始贡献加分池共 70 分，在项目结束时，按每位成员累积的贡献点数占团队总点数的比例进行加权分配
• 贡献点数在项目过程中持续累积，评估维度包括以下四个方面（详见 Part 1）
• AIGC 工作评估立场：不区分产出是否借助 AI 工具，只按最终交付结果进行验收与评价（详见 Part 2）

协商方案

每位成员在会议前完成以下准备工作：

• 阅读课程组对贡献分分配的基本要求，理解评估目的
• 思考本团队在哪些维度上容易出现贡献不均衡的情况
• 思考团队成员出现任务拖延、沟通失联、低质量交付等情况时，应如何进行记录和处理

---

Part 1 开会表决

基础分与贡献加分比例表决

大家一致同意使用基础分为 40 分，团队贡献加分初始共计为 70 分的比例。

同时，考虑到项目推进过程中可能出现实际贡献与前期预期不一致的情况，大家一致同意：基础分并非完全无条件获得。若成员在项目过程中长期未能有效参与、未完成分配任务，或交付成果明显无法使用，则应根据实际情况扣除部分基础分。被扣除的基础分进入贡献加分池，用于补偿实际承担额外工作的成员。

基础分扣分规则

每位成员基础分初始为 40 分。若出现以下情况，将按照记录进行扣分：

情况	扣分
无合理原因未按 deadline 完成自己负责的任务，或到 deadline 才提交明显无法使用、需要他人基本重做的成果	-5 分 / 次
对团队消息、任务确认、进度询问长时间不响应，影响项目推进	-3 分 / 次
口头或文字承诺完成任务，但多次未实际推进或未按承诺时间交付	-5 分 / 次
分配到任务后长期没有任何有效产出，最终主要由他人代为完成	-10 分 / 项
在整个项目周期中几乎没有可确认的有效贡献	基础分可酌情扣至 0 分

扣分应尽量依据群聊记录、会议记录、提交记录、仓库记录或实际产物进行认定，避免完全凭主观印象判断。
若成员存在合理原因，例如身体原因、课程冲突、临时突发情况等，应提前向团队说明，并由团队协商是否调整任务或不进行扣分。

贡献点数累积规则

贡献点数在整个项目周期内动态累积，最终点数决定每人从贡献加分池中获得多少分。具体的加分维度如下：

维度一：按时完成任务

表现	贡献点数
在 deadline（通常是例会） 前完成自己负责的任务，质量达标	+2 点
例会上大家认为完成质量良好	+3 点
未按时完成（无合理原因）	+0 点

维度二：承担了他人的任务

表现	贡献点数
在他人无法完成时主动接手其部分或全部任务	+3 点 / 次
接手任务后保质保量交付	额外 +1 点

此类情况需在群内或会议中有明确记录，避免事后争议。

维度三：公认承担了较多工作量

• 重大迭代结束时，由全体成员无记名投票，票选出本迭代中工作量明显高于平均水平的成员（可多选，但需超过半数成员认可）
• 被认可者获得 +3 点

维度四：为团队提供突破性贡献

• 在项目过程中，提出或实现了显著推进项目进度的关键方案、解决了卡住团队的技术难题，或带来了明显的效率提升
• 由全体成员在项目结束时投票认定，获得过半数支持即可获得 +5 点
• 每人在整个项目中最多获得一次此加分

最终分配公式

设七位成员在项目结束时各自累积的贡献点数为：

x_1, x_2, ..., x_7

设第 i 名成员被扣除的基础分为 d_i，其中：

0 <= d_i <= 40

则第 i 名成员的实际基础分为：

base_i = 40 - d_i

设全队被扣除的基础分总和为 D_sum，则：

D_sum = d_1 + d_2 + ... + d_7

贡献加分池初始总分为 70 分。被扣除的基础分进入贡献加分池后，实际贡献加分池为 R_pool，则：

R_pool = 70 + D_sum

设第 i 名成员的贡献加分为 bonus_i，则：

bonus_i = x_i / (x_1 + x_2 + ... + x_7) × R_pool

每人最终得分为：

score_i = base_i + bonus_i

也就是：

score_i = 40 - d_i + x_i / (x_1 + x_2 + ... + x_7) × (70 + d_1 + d_2 + ... + d_7)

若根据公式计算出的个人最终得分超过 100 分，则按 100 分计。

---

Part 2 AIGC 工作的工作量评估与产物验收

我们的主张是：不区分某项工作是否借助了 AIGC 完成，只按最终交付的结果进行评价。

理由如下：

1. 难以公平界定“AI 占比”：无论是代码、文档还是设计稿，借助 AI 的程度难以界定，对于成员是否使用 AI 也没有检验手段。
2. 工具使用本身也是能力：能够有效利用 AIGC 工具、识别其输出的错误、进行合理的 prompt 设计与结果校验，本身就是有价值的工程能力。
3. 项目评价应以结果为导向：软件工程项目最终关注的是团队能否按时交付可运行、可展示、可维护的成果。只要成员提交的成果质量达标，并实际推动了项目进展，就应被视为有效贡献。
4. 低质量产出不能因“花费时间”而获得额外认可：如果某项工作虽然耗费了时间，但最终成果无法使用，仍需要其他成员重新完成，则不应仅因其曾经尝试而获得与有效交付相同的评价。

因此，对于代码、文档、策划、美术、展示材料等各类任务，我们统一采用以下标准：

• 是否按时交付；
• 是否满足团队当前需求；
• 是否能够直接用于项目推进；
• 是否需要他人大量返工；
• 是否在沟通中及时响应并配合修改。

无论是否使用 AIGC，只要最终产物质量达标，就按照正常贡献进行评价；若最终产物明显不可用，或因拖延、失联、低质量交付导致其他成员额外承担工作，则按照基础分扣分规则和贡献点数加分规则进行处理。