Meegle 贡献统计口径

用途：基于 Meegle 的需求、任务、流程节点、Bug 数据，统计一段周期内不同职能人员的参与情况、工作量、交付节奏与质量结果。

边界：本文档只定义事实统计口径，不做 OKR 评分，不直接作为绩效评价或排名结论。

当前周期数据源：Tools 视图 hX6CV91vg、Box 视图 zA5UVrJDR。

全员快速入口：docs/rules/Meegle岗位操作规范.md。本文更适合需要复核公式、异常代码和统计口径的人阅读。

一、目标与边界

1.1 统计目标

本统计用于回答以下问题：

1. 本周期每个人参与了多少需求、承担了多少任务、对应多少预估工期。
2. 每个需求下不同职能分别承担了哪些任务，工作量如何分布。
3. 需求、流程节点、任务是否按预估节奏推进，是否存在延期。
4. 开发人员交付后产生了多少有效 Bug，Bug 等级如何，质量风险如何。
5. 测试人员提交了多少 Bug，其中有效 Bug 占比如何，测试发现质量如何。
6. 产品、UI 设计、开发、测试等职能在项目推进中分别贡献了什么。

1.2 不做的事情

• 不计算 OKR 得分。
• 不给个人生成绩效结论。
• 不在字段不完整时强行判断延期或质量责任。
• 不把单一指标直接等同于贡献大小。

1.3 设计原则

所有统计结果必须能回溯到原始 Meegle 数据：

Story -> Workflow Node -> Task / Bug -> Person -> Role Metrics

统计优先使用结构化字段；字段缺失时可使用代理口径，但必须在报告中标注。

二、统计范围与数据源

2.1 统计周期

统计周期由运行参数显式指定，例如：

2026-05

所有需求、任务、Bug、节点时间均以统计周期为过滤窗口。若具体字段不足以按时间过滤，可先按指定 Meegle 视图快照作为周期集合。

2.2 数据源

2.3 统计对象

三、基础数据模型

3.1 Story

Story 是需求统计的基础单位。

建议保留字段：

3.2 Workflow Node

流程节点用于统计不同职能的阶段性贡献与节奏。

建议保留字段：

3.3 Task

Task 是个人工作量统计的主要单位。

建议保留字段：

3.4 Bug

Bug 用于统计开发质量与测试发现质量。

建议保留字段：

四、人员与角色归属规则

4.1 角色归一

同一个人可拥有多个职能，报告中应允许多角色展示。

4.2 关联需求数

满足任一条件，即认为人员关联该需求：

1. 是 Story 角色成员。
2. 是任一流程节点负责人。
3. 是该 Story 下任一 Task 的负责人。
4. 是该 Story 下任一 Bug 的 Owner 或 Reporter。

关联需求数 = Count(Distinct Story where person appears in role/node/task/bug)

4.3 主责需求数

人员在对应职能主责位置出现，才计入主责需求。

主责需求数 = Count(Distinct Story where person is owner of role-specific responsibility)

4.4 有效参与需求数

人员在需求下存在可执行行为，才计入有效参与：

1. 有本人负责的 Task。
2. 有本人负责的流程节点。
3. 有本人提交或负责的 Bug。

有效参与需求数 = Count(Distinct Story where person owns task/node/bug action)

五、工作量统计

5.1 任务数量

个人任务数 = Count(Task where task.owner = person)

任务必须归属到明确负责人。负责人为空的任务应单独进入数据异常列表。

5.2 任务预估工期

优先使用 Task 上的 PD / 预估工期字段。

个人总预估工期 = Sum(Task.estimated_duration where task.owner = person)

若预估工期为空：

1. 该任务不计入预估工期分母。
2. 报告中单列“缺预估工期任务数”。
3. 不建议默认按 1 计入，避免扭曲工作量。

5.3 已完成工期

个人已完成预估工期 = Sum(Task.estimated_duration where task.owner = person and task is completed)

