开发人员每日工作 SOP
研发团队 SOP 体系 · 每日工作 SOP · 岗位分册
版本：V0.1（试行）
发布日期：2026-09-20
适用岗位：开发人员
状态：试行，试行期后调整
1. 目的
本 SOP 依据《每日工作 SOP · 共用骨架》制定，规范开发人员的每日工作节奏，目标是：
- 对团队：让上下游对开发人员的工作节奏和信息渠道有稳定预期，保底信息渠道畅通；
- 对个人：在日常重复中加深对自身岗位职责与上下游关系的理解。
边界声明：SOP 约定操作层面的"做什么"；任务交付到什么标准（代码质量、交付物规格等）属于项目层面与开发任务 SOP 的范畴，本 SOP 不作约定。
2. 适用范围
全体开发人员（含外包开发人员），每个工作日执行。
3. 每日流程
开工 → ① 盘点当日任务清单（含昨日顺延项）
→ ② 识别外部依赖项，逐项做出处理动作（解决 / 知会 / 升级）
→ ③ 执行自身任务
→ 收工 → ④ 更新当日完成情况（完成 / 未完成+原因 / 顺延）
4. 操作要求
4.1 开工环节
- 拉取并查看代码库最新状态（git pull / 查看合并记录），了解他人昨日的变更；
- 盘点当日任务清单：在手任务 + 昨日顺延项，建议 3~5 项以内；
- 识别外部依赖项并逐项处理（解决 / 知会 / 升级，三选一即可），并在依赖项旁轻量留痕（如"9:10 已在群里知会张三"）。开发岗典型依赖：
- 需求不清楚 → 知会产品经理；
- 接口未就绪 / 联调环境不可用 → 知会对方开发或测试；
- 权限、账号等阻塞 → 升级技术 Leader。
"处理"= 知道有这么个事，并做出行动，不要求当日彻底解决。判定标准是可观察的操作动作，而非依赖项的解决结果。
- 代码冲突、分支状态异常一并在开工时处理，不带病开工。
4.2 执行环节
- 每日至少一次代码提交/推送（未完成的工作走特性分支），保证"工作可见"；
- 任务卡状态随手更新（开始 / 进行中 / 待验收），不攒到收工；
- 方案拿不准的点，当天发起技术 Leader / 架构师咨询，不闷头猜。
4.3 收工环节
- 更新当日完成情况：完成 / 未完成+原因 / 顺延，外部依赖项的处理结果一并写明；
- 未推送的代码推送、可合并的发起合并请求；
- 明确明天开工的第一件事（与开工环节衔接，形成闭环）。
5. 收工自查 Checklist
| 序号 | 自查项 |
|---|
| 1 | 当日清单已盘点，外部依赖项已处理并留痕 |
| 2 | 今日代码已提交并推送 |
| 3 | 任务卡状态与实际进展一致 |
| 4 | 当日完成情况已更新（含未完成原因 / 顺延说明） |
| 5 | 明日开工第一件事已明确 |
6. 检查方式
以自查为主；技术 Leader 按周抽查（任务卡状态与提交记录一致性等），不逐日巡查。
7. 不在本 SOP 约定的事项
单元测试覆盖率、代码规范细则、固定站会等，属于开发任务 SOP 或团队既有规范，本 SOP 不重复约定。SOP 只固化少数关键动作，其余留白。
8. 修订记录
| 日期 | 版本 | 说明 |
|---|
| 2026-09-20 | V0.1 | 初稿发布，进入试行 |