流程

新任务流程记录：
https://docs.qq.com/markdown/DTnRRd05NVFJwbUpI?
## 1. 全流程详细拆解（六步法）

### 第一步：确定任务背景、问题、动机和目标 (Define)

流程的起点是任务发起人提交的原始需求。发起人需首先填写**《任务定义卡》初稿**，该卡是任务的核心档案，必须包含以下关键信息：
- **基本信息**：任务名称、发起人、协调人、执行者、优先级、期望完成日等，确保责任到人。
- **背景与问题**：描述现状、核心痛点及不做的影响，必须用数据支撑“为什么要做”。
- **目标**：必须符合SMART原则，分为定性目标、定量指标和交付物，这是后续验收的唯一依据。
- **范围**：明确包含与不包含的内容，防止需求蔓延。
- **资源与约束**：列出所需人力、预算、依赖项，并在此处记录BBS查阅结论（后续步骤补充）。

发起人填写初稿后，协调人整理并发至工作群，@核心执行者。核心执行者需在T+1日内反馈可行性意见。经过讨论后，最终形成确认版的《任务定义卡》。整个步骤需在T+2日内完成定稿，且目标必须严格遵循SMART原则。

### 第二步：查阅BBS要求详情 (Check)

基于定稿的《任务定义卡》，协调人或执行者需要在BBS或知识库中搜索相关关键词（如历史项目、合规要求、技术约束），以确认是否存在前置依赖任务或冲突任务。如有历史遗留问题，需在**《任务定义卡》的“BBS查阅结论”字段**中备注。这一步需要在第一步定稿后的4小时内完成，并输出查阅结论（无冲突/有依赖/需合规审查）。若发现重大冲突，则需退回第一步重新定义。

### 第三步：文字交流讨论确定细节 (Discuss)

确认无冲突后，团队将在工作群或协作软件中进行文字讨论。讨论应聚焦于**《任务定义卡》中尚未细化的部分**（如技术方案、资源分配等）。为了提升效率，我们设定一条共识规则：任何信息发出后24小时内无反对意见，即视为默认同意。若有修改意见，协调人需更新《任务定义卡》中的相应字段，并再次确认。重要结论必须更新到文档中，而非仅停留在聊天记录里。整个过程应在T+2日内完成。

### 第四步：会议讨论 (Meeting - 仅在文字不一致时触发)

如果文字交流超过24小时仍存在核心分歧，或问题复杂度超出预期，则触发第四步。此时，协调人需发起会议邀请，并必须包含会议议程。会议应聚焦分歧点，由任务发起人（若涉及业务目标）拥有最终决策权。记录员需现场记录决议，会后输出**《会议纪要》**。纪要必须包含以下部分：
- **会议元数据**：主题、时间、地点、参会人、记录人。
- **会议背景与目的**：为何开会。
- **核心讨论与决议**：逐条记录关键讨论点和最终结论。
- **变更内容**：相对于《任务定义卡》初稿的修改点。
- **待办事项**：明确事项、负责人、截止时间。
会后，协调人需根据决议**更新《任务定义卡》**，并在1个工作日内完成所有动作。会议时长建议控制在30-45分钟，严禁无准备开会。

### 第五步：记录在BBS (Record)

计划确定后，协调人应将最终版的**《任务定义卡》**和**《会议纪要》（如有）**发布至BBS指定板块，并添加相应标签（如#进行中 #高优先级 #部门名），同时关联相关文档链接。这一步虽标为“可选”，但强烈建议执行，以便信息透明化和后续复盘（涉密任务除外）。发布应在计划确定后立即完成。

### 第六步：确定计划并执行 (Execute)

最后，核心执行者需根据《任务定义卡》中的目标、范围和资源约束，对任务进行工作分解，制定**《执行计划表》**。该表必须包含：
- **总体信息**：任务名称、协调人、周期、核心目标。
- **详细执行分解 (WBS)**：按阶段拆分任务，明确每个子任务的责任人、时间、依赖关系和交付物。
- **里程碑**：识别关键节点，用于向管理层汇报。
- **风险跟踪**：提前识别风险并制定应对措施。

