Meegle 岗位操作规范
面向全员公开使用。
目的：让每个岗位快速知道自己在 Meegle 里应该填什么、什么时候流转、哪些缺失会影响统计。
边界：本文只说明操作规范和统计影响，不输出 OKR 分数、绩效等级或绩效排名。
0. 所有人必须知道的 5 条规则
- 工作必须进入 Meegle，才进入自动统计。
- Story、Task、Bug 字段不完整时，只能试算或不可判定。
- 每个岗位只统计本岗位可控制、可推进、可回溯的行为。
- 所有指标必须能回溯到具体 Story、Node、Task 或 Bug。
- 异常缺失不是直接扣分项，而是说明数据不完整、状态未流转或流程不可判定。
1. 我该看哪一节？
| 我的岗位 | 优先阅读 | 核心关注 |
|---|---|---|
| 产品 | 2. 产品操作规范 | 需求定义、PRD 评审、开发前准备、产品验收、需求变更 |
| UI 设计 | 3. UI 设计操作规范 | UI 任务、UI 设计节点、开发前 UI 完成、UI 验收、设计返工 |
| 开发 | 4. 开发操作规范 | 开发 Task、PD、完成状态、Bug Owner、修复闭环 |
| 测试 | 5. 测试操作规范 | 测试 Task、Bug Reporter、有效性、复测关闭 |
| 项目负责人 | 6. 项目负责人检查规范 | 角色完整、排期完整、长期卡点、风险闭环 |
| 想看异常含义 | 7. 异常代码速查 | 为什么报告里出现 C03、C04、C10 等 |
| 想确认最低要求 | 8. 最低填写标准 | 一个需求至少要填到什么程度 |
2. 产品操作规范
你负责什么
产品负责把需求从“想法”推进成“可开发、可测试、可验收、可上线”的 Meegle 记录。
你必须在 Meegle 填什么
| 阶段 | 必填 / 必做 | 影响统计 |
|---|---|---|
| 创建 Story | 需求名称、PM / Owner、优先级、预估开始时间、预估结束时间 | 负责需求数、排期置信度、C03 |
| 写 PRD | 需求背景、目标、范围、验收标准 | PRD 完备率、产品准备度、C14 |
| PRD 评审 | PRD评审 节点负责人、计划完成时间、完成状态 | PRD 节点完成率、开发前准备完成率 |
| 开发前确认 | UI、开发、QA 角色齐全，Task 有负责人和 PD | 开发前准备完成率、C04、C05、C13 |
| 需求变更 | 记录变更原因、影响范围、是否影响排期 | 需求变更数、需求不清返工 |
| 产品验收 | 产品验收 节点负责人、验收结论、完成状态 | 产品验收完成率、C15 |
怎么判断自己做对了
- Story 上能看到产品负责人。
- 开发开始前，PRD 评审已完成。
- 验收标准明确，测试和开发能据此判断是否完成。
- 需求变更不是只在群里说，而是在 Story 中留下记录。
- 测试完成后，产品验收节点及时流转。
常见错误
- 只建 Story，不填预估结束时间。
- 需求已经开发，但 PRD 评审节点没有完成。
- 需求变更没有记录，导致延期和返工无法解释。
- 产品验收完成了，但节点没有流转。
3. UI 设计操作规范
你负责什么
UI 负责让设计交付、设计走查和设计返工能被 Meegle 追踪。
你必须在 Meegle 填什么
| 阶段 | 必填 / 必做 | 影响统计 |
|---|---|---|
| 接入需求 | Story 填写 UI&UX 负责人 | UI 参与需求数 |
| 设计执行 | UI 设计、切图、标注、走查拆成 Task | UI 任务数、UI 预估工期 |
| 任务维护 | 每个 UI Task 填负责人、PD、状态 | UI 工作量、C04、C05、C08 |
| 设计完成 | UI设计 节点更新完成状态 | UI 节点完成率、开发前 UI 完成率 |
| UI 验收 | UI验收 节点流转，记录走查问题 | UI 验收完成率、UI 走查问题 |
| 设计返工 | 用 Bug 或 Task 记录返工原因 | 设计返工问题数 |
怎么判断自己做对了
- 有 UI 工作的需求能看到 UI&UX 负责人。
- 设计工作不是只挂在节点上，而是有对应 Task。
- 开发开始前，UI 设计节点已完成或有明确风险说明。
- UI 走查问题有 Bug 或 Task 记录。
常见错误
- UI 已交付，但 UI Task 或 UI 节点没有完成。
- 设计返工只在线下沟通，没有 Meegle 记录。
- 多个设计工作混在一个无 PD 的 Task 里。
4. 开发操作规范
你负责什么
开发负责让实现工作量、交付状态和 Bug 修复过程可追踪。
你必须在 Meegle 填什么
| 阶段 | 必填 / 必做 | 影响统计 |
|---|---|---|
| 任务拆分 | 按端、模块、功能拆 Task | 开发任务数、需求工作量分布 |
| 任务估时 | 每个 Task 填负责人、PD、所属 Story | 总预估工期、Bug 密度分母、C04、C05 |
| 开发中 | 维护 Task 状态和开发节点状态 | 工期完成率、C08 |
| 开发完成 | Task 和开发节点及时完成 | 已完成工期、转测节奏 |
| Bug 修复 | 确认 Bug Owner 是实际修复人 | 开发有效 Bug、未结案 Bug |
| 非代码问题 | 标记根因或推动改为无效原因 | 避免误算开发质量 |
开发质量怎么算
基础开发 Bug 密度 = 开发有效 Bug 数 / 已完成开发 PD
加权开发 Bug 密度 = Σ(有效 Bug × 等级权重) / 已完成开发 PD
逃逸 Bug 密度 = 验收后或线上有效 Bug 数 / 已完成开发 PD旧口径 有效 Bug 数 / 总预估工期 只作为试算参考。
怎么判断自己做对了
- 自己做的工作都有 Task。
- Task 有 PD，完成后状态及时更新。
- Bug Owner 正确，修复后状态及时流转。
- 非代码、需求、设计、环境问题有明确原因，不默认挂在开发质量上。
常见错误
- 多人共用一个 Task，导致工作量归属不公平。
- 完成了但 Task 状态没更新。
- Bug 修复了但状态没有流转。
- 需求变更导致返工，但没有记录变更原因。
5. 测试操作规范
你负责什么
测试负责让问题发现、Bug 有效性和复测关闭可追踪。
你必须在 Meegle 填什么
| 阶段 | 必填 / 必做 | 影响统计 |
|---|---|---|
| 测试准备 | Story 填写 QA 负责人 | 测试参与需求数 |
| 测试执行 | 测试计划、用例执行、回归测试拆 Task | 测试任务数、测试预估工期 |
| 提交 Bug | 关联 Story，填写 Reporter、Owner、等级、复现步骤 | 提交 Bug 数、Bug 等级分布 |
| Bug 定性 | 标记有效性或无效原因 | 测试有效率、无效率、C10 |
| 复测关闭 | 修复后复测并关闭 Bug | 复测闭环率、未结案 Bug、C06、C09 |
怎么判断自己做对了
- Bug 都关联到具体 Story。
- Bug 标题和描述能让开发复现。
- Bug 有 Reporter、Owner、等级、状态。
- 重复、非缺陷、环境问题、无法复现等要有明确无效原因。
- 复测完成后及时关闭。
常见错误
- Bug 没有关联 Story。
- Bug 缺复现步骤或预期结果。
- Bug 已修复但没有复测关闭。
- 无效 Bug 没有原因，导致统计只能试算。
6. 项目负责人检查规范
你负责什么
项目负责人负责让流程可判定、风险可暴露、跨职能卡点可推进。
每周检查清单
| 检查项 | 典型异常 |
|---|---|
| Story 是否有 PM、UI、开发、QA | C13 |
| Story / 节点是否有预估结束时间 | C03 |
| Task 是否有负责人、PD、状态 | C04 / C05 / C08 |
| Bug 是否关联 Story | C12 |
| Bug 是否有 Owner、Reporter、等级、有效性、关闭原因 | C10 / C11 |
| 已完成需求是否还有未结案 Bug | C06 |
| 产品验收是否闭环 | C15 |
| 是否有长期停留节点或延期节点 | C01 / C02 |
怎么判断自己做对了
- 高风险需求能解释风险来自哪个 Story、Node、Task 或 Bug。
- 关键需求不会因为缺预估结束时间而无法判断延期。
- 长期未结案 Bug 和长期停留节点有明确负责人和处理结论。
- 每周能基于异常代码推动字段补齐和状态流转。
7. 异常代码速查
| 代码 | 级别 | 含义 | 常见处理 |
|---|---|---|---|
| C01 | 高 | Story 当前延期 | 更新排期、说明延期原因、推进风险处理 |
| C02 | 高 | 开发 / 测试节点延期 | 检查节点负责人、计划时间和阻塞原因 |
| C03 | 中 | 缺预估结束时间 | 补 Story 或节点计划完成时间 |
| C04 | 中 | Task 缺 PD | 补预估工期 |
| C05 | 中 | Task 缺负责人 | 填实际执行人 |
| C06 | 中 | 已完成 / 即将完成需求存在未结案 Bug | 复测关闭或说明暂不关闭原因 |
| C07 | 低 | 节点负责人存在但无关联 Task | 补 Task 或说明该节点无需 Task |
| C08 | 中 | Task 状态未及时更新 | 完成后更新状态 |
| C09 | 中 | Bug 状态未流转 | 修复、复测或关闭 |
| C10 | 中 | Bug 缺有效性 / 关闭原因 | 补有效性或无效原因 |
| C11 | 中 | Bug 缺等级 | 补严重程度或优先级 |
| C12 | 高 | Bug 未关联 Story | 关联到具体需求 |
| C13 | 中 | Story 角色成员缺失 | 补 PM、UI、开发、QA |
| C14 | 中 | PRD 关键字段缺失 | 补背景、目标、范围、验收标准 |
| C15 | 中 | 产品验收节点未闭环 | 推进产品验收节点 |
8. 最低填写标准
每个 Story 至少做到：
- 有明确需求名称。
- 有 PM / Owner。
- 有预估结束时间。
- 有优先级。
- 有验收标准。
- 有对应 UI、开发、QA 角色；不需要某角色时应说明。
- 有拆分 Task。
- 每个 Task 有负责人、PD、状态。
- 每个 Bug 关联 Story。
- 每个 Bug 有 Reporter、Owner、等级、状态、有效性或关闭原因。
- 需求完成前，产品验收和未结案 Bug 已处理。
只要按这个标准维护 Meegle，贡献统计就能更接近真实情况，也更容易做到公平、公开、公正。
9. 深入阅读
- 完整统计公式：
docs/rules/Meegle贡献统计口径.md - Story / Task / Bug 操作细节：
docs/rules/Meegle任务创建和管理建议.md - 节点归一化和流程映射：
docs/rules/node_normalize.md - 字段映射维护：
docs/rules/Meegle贡献统计字段映射.md
*文档版本：v0.1 · 更新日期：2026-05-31*