系统永远做不完

业务没想清楚就开始开发，每看到一个新界面就发现「原来我不是这个意思」。需求在开发过程中反复变更，系统越改越复杂，却始终无法真正上线。

典型症状

• 开发到一半，业务部门突然推翻之前确认的流程。
• 每个版本都有人提出新想法，优先级不断变化。
• 技术团队疲于改界面，核心逻辑却没人认真推敲。
• 项目周期不断延长，预算一超再超。

真实场景

一家物流企业启动 TMS 系统开发，最初只要求记录运输订单。开发三个月后，业务方陆续提出异常预警、司机 APP、运费对账、客户门户等需求，且每个需求都「必须做」。系统越来越臃肿，最终因成本失控而暂停。

深层分析

需求频繁变更的根源往往不是业务变化快，而是前期缺乏统一的业务语言和优先级判断。没有清晰的边界，开发就会变成无限游戏。技术团队与业务团队之间缺少共同语言，也是返工的重要原因。

判断标准 / 应对思路

在写代码之前，先用两周时间把业务流程、角色权责和最小闭环梳理清楚。通过交互原型提前确认体验，再进入开发。每个迭代只解决一个明确的业务问题，避免一次性追求大而全。

让需求变更成为可控节奏

业务变化本身是合理的，真正的问题在于变更没有边界。要避免项目失控，需要在启动阶段就建立「变更漏斗」：所有新想法先进入待评估池，由业务负责人判断其对核心目标的贡献度和紧迫性，再决定是否纳入当前迭代。这样做不是为了拒绝变化，而是让有限的开发资源集中在最有价值的事情上。

同时，业务与技术之间需要一种共同语言。用流程图、原型和用例把抽象需求具体化，减少口头描述带来的歧义。在每次迭代结束时进行可演示的验收，让业务方在真实界面中确认理解是否一致。越早发现偏差，修正成本越低。