8.2 失败项目的教训
无论项目计划得多么仔细，失败都还是可能发生。但失败不只是一个最终结果——它带着值得保留下来的教训，留给下一次。
这一节我们从几个角度，把失败项目里常见的原因和警告信号梳理一遍，让你能更早地发现它们，并阻止它们扩散。
1. 目标模糊或半路改变
- 不同干系人持有彼此冲突的预期，却从未被对齐
- 业务目标从未被清楚地写下来，于是各方都按各自的理解去做
- 公司优先级在项目中途改变，最初的目的就此漂移
没有稳定的方向，哪怕一个项目按时上线了，最终也可能被记成一次令人失望的经历。
2. 风险和问题没沟通到位
- 问题跟踪表沦为形式——填了，但没人真正去看
- 一线的声音从未到达决策者那里
- 风险缓解和应急方案缺失，或者很单薄
沉默的文化——或者把困难的对话推到以后——会让早期风险几乎无法被采取行动。
3. 人这一面被忽视
- PM 或其他关键 leader 太晚才被指派，或者根本没指派
- 评审和审批退化成了走过场
- 成员变动让交接没做完整
稳定的人和清晰的归属，和进度计划同样重要。任何一面失稳，其他部分也会跟着摇晃。
4. 项目管理本身没在运转
- 情况是清楚的，但决策被推迟或回避
- 事先约定的规则——评审、进度更新——并没有真的被执行
- 报告写了，但没引出任何行动
"我们知道，但没行动"，是失败项目里最常见的模式之一。
案例：某零售公司电商网站改版
概况：一次为期 8 个月的 B2C 电商网站全面改版，最终在临近上线时被取消。
- 从开局起 KPI 就不清晰，需求一直在变
- 和用户侧团队的协调很薄弱，规格确认一直在滑动
- 核心成员先后离职，连续性和交接被打断
- 临近发布时质量问题积压，最终项目被取消
这个案例把目标模糊、领导力缺位、沟通薄弱叠加在了一起——单独任何一个或许都还能撑住，但合在一起就把项目推过了可挽回的临界点。
结语：失败是一连串被忽视的信号
项目失败不是某一个错误造成的。它是累积的信号、被推迟的决策、和从未发生过的对话共同的结果。
这就是为什么早早地察觉到不适——并且既有勇气、也有机制去暂停、去聊、去修——才是真正的预防。
在 AB 中是这样的
上面每一种失败模式，在 AB Project Management 里都有一个对手：范围模糊 → 项目描述加一篇 Wiki 上的"范围外"页面，给范围一个不会漂移的家；隐藏的风险 → 用 Risk 类型的任务配上 check-in 节奏，让风险保持鲜活，而不是埋在某张表里；升级太晚 → 变更历史标签页会自动展示状态和负责人变化，所以升级不再是一份单独的报告；知识孤岛 → Wiki 页面、评论和附件都和项目本身绑在一起，而不是散落在各种共享盘和邮箱里；归属不清 → 负责人字段强制每个任务都有一个名字。AB 不能阻止失败发生——但它会让失败更早地变得可见，那时候修复的成本还很低。
→ 接下来，前往 9.0 常见问题（FAQ），把真实工作里常见的挑战和疑问一一过一遍。