任务完成状态包括：

Completed / Done / 已完成

5.4 任务完成率

任务完成率 = 已完成任务数 / 个人任务数 × 100%

5.5 工期完成率

工期完成率 = 个人已完成预估工期 / 个人总预估工期 × 100%

相比任务完成率，工期完成率更能反映工作量完成情况。

5.6 需求总估分

需求总估分以需求下所有任务的预估工期汇总。

需求总估分 = Sum(Task.estimated_duration where task.story_id = story.id)

若后续补充 Story Point 字段，则可同时保留：

需求故事点 = Story.story_points
需求任务估时 = Sum(Task.estimated_duration)

两者含义不同，不应混用。

5.7 个人在需求内的工作量占比

个人需求工作量 = Sum(Task.estimated_duration where task.owner = person and task.story_id = story.id)

个人需求贡献占比 = 个人需求工作量 / 需求总估分 × 100%

该指标用于展示多人协作需求中的工作量分布。

六、时间与延期统计

6.1 Story 开始时间

Story 开始时间按以下优先级取值：

1. Story 明确填写的开始时间。
2. 首个有效流程节点的 actual_begin_time。
3. 首个任务提交时间。
4. Story 创建时间。

若以上字段均不存在，则 Story 开始时间不可判定。

6.2 Story 预估结束时间

Story 预估结束时间按以下优先级取值：

1. Story 明确填写的计划 / 预估结束时间。
2. 流程节点中最晚的 estimate_finish_time。
3. 子任务中最晚的预估完成时间。

若以上字段均不存在，则 Story 是否延期不可判定。

6.3 Story 实际完成时间

Story 实际完成时间按以下优先级取值：

1. 已完成 / Done / Launched 节点的 actual_finish_time。
2. Story Completion date。
3. 产品验收节点完成时间。
4. 最后一个完成任务的完成时间。

6.4 Story 按时完成判定

已完成 Story：

若 Story 实际完成时间 <= Story 预估结束时间，则按时完成
若 Story 实际完成时间 > Story 预估结束时间，则延期完成

未完成 Story：

若当前时间 <= Story 预估结束时间，则进行中未延期
若当前时间 > Story 预估结束时间，则当前已延期

缺少预估结束时间或实际完成时间时：

是否可判定延期 = false
延期状态 = 不可判定

6.5 节点延期判定

满足任一条件，即认为节点延期：

1. node.is_delayed = true
2. node.actual_finish_time > node.estimate_finish_time
3. 节点未完成且当前时间大于 node.estimate_finish_time

6.6 任务延期判定

任务必须同时有预估完成时间和实际完成时间，才可判断是否延期。

任务延期 = task.finish_time > task.estimated_finish_time

若只有预估工期而没有预估完成时间，不判断任务延期，只统计工作量。

七、Bug 统计口径

7.1 Bug 有效性

Bug 有效性按以下优先级判定：

1. 若存在结构化字段 Bug 有效性，直接使用字段值。
2. 否则使用最终状态代理。
3. 否则使用缺陷分类、标题、描述关键词辅助判断。

状态代理规则：

7.2 无效 Bug 类型

满足任一条件，可归为无效 Bug：

7.3 开发 Bug 数

开发负责 Bug 数 = Count(Bug where bug.owner = developer)
开发有效 Bug 数 = Count(Bug where bug.owner = developer and bug.validity = 有效)
开发无效 Bug 数 = Count(Bug where bug.owner = developer and bug.validity = 无效)
开发未结案 Bug 数 = Count(Bug where bug.owner = developer and bug.validity = 未结案)

7.4 Bug 等级分布

按 Meegle 字段中已有的严重程度或优先级分组。

Bug 等级分布 = Count(Bug by severity / priority)

如果同时存在严重程度与优先级，优先使用严重程度统计质量风险，优先级作为处理顺序参考。

