面对复杂项目，常见建议是“把大问题拆小”。但如果只是把工作切成更多任务，复杂度并不会自动下降：依赖仍然混乱，信息在交接中丢失，每个小任务也可能只完成一次，下一次还要重新开始。
拆分的对象是变化#
有效拆分首先要观察哪些部分经常变化，哪些部分相对稳定。把变化速度不同的内容隔开，可以避免一次局部调整迫使整个系统同时重做。
例如，内容与展示、规则与执行、数据获取与结果解释，常常适合通过明确接口分离。接口不是组织图上的边界，而是双方都能验证的输入、输出和责任。
小问题必须可以独立验证#
一个任务规模很小，却只能等到项目末尾才能判断对错，它仍然不是好的模块。真正有价值的小问题应该拥有清楚的完成条件，能够在较短周期内得到反馈，并在失败时把影响限制在局部。
验证能力让未知变得可管理。团队不必一次证明整个方案正确，而是逐步确认若干关键假设，再决定是否扩大投入。
重复带来学习曲线#
模块化最容易被忽略的收益是重复。同一种部件、流程或决策被多次使用后，团队会积累估时、质量和故障模式的数据。每次改进都能作用于之后的实例，学习不再随着项目结束而清零。
如果每次都把问题定义成独一无二的例外，经验就很难迁移。保留少量真正需要定制的部分，把其余工作转化为可重复单元，通常比追求一次性的完美方案更稳健。
接口决定拆分是否成功#
拆分之后的成本主要出现在接口：信息是否完整，责任是否清楚，变化如何通知，异常由谁处理。接口模糊会让并行变成等待，让模块化变成更多会议。
所以，拆分工作的核心不是得到更长的任务清单，而是形成更少、更稳定的协作约定。大问题因此不再是一团同时变化的未知，而是一组可以反复解决、逐步验证的小问题。