用范围换确定性

时间、范围、质量，只能同时锁两个

这是老话，但真正按它做事的团队并不多。多数延期都不是因为开发慢，而是因为范围一直在长。

我的做法是把需求分三层：必须做的、应该做的、可以晚一点做的。第一层决定上线时间，后两层排进后续迭代。

让范围变更可见

新增需求本身不是问题，问题是不记录。一旦有了变更清单，讨论就从「能不能做」变成了「用哪个换」，沟通成本立刻降下来。

• 每次变更都写清楚：谁提的、解决什么问题、替换掉哪项
• 变更进当期，就明确说出被挤出去的是哪一项
• 先做能验证核心假设的部分

验收标准要提前写

验收标准写在开发之前，是范围管理里性价比最高的一件事。它同时约束了需求方和实现方，也避免上线前临时争论「这算不算做完」。

延伸阅读

范围确认之后，通常会进入架构与数据库设计。可以继续阅读《架构够用就好》，或了解 企业级 Web 系统开发服务。