Meegle 任务创建和管理建议

目的：让所有成员按照统一方式创建、拆分、维护 Meegle 需求、任务和 Bug，保证贡献统计过程尽量公平、公开、公正。

适用对象：产品、UI 设计、开发、测试、项目负责人。

适用范围：基于 Meegle Story、流程节点、Task、Bug 的项目贡献统计。

全员快速入口：docs/rules/Meegle岗位操作规范.md。如果只想确认自己岗位怎么做，优先阅读该文档。

一、统计原则

本项目的贡献统计只基于 Meegle 中可追溯的数据，不做主观评分，也不直接输出绩效排名。

统计过程遵循三个原则：

公平：同一类角色使用同一套统计口径，缺字段时不强行推断。
公开：每个指标都能回溯到具体需求、任务、节点或 Bug。
公正：只统计 Meegle 中实际存在的数据，不用口头描述替代系统记录。

因此，大家在 Meegle 中填写得越完整，统计结果越准确；字段缺失时，系统会标记为“不可判定”或“试算”。

二、系统如何计算

2.1 基础数据来源

统计系统主要读取以下对象：

对象	用途
Story / 需求	判断参与需求数、需求状态、需求总工作量
流程节点	判断产品、UI、开发、测试等阶段推进情况
Task / 任务	统计个人任务数、预估工期、完成工期
Bug / 缺陷	统计开发质量和测试发现质量
角色成员	判断产品、UI、开发、测试等职能归属

2.2 人员贡献如何归属

只要一个人出现在以下任一位置，就会和该需求产生关联：

Story 角色成员，例如 PM、Owner、UI&UX、Android、iOS、Server、Web、QA。
流程节点负责人。
Task 负责人。
Bug Owner。
Bug Reporter。

系统会区分三类需求数：

指标	含义
关联需求	只要人在需求中出现过，就计入
主责需求	人在对应职能主责位置出现，才计入
有效参与需求	人在需求下有节点、任务、Bug 等实际行为，才计入

2.3 工作量如何计算

工作量主要来自 Task 的 PD / 预估工期。

个人总预估工期 = 本人负责的所有 Task 的 PD 之和
个人已完成工期 = 本人已完成 Task 的 PD 之和
工期完成率 = 个人已完成工期 / 个人总预估工期
需求总估分 = 需求下所有 Task 的 PD 之和

如果 Task 没有填写 PD，系统不会默认按 1 计算，而是标记为“缺预估工期”。这样可以避免因为默认值导致工作量被高估或低估。

2.4 延期如何判断

延期判断依赖明确的计划时间和实际完成时间。

层级	判断依据
Story	预估结束时间 vs 实际完成时间
流程节点	节点预估完成时间 / `is_delayed` / 实际完成时间
Task	任务预估完成时间 vs 任务完成时间

如果没有预估结束时间，系统会输出“不可判定”，不会强行认定延期或按时。

2.5 Bug 如何计算

开发维度：

开发有效 Bug 数 = Owner 为该开发且有效的 Bug 数
开发 Bug 率 = 开发有效 Bug 数 / 该开发总预估工期

测试维度：

测试提交 Bug 数 = Reporter 为该测试的 Bug 数
测试有效 Bug 率 = 测试提交有效 Bug 数 / 已定性的提交 Bug 数

未结案 Bug 不进入有效率或无效率分母，但会单独展示。

Bug 有效性优先使用结构化字段；没有结构化字段时，系统使用状态代理：

Bug 状态	统计处理
Closed / SOLVED	有效
Refuse / 重复 / 非缺陷 / 无法复现	无效
STARTED / Pending / 挂起	未结案，不进入率分母

2.6 数据置信度如何计算

系统会统计关键字段是否完整，并输出数据置信度。

指标组	关键字段
工作量	Task 负责人、Task PD、Task 状态
排期节奏	Story / 节点 / Task 的计划时间和完成时间
开发质量	Bug Owner、Bug 有效性、Bug 等级
测试质量	Bug Reporter、Bug 有效性

字段越完整，统计结果越可信。

三、所有人都需要遵守的创建规则

3.1 一个独立功能创建一个 Story

一个 Story 应该代表一个可验收、可上线、可追踪的需求单元。

不建议：

多个不相关功能打包成一个 Story。
一个 Story 里混合多个独立上线目标。
只建 Story，不拆任务。

建议：

一个明确业务目标对应一个 Story。
Story 名称说明清楚业务结果。
Story 下拆分产品、UI、开发、测试等实际任务。

3.2 每个 Story 必须维护角色成员

建议至少填写：

角色	说明
PM / Owner	产品或需求负责人
UI&UX	设计负责人，有设计工作时填写
Android / iOS / Server / Web	对应端或服务开发负责人
QA	测试负责人

