工程师救火项目是否值得：有些项目该让它失败

有些项目就该失败

想救一个项目，就派你最好的工程师去。他们总能找到出路。他们会联系对的人，深入钻研自己并不熟悉的代码路径，协调依赖关系，把谁负责什么理清楚，然后开始走一条艰难的路。一个月前看起来不可能交付的东西，他们最终会交付出来。最后，你的工程师得到认可，大家继续往前走。

到了下半年，你又遇到一个急需抢救的项目。你犹豫要不要介入，要不要请你那位明星工程师出手。你知道他们又会搞定。问题不在这里。问题是，这个项目到底值不值得救。

当你认为一个脆弱的项目撑不下去时，也许你应该让自己别再往一艘沉船上投钱。可因为已经花了六个月，你最终又投了三个月，因为你有人能救它。是的，它确实救活了，但你为什么要这么做？

你把两位最好的工程师重新分配到一个也许本该失败的项目上。你打断了他们正在进行的工作，而那些工作很可能同样重要。因为你救了项目，你可能还从救援过程中所做的妥协里继承了一堆新的运营问题。更糟的是，你教会了你最好的人：能力的奖励，就是被丢进别人搞出的烂摊子里。

高管们不会再关心，因为项目已经交付了。交付过程中发生了什么，连同教训一起消失了。它当初为什么会失败？人的问题、糟糕的判断、时间线压力？不管原因是什么，通过介入，你可能已经失去了理解它的机会，并向所有人发出了错误的信号。如果救援的代价一直藏在地毯下面，那就几乎没有什么理由去质疑那些让救援变得必要的决策。项目被标记为已交付，而现实中它本该被叫停。这种荒唐事重复几次，英雄主义就会不知不觉变成日常操作。最终，你的规划变得次要，因为你整天在处理“已知”的紧急情况。

那么，我们到底要不要救项目？我觉得得回到沉没成本谬误上。保持简单，问一句：继续下去，真的能比让它失败带来更好的结果吗？把我们最好的工程师拉进来，我们是否获得了更好的业务结果？他们的时间是有双重代价的。第一，他们停下的工作；第二，他们上手之前花在熟悉上的时间。如果预期收益能证明这些代价合理，那就行。该做就得做。

如果经济账算不过来了，项目就该失败。领导层应该收到正确的信号。有些项目就该闹出足够大的动静，告诉所有人：不是所有事都能以干活的人为代价去实现。一个看得见的失败，至少能开启一场诚实的对话，而不是激励英雄主义。

让一个项目失败，不保证任何人能从中学习；但救活它，就保证没人会去尝试学习。当你准备打出“最好的工程师”这张牌时，停一下，问自己：你真正在保护的，是业务结果，还是那些做出糟糕决定的人——包括你自己？