项目管理规范
适用场景：公司内部项目管理流程，DarkM 项目实际使用的简化版流程
一、项目流程总览
需求流程 → 开发流程 → 测试流程 → 部署上线 → 运维监控
1
二、需求流程（8 步）
| 步骤 | 负责人 | 产出物 | 耗时 |
|---|
| 1. 需求提出 | 客户 IT | 需求邮件/文档 | - |
| 2. 内部评审 | 项目经理 | 《问题清单》 | 1-2 天，重大复杂需求时间更长 |
| 3. 需求澄清 | 项目经理 | 《需求确认邮件》 | 1-3 天 ，重大复杂需求时间更长 |
| 4. 工作量评估 | 项目经理 + 技术负责人 | 《工作量评估表》 | 1-2 天，重大复杂需求时间更长 |
| 5. 计划确认 | 项目经理 | 《项目计划表》 | 1 天，包括工作量确认，重大复杂需求时间更长 |
| 6. 开发实施 | 开发团队 | 代码、单元测试 | 按需求定 |
| 7. 测试验证 | 测试团队 | 《测试报告》 | 3-5 天，重大复杂需求时间更长 |
| 8. 部署上线 | 运维团队 | 《发布记录》 | 1 天 |
简化要点
- ✅ 小需求（<5 人天）可合并步骤 2-3-4-5，一次会议搞定
- ✅ 紧急需求可走快速通道，先上线后补文档，尽量避免
- ✅ 需求变更>20% 需重新评估工作量和排期
三、开发流程（6 步）
| 步骤 | 负责人 | 产出物 |
|---|
| 1. 需求分析 | 开发工程师 | 需求理解笔记 |
| 2. 技术方案 | 资深开发 | 简单设计文档 |
| 3. 编码实现 | 开发工程师 | 代码 |
| 4. 代码审查 | 技术负责人 | Code Review 记录 |
| 5. 单元测试 | 开发工程师 | 单元测试代码 |
| 6. 提测 | 开发工程师 | 提测邮件 |
简化要点
- ✅ 小需求（❤️ 人天）技术方案可简化为口头说明 + 关键代码注释
- ✅ 代码审查可采用"结对审查"，两人互相 review
- ✅ 单元测试优先覆盖核心业务逻辑和边界条件
四、测试流程（5 步）
| 步骤 | 负责人 | 产出物 |
|---|
| 1. 测试计划 | 测试经理 | 《测试计划》 |
| 2. 用例设计 | 测试工程师 | 《测试用例》 |
| 3. 执行测试 | 测试工程师 | 测试记录 |
| 4. 缺陷跟踪 | 测试工程师 | Bug 列表 |
| 5. 测试报告 | 测试经理 | 《测试报告》 |
简化要点
- ✅ 小需求测试用例可简化为"测试检查清单"（Checklist）
- ✅ 缺陷跟踪可用 Excel/在线表格，不必上复杂系统
- ✅ 所有测试都必须至少两个测试人员参与测试
- ✅ 测试报告可简化为一页纸
五、角色职责
| 角色 | 核心职责 | 关键产出物 |
|---|
| 项目总监 | 技术战略、整体管控、资源协调 | 技术规划、架构决策 |
| 项目经理 | 需求沟通、计划制定、进度管控 | 项目计划、周报 |
| 技术负责人 | 技术方案、代码审查、技术攻关 | 技术方案、Code Review |
| 开发工程师 | 需求开发、单元测试 | 代码、单元测试 |
| 测试工程师 | 测试计划、用例设计、执行测试 | 测试用例、测试报告 |
| 运维工程师 | 系统部署、监控告警、应急响应 | 部署记录、监控报表 |
六、紧急事故处理
事故分级
| 级别 | 响应时间 | 处理时限 | 示例 |
|---|
| P0-严重 | 15 分钟 | 2 小时 | 系统崩溃、数据丢失、核心功能不可用，如：订购系统宕机 |
| P1-高 | 30 分钟 | 4 小时 | 重要功能异常、影响部分用户，如：某个渠道无法下单 |
| P2-中 | 2 小时 | 24-48 小时，跟随发布周期 | 一般功能问题、不影响核心业务，如： 页面显示错误 |
| P3-低 | 2 小时 | 1-2 周，跟随发布周期 | UI 问题、文案错误，如UI 小问题 |
处理流程
事故发现 → 初步定级 → 应急响应 → 问题定位 → 修复验证 → 复盘总结
1
七、常用模板
- 《需求评估表》
- 《项目计划表》
- 《周报模板》
- 《测试用例模板》
- 《测试报告模板》
- 《发布记录模板》
- 《事故复盘报告》
参考文档