我先讲个让人难堪的事。三年前我接手一个内部系统升级，为了显得专业，我用了整整一周排了一份特别详细的甘特图，连每天谁该干嘛都标得清清楚楚。整整327个任务，颜色区分得像是艺术品。然后开工会刚开完，老板就过来说需求优先级变了，得先把报表模块提前。我当场就懵了，因为那份计划里报表模块排在第4个月。后来我花了一个周末改计划，刚改完又来了一个紧急需求，于是那份文件两周后就成了废纸。最后这个项目用了8个月，比计划晚了3个月，团队怨声载道。这就是我学到的第一个教训：计划做得越完美，就越容易碎。
但另一个极端我也经历过。后来我又参与一个项目，为了吸取教训，干脆不怎么做计划，口头说个目标就开始干。结果呢？每天都是在救火，今天这个模块出问题，明天那个接口没对接。看起来好像灵活了，但进度从没准过，大家全靠加班，连续一个月每天工作到凌晨。最后项目真的交付了，但交付的是一个勉强能用的版本，三个核心功能被砍掉了。而且好几个骨干离职。所以你看，完全没有章法也是一样的死法。
这两次经历让我开始怀疑那些天天吹敏捷的人，也怀疑那些死抱着瀑布的人。其实他们都在试图解决同一个问题：怎么对付不确定性。但他们都想错了方向。敏捷试图用“拥抱变化”来消解不确定性，瀑布试图用“提前规划”来消灭不确定性。但实际问题是不确定性是消解不掉的，也是消灭不了的。我反而觉得，项目管理真正的核心能力，是容忍一定程度的混乱，但要给混乱套上一个笼子。
具体来说，我觉得要做的是“有意识的混乱管理”。首先，不要做超过三个月的详细计划。我后来只做三层规划：第一层是结果型的里程碑，比如“10月底前必须有可演示版本”，第二层是未来两周的具体任务，第三层是明天要干什么。剩下的中间区域，完全允许它模糊。其次，每周五下午我会开一个“混乱盘点”会，不是看进度，而是专门看哪些地方脱离了预期。比如原先说好的接口又变了，或者某个外部依赖延期了。把这些混乱点列出来，评估它们会袭击哪个里程碑。这样混乱反而变成了情报。
也许你会觉得这算不上什么高深理论。对，我本来就不是什么方法论布道师。我只是觉得，项目就像一锅沸腾的水，你没法让它不沸腾，你能做的是控制火候和锅盖。敏捷和瀑布的区别，无非是锅盖开了一条缝还是完全盖上，但水还是得一直开着。写了这么多，其实我也还在摸索，毕竟项目管理的本质，是一群不太靠谱的人，在有限的时间和资源里，去完成一件本来就不太可能精确预测的事。