协调人负责跟踪进度（每日或每周同步），确保计划落地。任务完成后，由发起人依据《任务定义卡》中的定量目标进行验收，并在BBS更新状态为“已完成”。执行过程中，若目标发生变更（如范围扩大、指标调整），需重启第一步至第五步的变更流程，并更新所有相关文档。

---

## 4. 核心模板

### 模板一：任务定义卡 (Task Charter)

**用途**：这是每个新任务的“出生证明”，用于在起点就锁定任务的背景、目标和边界。所有核心干系人都必须在此达成共识。

```markdown
# 任务定义卡

## 1. 基本信息
| 字段 | 内容 | 填写说明 |
| :--- | :--- | :--- |
| **任务名称** | [示例：2023年Q4 用户注册流程性能优化] | 格式：[时间/版本] + [主体] + [动作]，要能一眼看出是什么任务 |
| **任务发起人** | [姓名] | 对业务结果负责的人，拥有最终验收权和变更决策权 |
| **项目协调人** | [姓名] | 负责流程推进、文档维护、会议组织、进度催办 |
| **核心执行者** | [姓名] | 负责技术/方案落地，拆解WBS，反馈风险 |
| **优先级** | [P0紧急/P1高/P2中/P3低] | P0：必须立即处理，否则业务受损；P1：本轮迭代必须包含 |
| **发起日期** | [YYYY-MM-DD] | 任务发起的日期 |
| **期望完成日** | [YYYY-MM-DD] | 业务期望的最终交付日期（初步，执行后可调整） |

## 2. 背景与问题 (Background & Problem)
> **核心逻辑**：为什么要做？现在发生了什么问题？不做会怎样？

- **背景现状**：[描述当前的情况，最好有数据支撑。例如：目前注册流程平均耗时3.5秒，高于行业平均水平2秒；近期客服收到约50起投诉反映注册卡顿。]
- **核心痛点**：[具体阻碍了什么业务？例如：高延迟导致新用户注册转化率从65%下降至58%。]
- **不做的影响**：[如果推迟或不做，会有什么量化损失？例如：预计每月损失约2000个新用户，对应潜在GMV损失XX万。]

## 3. 目标 (Goals)
> **必须符合SMART原则**：具体(Specific)、可衡量(Measurable)、可达成(Achievable)、相关性(Relevant)、时限性(Time-bound)。

- **定性目标**：[描述体验上的改进。例如：让注册过程更加流畅顺滑。]
- **定量目标 (关键指标)**：[这是验收的核心依据。例如：]
    - 注册接口平均响应时间从3.5秒降低至**1秒以内**。
    - 注册成功率从95%提升至**99.5%**。
    - 上线后一个月内，因注册卡顿引起的客诉减少**80%**。
- **交付物**：[具体要产出什么。例如：]
    - 优化后的注册接口代码（含前后端）。
    - 压测报告（需包含500并发下的响应时间）。
    - 上线部署文档与回滚预案。

## 4. 范围 (Scope)
> **明确边界**，防止需求蔓延。

- **包含 (In Scope)**：[本次必须做的事。例如：]
    - 手机号+验证码注册流程优化。
    - 密码设置环节的异步处理改造。
- **不包含 (Out Scope)**：[本次明确不做的事。例如：]
    - 第三方账号（微信/苹果）登录注册改造。
    - 注册后的欢迎页面UI redesign。
    - 老用户找回密码流程。

## 5. 资源与约束
> **明确条件**，提前暴露风险。

- **所需资源**：[需要什么支持？例如：]
    - 人力：后端开发1人(3人日)、前端开发1人(2人日)、测试1人(1人日)。
    - 预算/服务器：需申请2台临时压测服务器。
- **依赖项**：[需要谁配合？例如：需等待安全部门开放新的加密算法权限，预计10月20日完成。]
- **BBS查阅结论**：[是否有历史冲突或合规要求？例如：经查BBS，2022年曾有类似优化但因数据库版本老旧失败，本次需先升级数据库驱动。]

## 6. 流程状态记录
> **用于协调人标记进度**，可视化当前阶段。

- [ ] 第一步：定义完成
- [ ] 第二步：BBS查阅完成
- [ ] 第三步：文字对齐完成
- [ ] 第四步：会议讨论 (无需/已完成)
- [ ] 第五步：BBS公示完成
- [ ] 第六步：执行与验收
```

### 模板二：会议纪要 (Meeting Minutes)