如果角色不填写，系统可能无法正确识别职能贡献。

3.3 每个任务必须有负责人

Task 必须填写负责人。没有负责人的任务无法归属到个人工作量。

建议：

谁实际执行，负责人就填谁。
多人协作时拆成多个 Task，不要多人共用一个 Task。
任务负责人变更时及时更新。

3.4 每个任务必须填写 PD / 预估工期

PD 是当前工作量统计的核心字段。

建议：

按实际预估工作量填写。
小任务可填写 0.5、1 等小数。
不要为了降低 Bug 率或提高工作量而虚填。
如果任务范围变化，应同步调整 PD，并在评论或描述中说明原因。

3.5 Task 状态必须及时更新

任务完成后应及时改为完成状态。

否则会影响：

任务完成率。
已完成工期。
当前风险判断。
个人工作量闭环情况。

四、各职能操作建议

4.1 产品

产品的统计重点是需求定义质量和推进闭环。

建议操作：

Story 创建后补齐 PM / Owner。
PRD 完成后更新 PRD 完备字段。
需求进入开发前，确认 PRD 已评审并通过。
需求变更时，在 Story 评论或变更记录中说明变更原因。
验收完成后及时推进验收节点。

产品相关统计包括：

负责需求数。
负责需求总估分。
PRD 完备率。
PRD 节点完成情况。
验收完成情况。
需求延期和需求问题返工。

4.2 UI 设计

UI 的统计重点是设计交付、设计覆盖和设计返工。

建议操作：

有设计工作的需求必须填写 UI&UX 负责人。
UI 设计、切图、标注等工作应拆为 Task。
UI Task 必须填写负责人和 PD。
设计完成后及时推进 UI 节点。
UI 走查问题应通过 Bug 或任务记录，避免只在线下沟通。

UI 相关统计包括：

UI 参与需求数。
UI 任务数。
UI 预估工期。
UI 节点完成情况。
UI 走查问题数。
设计返工问题数。

4.3 开发

开发的统计重点是工作量、交付完成和 Bug 质量。

建议操作：

开发工作必须拆 Task，并填写负责人和 PD。
不同端、不同模块建议拆成独立 Task。
Task 完成后及时更新状态。
Bug 修复时确保 Bug Owner 正确。
如果 Bug 并非代码问题，应推动测试或产品标记无效原因。

开发相关统计包括：

参与需求数。
开发任务数。
总预估工期。
已完成工期。
工期完成率。
有效 Bug 数。
Bug 等级分布。
开发 Bug 率。

4.4 测试

测试的统计重点是测试覆盖、Bug 提交质量和闭环。

建议操作：

测试工作应拆 Task，并填写负责人和 PD。
提 Bug 时必须关联对应 Story。
Bug 标题要描述清楚问题现象。
Bug 描述中尽量包含复现步骤、预期结果、实际结果、截图或日志。
重复、环境、需求理解偏差等问题，应及时协助标记为无效原因。
Bug 解决后及时复测并关闭。

测试相关统计包括：

参与需求数。
测试任务数。
测试预估工期。
提交 Bug 数。
提交有效 Bug 数。
测试有效 Bug 率。
测试无效 Bug 率。
未结案 Bug 数。

五、Bug 创建和处理建议

5.1 Bug 必须关联需求

每个 Bug 都应关联到具体 Story。

不关联 Story 的 Bug 会导致：

无法归属到具体需求。
无法统计需求质量。
无法统计开发和测试贡献。

5.2 Bug 必须填写 Owner 和 Reporter

字段	用途
Owner	统计开发负责 Bug
Reporter	统计测试提交 Bug

如果 Owner 或 Reporter 缺失，会降低数据置信度。

5.3 Bug 等级必须准确

Bug 等级会影响质量风险展示。

建议统一理解：

等级	示例
P0 / 危险 / Critical	核心流程不可用、严重数据错误、安全风险
P1 / 严重 / High	重要功能不可用或影响主要路径
P2 / 一般 / Normal	普通功能缺陷，有替代路径
P3 / 轻微 / Low	文案、样式、小体验问题

5.4 无效 Bug 要有明确原因

无效 Bug 不代表“没有价值”，但需要明确原因，避免统计误判。

常见无效原因：

重复提交。
非缺陷。
无法复现。
环境 / 配置 / 网络问题。
操作误解。
需求问题。
设计问题。

六、项目负责人检查清单

项目负责人或模块负责人每周建议检查：

是否存在无负责人 Task。
是否存在无 PD Task。
是否存在未关联 Story 的 Bug。
是否存在缺 Owner / Reporter 的 Bug。
是否存在长期未结案 Bug。
是否存在已进入开发但角色成员不完整的 Story。
是否存在无法判定排期的关键需求。

这些问题不是为了追责，而是为了提高统计结果可信度。

