项目管理
项目管理就是把“要做的事”拆开、排好、盯住，保证按时按质交付。
排期与里程碑
Section titled “排期与里程碑”先拆阶段，再定里程碑。里程碑就是“到某天必须完成某件事”，是给人看的进度锚点。
| 阶段 | 产出 |
|---|---|
| 需求确认 | 需求文档、验收标准 |
| 设计 | 原型图、功能规格 |
| 开发 | 前后端功能完成、接口联调通过 |
| 测试 | 测试报告、Bug 修复完成 |
| 上线 | 部署完成、上线核验通过 |
- 里程碑要配一个明确的日期和负责岗位。
- 每个阶段留出缓冲时间，别把工期排到一天不剩。
迭代就是把工作切成一小段一小段，每段交付一部分可用功能。看板让所有人一眼看到进度。
看板列表（每张卡片代表一条需求或任务）：
| 列 | 含义 |
|---|---|
| 需求 | 待处理的需求 |
| 待开发 | 已排期，还没开始 |
| 开发中 | 前后端正在做 |
| 待测试 | 开发完成，等测试 |
| 测试中 | 测试进行中 |
| 待上线 | 测试通过，等发布 |
| 已完成 | 已上线并核验 |
流转链：需求 → 待开发 → 开发中 → 待测试 → 测试中 → 待上线 → 已完成
- 一张卡片同一时间只在一个列里，别“脚踏两条船”。
- 卡片上写清负责人和截止时间。
需求变更是常态，但不能随便变。每条变更都登记，评估后再决定做不做、要不要重新排期。
| 变更内容 | 原因 | 影响范围 | 是否重新排期 | 提出人 | 结论 |
|---|---|---|---|---|---|
| （变更了什么） | （为什么变） | （影响哪些功能/岗位） | 是/否 | （谁提的） | 同意/拒绝/延后 |
判断顺序：
- 变更原因是什么，是必须改还是想做。
- 影响范围有多大，涉及前端、后端、测试还是全部。
- 要不要重新排期，会不会影响上线时间。
- 评估结果写进登记表，通知所有相关人。
口头变更不算数，写进登记表才算数。
风险与依赖管理
Section titled “风险与依赖管理”风险是“可能出问题的事”，依赖是“要等别人先做完的事”。提前列出来，别等出事才想。
| 风险 | 可能影响 | 应对措施 |
|---|---|---|
| 第三方支付对接延迟 | 支付功能无法上线，牵连下单流程 | 提前对接、准备备用支付渠道、先用假支付联调 |
| 需求频繁变更 | 反复返工，工期延长 | 设需求冻结窗口、走变更登记、超范围单独排期 |
| 人员变动（核心开发离职） | 进度中断、代码交接困难 | 关键模块双人熟悉、及时提交代码、文档留档 |
| 服务器或域名未就绪 | 无法按时上线 | 提前申请备案、预留审批时间 |
- 每条风险都要有“谁负责盯着”。
- 高风险的应对措施要在开工前就准备好，不是出事才想。
上线 Checklist
Section titled “上线 Checklist”上线前逐项核对，勾完才能发布。
- 功能：核心流程逐条走通，和验收标准一致
- 文案：页面文字、提示语、报错文案无误
- 图片：图标、Banner、商品图正常显示，无裂图
- 权限：各角色（用户、管理员）只能看到该看的内容
- 数据：测试数据已清理，正式数据无误
- 环境：域名、证书、服务器配置正确
- 兼容：目标浏览器和机型抽测通过
- 回滚方案：出问题能快速退回上一版本
- 通知：相关人已知晓上线时间和影响
上线后开会回顾，别只夸成绩，重点找问题。
- 数据回顾：上线后的关键数据（访问、转化、留存、报错率）和目标比，达标没有。
- 问题：过程中出了哪些问题，是需求、开发、测试还是沟通造成的。
- 改进项：每条问题对应一个具体改法，写清负责人和下次迭代落地。
复盘要落到“下次怎么做”，不然就是白开一次会。