**用途**：当第四步触发会议时使用。目的是记录决议，明确待办，避免会上热闹、会后忘掉。

```markdown
# 会议纪要：[任务名称] 目标对齐会

## 1. 会议元数据
- **会议主题**：[示例：关于注册流程优化目标分歧的最终决策会]
- **时间**：[YYYY-MM-DD HH:MM - HH:MM]
- **地点/链接**：[例如：302会议室 / 腾讯会议 123-456-789]
- **参会人**：[列出姓名，如：张三(发起人)、李四(协调人)、王五(执行者)、赵六(特邀技术专家)]
- **记录人**：[姓名]

## 2. 会议背景与目的
- **为何开会**：[简述触发会议的原因。例如：因文字讨论24小时后，执行者与发起人在"1秒内"的目标是否可实现上存在分歧，故召开本次会议进行技术可行性评估。]

## 3. 核心讨论与决议
> **记录关键讨论点和最终结论**，这是纪要的灵魂。

- **讨论点1：1秒内响应时间的技术可行性**
    - 技术专家赵六分析：当前数据库IO是瓶颈，若升级SSD并优化索引，可达到900ms；若要保持现状，只能到1.2秒。
    - **决议**：同意升级数据库SSD，将目标定为**950ms以内**。升级成本在预算内，由执行者王五负责发起工单。
- **讨论点2：是否要同时优化微信登录**
    - 发起人张三认为微信登录也很慢，想一并做。
    - 执行者王五反馈：如果一并做，上线时间将推迟5天，且超出本次迭代容量。
    - **决议**：本次**不包含**微信登录，严格按范围执行。微信登录优化列为新任务，Q4另行启动。

## 4. 变更内容 (相对初稿)
- **目标值修改**：响应时间目标从"1秒内"修改为"950ms以内"。
- **新增依赖**：新增依赖项"需在10月25日前完成数据库SSD升级"。

## 5. 待办事项 (Action Items)
> **谁、在什么时间前、完成什么**。这是会后跟进的核心。

| 事项 | 负责人 | 截止时间 | 交付物/备注 | 状态 |
| :--- | :--- | :--- | :--- | :--- |
| 更新《任务定义卡》并重新公示 | 协调人(李四) | 会议次日 18:00前 | 更新后的任务定义卡链接 | 待处理 |
| 发起数据库SSD升级工单 | 执行者(王五) | 10月20日 12:00前 | 工单号 #INC-20231020-001 | 待处理 |
| 准备详细技术设计方案 | 执行者(王五) | 10月25日 18:00前 | 设计文档链接 | 待处理 |

## 6. 附件与相关链接
- [会议录屏链接] (如有)
- [会上展示的性能分析报告链接]
- [更新后的《任务定义卡》链接] (待更新后补充)
```

### 模板三：执行计划表 (Execution Plan)

**用途**：用于第六步，将任务拆解为可执行的动作，明确责任人和时间节点，便于跟踪。

