在一次核心需求迭代里，技术负责人（Tech Lead）不是“把需求拆完就消失”，也不是“全程亲自写代码”，而是要在**“需求→设计→编码→测试→上线→复盘”全链路里扮演“风险雷达 + 质量守门员 + 资源调度器”。下面按时间线给出“必须到场、必须决策、必须输出”**的 24 件关键事项，可直接当 Check-list 贴到 Jira/飞书多维表格里。
1. 需求澄清阶段（D-7 ~ D-3）
| 序号 | 动作 | 目的 | Tech Lead 交付物 |
|---|
| 1 | 反向需求陈述 | 防止“我以为” | 让产品经理重复一遍需求背景，Tech Lead 用 1 句话反向描述业务价值，邮件确认。 |
| 2 | 需求 ROI 计算 | 砍伪需求 | 用“人日 × 人均成本 ÷ 预期年化收入”算出 ROI<1 的直接否掉。 |
| 3 | 技术可行性预研（≤4 h） | 防止大坑 | 输出“可行性便签”：技术难点 1 张图、风险 1 张表、回退方案 1 句话。 |
| 4 | 版本范围锁定 | 防蔓延 | 在 Confluence 画“需求冻结线”，任何新增需求必须走 CC（Change Control）委员会。 |
2. 技术设计阶段（D-3 ~ D-1）
| 序号 | 动作 | 目的 | Tech Lead 交付物 |
|---|
| 5 | 接口契约先行 | 并行开发 | 用 Swagger-OpenAPI 先定义接口，前端/后端/测试三方会签。 |
| 6 | 容量预估小算式 | 防崩溃 | 峰值 QPS = 日活 × 8% ÷ 3600 × 10；若 >500，必须加缓存或限流。 |
| 7 | 灰度方案设计 | 最小爆炸 | 写 3 行配置：①灰度白名单 ②灰度比例 ③一键回滚开关（Feature Flag）。 |
| 8 | 测试策略评审 | 一次做对 | 把“单元/接口/E2E/性能”四项测试责任人、覆盖率、截止时间写进表格并@到人。 |
3. 编码阶段（D-1 ~ D+3）
| 序号 | 动作 | 目的 | Tech Lead 交付物 |
|---|
| 9 | 每日 15 min 站会 | 同步阻塞 | 只回答“昨天完成了什么→今天要做什么→卡点”，卡点多于 2 个立即拆解。 |
| 10 | 代码 Review “三件套” | 防屎山 | ①自我 Diff（作者发 Merge Request 前自己评论 3 处可优化点）；②同伴 Review；③Tech Lead 抽样 30% 关键路径。 |
| 11 | 静态扫描门禁 | 防漏洞 | Sonar 新增阻断问题 = 0，否则流水线自动打回。 |
| 12 | 联调“冒烟清单” | 防返工 | 列出 5 条主流程 curl 命令，联调通过后方可提测。 |
4. 测试 & 验收阶段（D+3 ~ D+5）
| 序号 | 动作 | 目的 | Tech Lead 交付物 |
|---|
| 13 | 缺陷分级会议 | 不背锅 | P0/P1 缺陷必须当天修复；P2 缺陷数 > 需求数的 10% 禁止上线。 |
| 14 | 性能基线对比 | 防慢查询 | 用 last-build 的 JMeter 报告做基线，接口 P99 延迟上升 >20% 即阻塞。 |
| 15 | 产品 UAT 签字 | 防扯皮 | 产品经理在 TestRail 点“Pass”并截图发群，否则视为未验收。 |
5. 上线阶段（D+5）
| 序号 | 动作 | 目的 | Tech Lead 交付物 |
|---|
| 16 | 上线清单 Checklist（纸面打钩） | 防遗漏 | 含 12 项：配置中心 key□、数据库脚本□、Feature Flag□、回滚脚本□、监控大盘□ … 全部打钩才 @运维 发版。 |
| 17 | 双人值守 & 回滚演练 | 防深夜炸雷 | 上线当晚 Tech Lead + 1 名核心开发 On-Call，先在生产环境演练回滚脚本，耗时 <5 min 才算通过。 |
| 18 | 实时监控 | 秒级告警 | 对核心接口配置“1 min 错误率 >1%” 的 P0 告警，5 min 内无恢复立即回滚。 |
6. 复盘阶段（D+6 ~ D+7）
| 序号 | 动作 | 目的 | Tech Lead 交付物 |
|---|
| 19 | 5 Why 复盘 | 找根因 | 出现 P0/P1 缺陷必开 30 min 复盘会，输出“根因→责任人→改进动作→完成日期”。 |
| 20 | 沉淀技术笔记 | 可复用 | 把本次迭代架构图、踩坑记录、性能调优参数写入团队 Knowledge Base，下次迭代前必须能检索到。 |
| 21 | 更新“研发资产” | 可持续 | 把新增接口、环境变量、回滚开关登记到“研发资产表格”，离职交接 5 分钟能看懂。 |
7. 沟通 & 风险管理（贯穿全程）
| 序号 | 动作 | 目的 | Tech Lead 交付物 |
|---|
| 22 | 每日 1 条“风险广播” | 早暴露 | 无论大小，只要可能延期 >1 天，立即发群@产品经理：风险描述/影响/缓解/决策人。 |
| 23 | 可视化燃尽图 | 给老板安全感 | 用 Jira Dashboard 公开展示“剩余 Story Point & 缺陷趋势”，老板每天自己刷，无需催。 |
| 24 | 复盘 ToDo 跟踪 | 防止白复盘 | 把复盘产生的 Action 转成 Jira 子任务，指派到人，下次迭代评审必须先关闭。 |
一句话总结
Tech Lead 的核心迭代使命就是：让需求“快速”且“安全”地变成钱，同时把下次迭代的速度再提高 10%。
把以上 24 件事打成一张 A4 表格，贴在工位，做完一项勾一项，基本就能在 20 人小团队里做到“上线不炸、复盘不甩锅、下次迭代更快”。
