8.1 不确定性下的计划

项目计划最容易被误解成“把未来写成表格”。真实软件项目里，需求会变化，技术会暴露限制，外部依赖会延迟，团队也会不断学到新信息。

所以好的计划不是假装未来完全确定，而是安排学习、暴露风险、保留调整空间。

计划是学习系统

不确定性越高，越不应该一开始就承诺完整范围和精确日期。更好的做法是把未知拆出来：

• 用户到底需要什么？
• 技术方案是否可行？
• 外部团队是否能按时交付？
• 数据质量是否足够？
• 合规、安全或性能是否有隐藏约束？

每个未知都应该对应一个学习动作，例如技术 Spike、原型验证、用户访谈、数据抽样、灰度演练或架构评审。

缓冲不是偷懒

缓冲是承认现实。没有缓冲的计划，只是把所有风险藏到最后一周。缓冲可以放在时间、范围、人员、技术方案或发布策略上。

但缓冲不应该变成模糊借口。成熟的缓冲应该说明：

• 它保护什么风险？
• 谁可以使用它？
• 使用后会触发什么重新计划？
• 如果不用，是否可以提前交付或增加验证？

里程碑要包含决策

弱里程碑只写日期：“6 月 30 日完成后端”。强里程碑写证据和决策：“6 月 30 日前完成两家客户 IdP 的 SSO Spike，决定是否支持通用配置，还是先限制范围。”

好的里程碑回答：

• 到这个时间点我们要知道什么？
• 如果结果不好，范围、方案或时间怎么调整？
• 谁拥有这个决策？
• 什么证据足以继续前进？

计划不是一次性文档。它是团队在不确定世界里持续学习和纠偏的工作台。