我上一份工作，每天上午九点半，全组雷打不动地开站会。每个人对着Jira看板，把昨天完成的任务从一个列拖到另一个列，然后说一句“昨天没什么问题，今天继续”。看起来井井有条，实际上呢？那个项目已经延期三个月了，老板还觉得一切尽在掌握，因为看板上所有任务都有负责人，都有截止日期，甚至连颜色都标得清清楚楚。
这让我开始怀疑，我们到底是在做项目管理，还是在做一场大型的“秩序表演”？甘特图、里程碑、燃尽图……这些工具确实很漂亮，但她们只负责呈现一个符合逻辑的故事：任务在推进，依赖关系清晰，风险被标记。而真相往往躲在故事之外——真正卡住进度的不是一个技术难题，而是两个同事之间的冷战；真正消耗时间的不是开发，而是反复修改需求的产品经理。工具记录得了“状态”，却记录不了“为什么状态是这个样子”。
对比一下瀑布和敏捷吧。瀑布计划周全，试图预判所有变化；敏捷拥抱变化，把工作切成一个个小迭代。看似两个极端，实际上它们的底层思维是一致的：都相信“控制”能带来好结果。瀑布用流程控制，敏捷用反馈控制，但控制的对象都是人。人一旦被控制，就会下意识地应付控制——因为你的绩效是被看板上的绿点决定的，那我就要确保绿点是绿的，至于绿点背后是不是真的在推进，那是另外一回事。于是项目变成了一场各方心照不宣的表演，大家共同维护一个“可控”的幻象。
我后来在一个只有四五个人的小项目里，尝试了另一种做法：不设看板，不写周报，取消站立会。唯一的要求是，每个人都得在每天下班前，给全组发一封邮件，用三行字说明今天干了什么、遇到了什么阻碍、明天准备干什么。就这么简单。一开始大家很不适应，觉得没看板心里不踏实。但慢慢发现，邮件的语气比看板诚实得多——因为邮件是写给人看的，不是写给流程看的。有人在邮件里说“今天跟XX吵架了，所以没写代码”，这些真实信息以前在Jira上绝对看不到。
当然，我不是说项目管理工具没用，或者我们应该回到“沟通靠吼”的原始时代。我想说的是，秩序不是用来展示的，而是用来服务问题的。如果你的项目出问题了，第一反应不应该是再找一个更复杂的工具或者更严格的控制流程，而是停下来看看你们依赖的那些“可视化”信息，到底有多少是真实发生的，有多少只是为了让看板好看而填的。真正有效的项目管理，不是让一切变得可控，而是让不可控的部分尽早暴露出来——这需要勇气，也需要抛弃一点对“秩序感”的迷恋。混乱不可怕，假装有序才可怕。