```markdown
# 执行计划：[任务名称：Q4 用户注册流程性能优化]

## 1. 总体信息
- **任务名称**：Q4 用户注册流程性能优化
- **项目协调人**：李四
- **计划周期**：2023-10-20 至 2023-11-10
- **核心目标**：注册接口响应时间 ≤ 950ms，成功率 ≥ 99.5%

## 2. 详细执行分解 (WBS)
> **建议按阶段拆分**：规划、开发、测试、上线。

| 阶段 | 任务ID | 任务内容 | 责任人 | 计划开始 | 计划结束 | 依赖前置任务 | 交付物/产出 | 状态 |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| **规划** | P-01 | 数据库SSD升级 | 王五 | 10-20 | 10-25 | 无 | 升级完成确认单、性能基线数据 | 未开始 |
| | P-02 | 编写详细技术设计文档 | 王五 | 10-21 | 10-26 | P-01 (需确认新硬件性能) | 技术设计文档V1.0 | 未开始 |
| **开发** | D-01 | 后端代码重构与索引优化 | 王五 | 10-27 | 10-31 | P-02 | 代码提交(MR链接)、单元测试覆盖率报告 | 未开始 |
| | D-02 | 前端请求合并改造 | 赵六 | 10-28 | 11-01 | P-02 | 代码提交(MR链接) | 未开始 |
| **测试** | T-01 | 编写压测脚本 | 孙七 | 11-01 | 11-02 | D-01, D-02 | 压测脚本仓库地址 | 未开始 |
| | T-02 | 执行功能测试与回归 | 孙七 | 11-02 | 11-03 | D-01, D-02 | 测试报告（含bug列表） | 未开始 |
| | T-03 | 执行压力测试 | 孙七 | 11-04 | 11-05 | T-01, P-01 | 压测报告（含响应时间、成功率、CPU/内存监控） | 未开始 |
| **上线** | L-01 | 编写上线部署文档与回滚预案 | 王五 | 11-05 | 11-06 | T-03 | 部署文档、回滚脚本 | 未开始 |
| | L-02 | 灰度发布(10%流量) | 王五 | 11-07 | 11-07 | L-01 | 线上灰度监控数据 | 未开始 |
| | L-03 | 全量发布 | 王五 | 11-08 | 11-08 | L-02 (观察24h无异常) | 上线成功确认 | 未开始 |
| | L-04 | 上线后观察与验收 | 李四/张三 | 11-08 | 11-10 | L-03 | 验收确认签字 | 未开始 |

## 3. 里程碑
> **关键节点**，用于向管理层汇报进度。

| 里程碑 | 对应任务ID | 计划完成日 | 实际完成日 | 状态 |
| :--- | :--- | :--- | :--- | :--- |
| 技术方案定稿 | P-02 | 10-26 | - | 未开始 |
| 代码开发完成 | D-01, D-02 | 11-01 | - | 未开始 |
| 压测验收通过 | T-03 | 11-05 | - | 未开始 |
| 全量上线成功 | L-03 | 11-08 | - | 未开始 |

## 4. 风险跟踪
| 风险描述 | 可能性 | 影响程度 | 应对措施 | 责任人 | 状态 |
| :--- | :--- | :--- | :--- | :--- | :--- |
| SSD升级导致服务器短暂宕机 | 中 | 高 | 提前发布公告，选择凌晨业务低谷期操作，准备好回滚 | 王五 | 监控中 |
| 压测不达标，响应时间超过950ms | 低 | 高 | 准备二级缓存方案作为备选，若压测不达标则立即启用 | 王五 | 待触发 |
```

---

## 5. 时间节点与 SLA

为保证效率，我们对各步骤设定了默认时限：任务定义需在1个工作日内完成（最长容忍2个工作日），超时则协调人需升级汇报给发起人主管；BBS查阅需在4小时内完成（最长容忍1个工作日），超时则默认无冲突，风险自负；文字对齐需在1个工作日内完成（最长容忍2个工作日），超时则自动触发会议；会议讨论需在1小时内完成（最长容忍1个工作日），超时则由发起人现场强制决策；BBS记录需在2小时内完成（最长容忍4小时），超时会影响任务透明度考核；执行阶段则按计划进行，若超时则触发风险预警机制。

## 6. 常见问题解答

**Q1: 如果文字交流大家都不说话怎么办？**  
A: 协调人需在发出文档后@所有人并设定反馈截止时间（例如今日18:00）。截止后无异议视为默认同意。

**Q2: 小任务也需要走这么复杂的流程吗？**  
A: 可根据任务规模分级处理：S级/A级任务（跨部门、高成本）需严格执行6步；B级/C级任务（组内、低成本）可简化第2、5步，但第1步（定义卡）和第6步（计划）不可省略。

**Q3: 执行过程中需求变了怎么办？**  
A: 若为微小变更（不影响目标），执行者可直接调整并同步协调人；若为重大变更（影响目标/时间/成本），则必须重启第一步，更新《任务定义卡》并重新公示。

**Q4: BBS记录太麻烦，可以省略吗？**  
A: 可以省略，但需经发起人确认。建议至少将《任务定义卡》链接存档至共享文件夹，以便后续追溯。

## 7. 落地执行清单

作为项目协调人，每次启动新任务时，请核对以下事项：是否已指定唯一的协调人？《任务定义卡》是否填写完整？是否设定了明确的反馈截止时间？文字沟通是否有结论？若无，是否已预约会议？会议纪要是否已发出并@相关人员？最终文档是否已归档或发布BBS？执行计划是否已拆解到“人/天”？