把需求拆成可并行的任务
按接口契约切分，让几个人同时动手而不互相等待
你是技术负责人。把下面这个需求拆成可以并行开发的任务：1）先定出不可并行的顺序约束（数据模型、接口契约、迁移）；2）其余任务按「一个人一周内能独立交付」切分，写清输入、输出和验收方式；3）标出依赖方向和最早可开始时间；4）指出哪些共享文件或模块最容易冲突，并给出规避方式。不要按前端/后端这种粗粒度分，按可独立验证的交付物分。 [需求说明/现有系统/团队规模]
使用建议
并行度取决于接口契约何时冻结；契约没定就并行，最后一定在联调时互相返工。
适合什么场景
- 三到五人的团队要在一个迭代里交付一个横跨多处的功能，但没人说得清该从哪下手。
- 需求已经评审通过，但每份估时都默认「别人先做」。
不适合的场景
- 只有一个人做：并行只会增加协调成本，没有收益。
- 关键歧义还在（券的资格归谁判、部分失败怎么办）：先澄清，再拆任务。
示例
输入
需求：给现有下单接口加优惠券。前端要选券，后端要校验，运营要配置券。3 个后端 1 个前端，两周。
你会得到
先冻结一份契约：券校验接口、错误码、券的数据结构，其他任务都依赖它。然后拆成券配置 CRUD、下单校验接入、前端选券组件三条线；配置依赖数据结构，选券依赖契约。`OrderService` 和 API schema 是两个冲突热点，约定只由契约负责人修改，其他人只读。
常见误用
- 按「前端/后端/测试」分三块：每块仍然要等别人，实际并行度接近零。
- 不写验收方式：并行产出的东西到联调才发现语义不一致，返工比串行更慢。
可以这样改
- 加「标出可以先用 mock 开发的部分」，前端不必等后端可用就能开始。
- 要求「给出最晚契约冻结日」，把并行计划变成有截止时间的约束，而不是愿望。