我做过三年项目经理，最大的教训不是什么甘特图技巧，也不是风险评估矩阵。是有一次我们团队花了两周做出来的原型，客户看了一眼说“这不是我要的”。所有人都很沮丧，但复盘时我突然意识到——问题不是沟通不够，而是我们把“避免错误”放在了“发现错误”前面。项目管理界整天教你怎么防止偏差，但真正决定项目生死的是你多久能发现自己跑偏了。那些所谓的最佳实践，很多只不过是把错误推迟到更贵的时候才炸出来而已。
传统项目管理和敏捷的争论，在我看来根本不是迭代和文档的对立。真正的分水岭是：你允许错误以多高的频率、多小的规模出现？瀑布把错误积攒到验收那一刻，敏捷把它拆成每两周一次的“小爆炸”。但很多团队用了敏捷却还是怕错，因为他们的组织文化里，犯错是丢人的事。于是大家拼命在评审会上展示“进展”，而不是暴露“疑问”。这种自我欺骗比任何工具都致命。我发现那些真正跑得快的小组，往往不是流程最规范的，而是成员愿意在下午三点就冲进会议室说“我觉得方向有问题”——这种团队里，项目失败的代价被均摊到了每一天。
不过说这些很容易变成另一种鸡汤。我想说的是一个更让人不舒服的维度：项目管理其实是在管理“注意力的政治”。谁的优先级算数？哪个部门的声音在会议上被听见？这从来不是靠什么优先级矩阵能解决的。我见过一个项目，看似卡在技术难点上，实际上呢，是技术负责人和产品经理在争谁对这个项目的解释权更大。两个人都不明说，但所有的会议都在旁敲侧击。那时候我才明白，项目进度表上的每一条延误，背后可能都是一场微型的权力拉扯。你不去正视这种拉扯，只是把里程碑往后推，那项目就会变成一场漫长的相互消耗。
所以我现在带项目，最先做的不是建WBS，也不是挑模板，而是跟每个人聊一句：“你觉得这个项目里，哪件事是做了也白做的？”很多人会愣住，但这个问题会逼他们说出那些被所谓流程掩盖的废话工作。然后我让团队把那些“白做的事”列成清单，我们每周专门拿出一小时，专门干一件“注定失败的小事”——比如用一个笨办法做个一次性工具，或者故意把设计稿改成最丑的样子给用户看。听起来很蠢，但这么做会让团队对“错误的嗅觉”变灵敏。当大家不再害怕犯错，错误的成本反而降下来了。项目管理的终极能力，大概就是别把项目当成一条需要精雕细琢的笔直线，而是当成一片可以快速踩雷的田野——你踩的雷越多，后面走的路反而越安全。