7.5 开发 Bug 率

开发 Bug 率 = 开发有效 Bug 数 / 开发个人总预估工期

当开发个人总预估工期为 0 或缺失时，该指标不可计算。

7.6 加权开发 Bug 率

为体现高等级 Bug 的风险差异，建议保留加权口径：

加权有效 Bug 数 = Σ 有效 Bug 等级权重
加权开发 Bug 率 = 加权有效 Bug 数 / 开发个人总预估工期

建议默认权重：

7.7 测试提交 Bug 数

测试提交 Bug 数 = Count(Bug where bug.reporter = tester)
测试提交有效 Bug 数 = Count(Bug where bug.reporter = tester and bug.validity = 有效)
测试提交无效 Bug 数 = Count(Bug where bug.reporter = tester and bug.validity = 无效)
测试提交未结案 Bug 数 = Count(Bug where bug.reporter = tester and bug.validity = 未结案)

7.8 测试有效 Bug 率

测试有效 Bug 率 = 测试提交有效 Bug 数 / (测试提交有效 Bug 数 + 测试提交无效 Bug 数) × 100%

未结案 Bug 不进入分母，但应单独展示。

7.9 测试无效 Bug 率

测试无效 Bug 率 = 测试提交无效 Bug 数 / (测试提交有效 Bug 数 + 测试提交无效 Bug 数) × 100%

八、职能贡献指标

8.1 开发

8.2 测试

8.3 产品

产品贡献重点统计需求定义质量、推进节奏与验收闭环。

8.4 UI 设计

UI 贡献重点统计设计交付、设计覆盖与设计返工。

8.5 项目负责人

项目负责人重点查看整体节奏、跨职能协同和风险。

九、项目节奏统计

9.1 需求阶段分布

按当前状态或当前节点归类：

未开始 / PRD 中 / UI 中 / 开发中 / 测试中 / 验收中 / 待发布 / 已完成

9.2 阶段停留时长

节点停留时长 = node.actual_finish_time - node.actual_begin_time

未完成节点：

当前停留时长 = 当前时间 - node.actual_begin_time

9.3 需求周期

需求周期 = Story 实际完成时间 - Story 开始时间

未完成需求可统计当前已流转时长。

9.4 项目节奏异常

建议定义以下异常：

异常项必须保留来源实体，至少包含：

异常代码、级别、原因、来源实体类型、来源实体 ID、来源名称、相关负责人、影响指标组

异常缺失不是绩效扣分项，而是说明该指标是否可判定、是否试算、是否能回溯到 Meegle 原始记录。

十、输出报表结构

10.1 项目总览报告

建议输出：

1. 统计周期与数据源。
2. 需求总数、完成数、延期数、风险数。
3. 阶段分布。
4. 职能工作量分布。
5. Top 风险需求。

10.2 职能汇总报告

建议按职能输出：

不同职能的质量指标不同：

10.3 人员贡献报告

建议每人一行：

10.4 需求明细报告

建议每个需求输出：

1. Story 基本信息。
2. 需求总估分。
3. 各职能参与人。
4. 各人员任务与预估工期。
5. 节点开始 / 结束 / 延期情况。
6. 关联 Bug 与有效性。
7. 当前风险与异常。

十一、数据缺口与置信度

11.1 必要字段

11.2 数据置信度

每个报告建议输出数据置信度：

数据置信度 = 已具备关键字段数 / 应具备关键字段数

可按模块分别计算：

字段缺失较多时，报告应标记为“试算”，不建议用于正式排名。

十二、公开岗位操作规范

公开规则用于让不同岗位提前知道哪些 Meegle 行为会进入统计：

没有进入 Meegle 的工作，不参与自动统计；
字段不完整的工作，只能试算或不可判定；
每个指标必须能回溯到 Story / Node / Task / Bug。

12.1 产品

产品负责把需求定义清楚、推进评审、确认开发前准备、完成产品验收。

