从校招生到社畜-团队开发SOP

团队软件需求开发 SOP

适用场景：接到产品需求、技术需求或跨模块改造任务后，从需求澄清、方案评审、敏捷开发、测试验收到上线复盘的完整过程。

一、为什么需要这套 SOP

个人项目中，产品、开发和测试往往都是同一个人，很多决定可以只存在自己的脑子里：想到一个功能，马上开始写，发现不合适再调整。

团队项目不同。产品、开发、Leader、测试人员掌握的信息不同，任何没有被明确写出来并确认的内容，都可能被不同的人理解成不同的意思。

团队开发的核心不是消灭所有变化，而是做到：

1. 开发前尽早暴露需求歧义。
2. 开发中让需求变化可见、可评估、可决策。
3. 开发后用验收标准和测试证据证明结果。

完整流程如下：

接收需求
  ↓
产品需求对齐
  ↓
技术调研
  ↓
Leader 技术方案评审
  ↓
任务拆分与排期
  ↓
小步开发与阶段演示
  ↓
开发自测与代码评审
  ↓
测试、回归与产品验收
  ↓
灰度/上线与观察
  ↓
复盘

---

二、角色与职责

角色	主要负责	不应该由其单独决定
产品	为什么做、给谁用、业务范围、优先级、验收标准	具体代码架构和技术实现
开发	技术调研、方案设计、影响评估、编码、自测、暴露风险	未经确认自行扩大或改变业务范围
Leader/技术负责人	技术方向、架构边界、风险取舍、资源和排期协调	代替产品决定最终业务目标
测试	测试设计、功能验证、边界与回归测试、质量反馈	在没有确认的情况下直接改变需求范围

即使暂时没有专门的产品或测试人员，也应当把这些角色分开思考，并留下相应的需求、方案和测试记录。

---

三、阶段一：产品需求对齐

目标

确认“为什么做、做什么、什么结果算完成”，此时先不要深入讨论具体代码实现。

需要确认的问题

1. 目标和用户场景

• 这个需求解决什么用户问题？
• 谁会使用这个功能？
• 用户在什么情况下使用？
• 为什么现在要做？
• 最重要的是效果、速度、稳定性还是覆盖范围？

2. 本期范围

• 本期具体支持哪些场景？
• 哪些相关场景明确不支持？
• 自动触发还是用户手动触发？
• 成功后用户看到什么？
• 失败、取消、超时后怎么表现？
• 是否需要功能开关或灰度发布？
• 是否有平台、版本、文件格式限制？

3. 验收标准

验收标准必须能够直接判断“通过”或“不通过”，避免只写“支持某功能”“优化用户体验”。

示例：

1. 用户打开包含普通低清图片的 PDF 时，可以自动触发超分。
2. 超分成功后，页面显示高清结果。
3. 超分失败时继续显示原图，不影响 PDF 阅读。
4. 用户切换页面后，旧页面结果不能应用到新页面。
5. 特殊图片本期不处理，继续走原始渲染流程。
6. 编辑模式本期不支持。
7. 关闭功能开关后，完全走原有流程。