七、公开岗位操作规范

以下规则可以公开给团队执行。统计系统只读取 Meegle 中可回溯的数据，不使用口头同步替代系统记录。

7.1 产品

产品需要保证需求从“想法”变成“可开发、可测试、可验收”的 Meegle 记录。

阶段要求：

阶段	Meegle 操作	影响指标
创建需求	填写 Story 名称、PM / Owner、优先级、预估开始/结束时间	负责需求、排期置信度
PRD 编写	填写背景、目标、范围、验收标准	PRD 完备率、产品准备度
PRD 评审	推进 `PRD评审` 节点，填写负责人和完成状态	PRD 节点完成率、开发前准备完成率
开发前确认	确认 UI、开发、QA 角色齐全，Task 有负责人和 PD	开发前准备完成率、异常 C04/C05/C13
需求变更	在 Story 评论或字段中记录变更原因、影响范围和排期影响	需求变更数、需求不清返工
产品验收	推进 `产品验收` 节点并填写验收结论	产品验收完成率、异常 C15

7.2 UI 设计

UI 需要让设计交付和返工原因可追踪。

阶段要求：

阶段	Meegle 操作	影响指标
接入需求	Story 填写 UI&UX 负责人	UI 参与需求
设计执行	拆 UI 设计、切图、标注、走查 Task，填写负责人和 PD	UI 任务数、UI 预估工期
设计完成	推进 `UI设计` 节点完成状态	UI 节点完成率、开发前 UI 完成率
UI 验收	推进 `UI验收` 节点，记录验收问题	UI 验收完成率、UI 走查问题
设计返工	用 Bug 或 Task 记录返工原因	设计返工问题数

7.3 开发

开发需要让实现工作量、交付状态和质量问题可追踪。

阶段要求：

阶段	Meegle 操作	影响指标
任务拆分	按端、模块、功能拆 Task	开发任务数、需求工作量分布
任务估时	每个 Task 填负责人、PD、所属 Story	总预估工期、Bug 密度分母
开发中	维护开发节点和 Task 状态	工期完成率、异常 C08
开发完成	及时完成 Task 和开发节点	已完成工期、转测节奏
Bug 修复	确认 Bug Owner、修复状态、根因或无效原因	有效 Bug、加权 Bug、未结案 Bug

开发质量主指标使用：

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

7.4 测试

测试需要让问题发现、有效性和复测闭环可追踪。

阶段要求：

阶段	Meegle 操作	影响指标
测试准备	Story 填写 QA，测试计划/用例/回归拆 Task	测试参与需求、测试预估工期
提交 Bug	Bug 关联 Story，填写 Reporter、Owner、等级、复现步骤	提交 Bug 数、等级分布
Bug 定性	补充有效性或无效原因	测试有效率、无效率、异常 C10
复测关闭	复测通过后关闭 Bug	复测闭环率、未结案 Bug

7.5 项目负责人

项目负责人负责让流程可判定、风险可暴露。

每周检查：

检查项	典型异常
Story 是否有 PM / UI / 开发 / QA	C13
Story / 节点是否有预估结束时间	C03
Task 是否有负责人、PD、状态	C04 / C05 / C08
Bug 是否关联 Story	C12
Bug 是否有 Owner、Reporter、等级、有效性、关闭原因	C10 / C11
产品验收是否闭环	C15
已完成需求是否仍有未结案 Bug	C06

八、常见问题

8.1 为什么我的工作没有统计进去？

通常是因为：

Task 没有负责人。
Task 不在对应 Story 下。
Story 角色没有填你。
Bug 没有关联 Story。
Bug Owner / Reporter 没有填对。

8.2 为什么我的工作量是 0？

通常是因为：

Task 没有填写 PD。
你只在节点上出现，但没有实际 Task。
多人共用一个 Task，负责人不是你。

8.3 为什么延期显示“不可判定”？

通常是因为：

Story 没有预估结束时间。
节点没有预估完成时间。
Task 没有预估完成时间。

系统不会在缺字段时强行判断延期。

8.4 为什么 Bug 率显示“试算”？

因为当前 Bug 有效性主要通过状态、分类和关键词代理判断。后续如果 Meegle 中补充结构化“Bug 有效性”字段，统计结果会更准确。

九、推荐填写标准

每个 Story 至少做到：

有明确需求名称。
有 PM / Owner。
有对应开发、测试、UI 角色。
有拆分 Task。
每个 Task 有负责人。
每个 Task 有 PD。
每个 Bug 关联 Story。
每个 Bug 有 Owner、Reporter、状态和等级。

只要大家按这个标准维护 Meegle，贡献统计就能更接近真实情况，也更容易做到公平、公开、公正。

*文档版本：v0.2 · 更新日期：2026-05-31*