必须维护：

• Story 的 PM / Owner、优先级、预估开始时间、预估结束时间。
• 需求背景、需求目标、需求范围、验收标准。
• PRD评审 节点负责人、计划完成时间、实际完成状态。
• 开发开始前确认 UI、开发、QA 角色齐全，Task 已拆分且具备负责人和 PD。
• 需求变更原因、影响范围、是否影响排期。
• 产品验收 节点负责人、验收结论、实际完成状态。

统计指标：

负责需求数
负责需求总估分
PRD 完备率
开发前准备完成率
产品验收完成率
开发后需求变更率
需求不清返工数
负责需求延期 / 风险数

12.2 UI 设计

UI 负责让设计交付、设计覆盖和设计返工可追踪。

必须维护：

• Story 的 UI&UX 负责人。
• UI 设计、切图、标注、走查等 Task，并填写负责人、PD、状态。
• UI设计 和 UI验收 节点的负责人、计划完成时间、实际完成状态。
• UI 走查问题、设计返工原因和影响范围。

统计指标：

UI 参与需求数
UI 任务数
UI 预估工期
UI 节点完成率
开发前 UI 完成率
UI 验收完成率
UI 走查问题数
设计返工问题数

12.3 开发

开发负责让实现工作、完成状态和质量问题可追踪。

必须维护：

• 按端、模块、功能拆分 Task。
• Task 的负责人、PD、所属 Story、所属节点、状态、完成时间。
• 对应开发节点的开始、完成和延期状态。
• Bug Owner、修复状态、非代码问题的根因或无效原因。

开发质量主口径：

基础开发 Bug 密度 = 开发有效 Bug 数 / 已完成开发 PD
加权开发 Bug 密度 = Σ(有效 Bug × 等级权重) / 已完成开发 PD
逃逸 Bug 密度 = 验收后或线上有效 Bug 数 / 已完成开发 PD

旧口径 有效 Bug 数 / 总预估工期 可保留为试算指标，但不作为主解释口径。

12.4 测试

测试负责让发现质量、复测结果和 Bug 闭环可追踪。

必须维护：

• Story 的 QA 负责人。
• 测试计划、用例执行、回归测试等 Task，并填写负责人、PD、状态。
• Bug 的关联 Story、Reporter、Owner、等级、复现步骤、有效性、关闭原因。
• 复测结果和关闭状态。

统计指标：

测试参与需求数
测试任务数
测试预估工期
测试节点完成率
提交 Bug 数
测试有效率 / 无效率
高等级有效 Bug 数
未结案 Bug 数
复测闭环率

12.5 项目负责人

项目负责人负责流程完整度、风险暴露和跨职能卡点推进。

必须每周检查：

• Story 是否缺 PM、UI、开发、QA。
• Story、节点、Task 是否缺计划时间。
• Task 是否缺负责人、PD、状态。
• Bug 是否未关联 Story，是否缺 Owner、Reporter、等级、有效性、关闭原因。
• 是否存在长期未结案 Bug、长期停留节点、延期但无风险说明的需求。

统计指标：

需求总数
已完成需求数
延期需求数
风险需求数
长期卡点需求数
字段完整率
风险关闭率
跨职能阻塞数

十三、排名与解释原则

本文档不定义绩效排名，但可支持工作量和贡献对比。

如果后续需要排序，建议：

1. 先按职能分别排序，再考虑全员归一化对比。
2. 工作量、完成率、质量、节奏必须同时展示。
3. 排序结果必须支持回溯到 Story、Task、Bug 明细。
4. 对数据缺失较多的人员，不应与字段完整人员直接比较。
5. 排名旁必须展示异常和置信度，避免单一数字误导。

*文档版本：v0.2 · 目标：替代 OKR 评估口径，作为 Meegle 贡献统计重构的统一口径 · 更新日期：2026-05-31*