为什么资深工程师会放任糟糕项目失败？|工程师

在大公司里待久了，很多工程师都会有一种相似的体验：你越来越早地看出某些项目哪里不对劲，却越来越少地选择开口。不是因为看不出来问题，而是因为你已经见过太多“明明逻辑上站不住脚，却依然按既定轨道一路向前”的项目。

技术讨论往往只是表层，真正决定一个项目命运的，常常是组织结构、资源分配、晋升机制，以及那些没人写进设计文档里的隐性规则。于是，一些项目在技术上并不差，却从一开始就注定难以落地；另一些问题显而易见，却始终没人愿意成为第一个站出来“泼冷水”的人。

随着资历增长，工程师开始意识到一个更现实的问题：在复杂组织里，“说对的话”并不等于“能产生效果”。影响力是有限的，发声是有成本的，而大多数失败项目，并不是缺少聪明人，而是缺少合适的时机、位置和方式去阻止它。

下面这篇文章，正是基于一位 Google 资深工程师在 Google 工作 9 年的亲身经历，讲清楚了两个问题：为什么你不可能阻止所有糟糕项目，以及在现实世界中，工程师该如何更理性地使用自己的判断力和影响力。

来源：https://lalitm.com/post/why-senior-engineers-let-bad-projects-fail/

作者 | Lalit Maganti 责编 | 苏宓

出品 | CSDN（ID：CSDNnews）

当年在我还是一名初级工程师的时候，我的经理偶尔会在每周 1 对 1 的会议上向我倾诉他的一些不满。他会指着另一个团队正在做的项目，说：“我觉得这个项目不会成功，因为他们一开始就选错了要解决的问题。”

那时我常常会想：“既然你资历这么深了，为什么不直接去跟他们谈谈你的担忧呢？”在我看来，他明明有影响力，却什么都不说，实在有点浪费。

颇具讽刺意义的是，就在上周，我也在向一位被我指导的同事解释，为什么我觉得兄弟团队的一个项目迟早要调整方向，因为他们的早期设计选择存在缺陷。结果，我带的这个工程师理所当然地问了我一个和我当年一模一样的问题：“那你为什么不直接把你的看法告诉他们？”

这几天，他的这个反问一直萦绕在我的脑海里，因为我意识到，这些年我对这件事的看法已经发生了很大的变化。

根本答案其实是：正确和有效其实是两回事。

在大公司里，指出你眼中“有问题的项目”本身是一件好事，但前提是要有分寸。

有时候，所谓的资深，恰恰体现在你能意识到：和那些根本不会听的人争论，并不值得；你的判断力，应该留在更合适的地方使用。

什么是“糟糕的项目”

我所说的“糟糕项目”，可能体现在很多方面：

用户体验层面（UX）：把产品做复杂了、再解决一个并不存在的问题、破坏了已有的工作流
技术层面：设计过度复杂、选错技术栈、架构性能糟糕
政策层面：追逐风口、项目存在的主要目的只是为了支撑一次晋升

需要强调的是，在项目生命周期的很长一段时间里，一个项目到底“糟不糟”，其实是高度主观做出的判断。

软件工程本质上是一连串取舍的过程：这并不是要求所有工程师起初都能做出完美决定，而是在信息有限的情况下做出当下最合理的选择。不同的工程师完全可能在这些选择上产生分歧，而真相往往要到很久以后才会显现——有时甚至是项目上线多年之后。

经验多了之后，你会对软件项目产生一种很难解释的“感觉”。有些项目一摆在你面前，你就会下意识地觉得：这事不太妙。

在我看来，这正是“糟糕项目”的征兆——还没等问题全面爆发，你心里已经大概知道它会怎么收场。

从我个人经历来看，最让我印象深刻的一次发生在几年前的 Google。

当时 Google 公司内部高调宣布了一个“颠覆性”的项目，该项目牵扯到两个规模极其庞大的组织。从技术角度来看，这一项目非常惊艳，设计优雅，充满了应对复杂问题的巧妙想法。

但我清楚地记得，发布会现场我转头对我的主管小声说了一句：“这个项目根本不可能成功，对吧？”

他看了我一眼，只回了一个字：“嗯。”

我们当场就意识到了问题所在：这个项目的前提，是让一个平台团队去要求一个旗舰产品团队放弃对其核心用户流程的控制权。

从技术上讲，这确实是正确的选择；但在现实中，没有任何负责人或产品经理会把如此核心的东西交给另一个团队。在政治层面，这个项目从一开始就是一场幻想。

果不其然，该项目随后在后台默默推进了将近两年。每次快要上线时，都会被以“还没准备好”为由推迟。渐渐地，关于它的消息越来越少，直到有一天，我的邮箱里收到了那封几乎不可避免的“战略转向”邮件：资源被重新分配，代码被删除。官方说法是公司“从这次尝试中学到了很多”，但在我看来，它从一开始就注定失败。

技术上的优雅固然重要，但政治现实，以及是否真正解决了正确的问题，同样重要，甚至同样致命。

为什么你无法阻止他们所有人

当我开始逐渐注意到这些“糟糕项目”，也觉得自己多少有些经验可以分享时，我很自然地产生了一种冲动：把它们一个个指出来。主动联系负责项目的团队，直接告诉他们“这事不太对劲”，再用事实和逻辑解释原因，试图说服对方。

我确实这么做过——但时间并不长。很快我就意识到，这种做法背后的成本，远远超出了我最初的预期。

首先，软件公司天生就倾向于“快速行动”。速度和交付被高度重视，而“担忧”本身就意味着减速，意味着要重新审视那些原本没有纳入计划的事情。所以，除非你的问题严重到足以压过那股“先上线再说”的惯性，否则你开口的结果，大概率不会带来任何实质改变。更现实的情况是：你很可能会被直接忽略。

与此相关的还有一个问题：就算对方认真对待了你的意见，这种事也不能做得太频繁。一两次，你可能会被视为“在把关质量的人”；次数多了，很快就会被贴上“负能量”“总是找麻烦”的标签——一个制造问题的人，而不是解决问题的人。更残酷的是，你很少会因为阻止了“灾难的发生”而获得认可。因为什么都没发生，大家很快就忘了这件事。

此外，每一次反对，都有可能直接影响到某个人的晋升材料，或者某位 VP 的“心头好项目”。你可能会因此烧掉一些桥梁，甚至结下一些“敌人”。在大公司里，有少数人不同意你是正常的业务成本；但如果这样的人太多，它就会开始反过来影响你自己的本职工作。

最后，还有心理层面的消耗。你只有一个人，而公司里有成百上千名工程师，分布在你“也许能帮得上忙”的各个角落。你的精力是有限的，但大公司制造糟糕想法的能力几乎是无限的。

以我的亲身经验来说，过度投入到“阻止坏项目”这件事里，很容易让人变得愤世嫉俗，对整个世界失去耐心——而这绝对不是一个好的状态。

像管理银行账户一样管理影响力

既然你不可能阻止所有糟糕项目，那该怎么办？答案是：变得更有策略。

不要试图修复一切，而是把你的影响力当作一个银行账户。每个月，你都会因为认真工作、帮助同事、成功交付项目、减少摩擦而获得一些“影响力收入”。

而当真正重要的时刻到来，你需要准备好“取款”。每一次你提出反对或表达担忧——无论多小——本质上都是在开一张支票。但不同的支票，面额差别很大：

5 美元支票：在代码评审里抠一个小细节。便宜，日常开销。
500 美元支票：挑战一个架构决策，或对项目节奏提出异议。需要一定积蓄。
5 万美元支票：试图干掉一个 VP 的“宠物项目”。这是一次巨额支出，可能几年才负担得起一次。

真正的问题出现在：你把每一个微小的低效都当成 5 美元花掉。如果你对所有小事都说“不”，那么当真正需要开出那张大额支票、去阻止一场真正的灾难时，你的账户早就空了。

一旦“透支”，你就进入了政治破产状态。人们不再邀请你参加会议，不再征求你的意见，开始绕开你做事。破产之后，你的影响力会迅速归零——不仅无法再影响方向，甚至会开始影响你自己把事情做成的能力。

什么时候该花这笔“影响力”

既然我们已经接受了“不可能对所有事情都发声”这个现实，接下来就要判断：什么时候值得出手。

第一步，是保持谦逊，认真评估自己是否真的具备判断的专业能力。资深往往会带来很多观点，但这些观点并不一定都是建立在深度经验之上的。

举个例子：我有一些前端经验，但我并不认为自己有资格给出深入的前端建议——我的知识只是“够用”，而不是那种长期负责、反复踩坑积累出来的深度理解。高质量的判断，离不开高质量的信息来源。如果你意识到自己只是一个“有看法的旁观者”，那就停在这里。

你还必须真正接受一个事实：你说出来的话，并不等于真理。你是在提出一种视角，而不是下达命令。所以，如果某个团队听完你的担忧，依然决定按原计划推进，你需要接受这个结果，然后继续前行——说到底，你只是工程师，不是对他们有直接权力的 CEO。

在这些前提下，我通常用三个因素来决定是否要开口：

1. 这个项目离我的团队有多近？

2. 如果它失败，对我的团队影响有多大？

3. 如果它失败，对整个公司的影响有多大？

距离感。

项目越接近你，开口的“价格”就越低。如果是在你自己的团队里，成本几乎为零——信任基础高，一次快速沟通往往就能解决问题。如果是在你所在的大组织内，成本就会上升：你需要消耗社会资本，甚至押上个人声誉。若是完全在组织之外？那成本往往高得无法承受。你几乎没有杠杆，不同的汇报链条，想要阻止它，意味着一次巨额取款。

团队影响。

有时，别的团队做的事情会深度影响你的工作。以我负责的 Perfetto（性能分析工具）为例，它在 Google 内部有大量用户，有时会有团队希望我们为一个非常复杂的集成方案“背书”。这是一种典型风险：事情顺利，他们拿功劳；一旦出问题，你的管理层可能会指望你去帮忙收拾一个并非你造成的烂摊子。在这种情况下，开口的收益很高，因为你是在保护自己的团队。

公司层级

最后要看“爆炸半径”。有些项目是自洽的，失败了也只是自己倒下；另一些则深度耦合在核心系统里，一旦失败，会造成广泛破坏，或者留下多年难以清理的技术债。这类项目，对长期健康来说是致命的。

面对糟糕项目，具体该怎么做

不仅要考虑什么时候表达意见，还要考虑怎么表达。根据具体情境，可采取的行动范围非常大。

当你选择介入

最激进的做法，是直接说：“这事不该做”，并尝试彻底叫停项目。这几乎总是需要向上升级，牵涉到你和对方团队的负责人，也要求你对“自己是对的”以及“这个项目会造成实质伤害”有极强的确信。在某些情况下，这是唯一正确的选择，尤其是当沉默可能对你的项目或团队造成致命后果时。

稍微温和、但依然风险不小的做法，是不直接升级，而是直接向项目团队提出强烈关切。通常表现为一次严肃的会议，或一份措辞强硬的“担忧/反驳”文档。目标不是强行否定，而是让团队自己得出结论：这个项目也许并不是一个好主意。

再往下，就是更小尺度的干预——把事情往正确方向“推一推”。这很适合那些“方向没错，但方式不对”的情况。我在 Perfetto 上经常遇到：有团队提交设计文档，提出一种我一看就知道未来会很痛苦的复杂用法。我会和他们坐下来，理解他们真正的问题，然后引导他们走向一个更好的解决方案。花一个小时，省下几个月。如果做得好，你甚至会被视为“帮忙的人”，而不是拖慢进度的阻碍者。

当你选择不介入

有时你会得出结论：直接介入的 ROI（回报率）太低了——政治因素太多，或者问题太小，不值得消耗任何影响力。此时该怎么做，取决于你的团队被卷入的程度。

如果它和你们团队的工作关系很大，比较稳妥的做法，是私下提前做点准备：要么慢慢降低对它的依赖，要么在外面套一层抽象，防着哪天它突然“没了”。还有一种更偏长期的思路：就算是糟糕的项目，往往也藏着一点“好点子”——可能是它想解决的问题本身，或者背后的某种判断。如果这正好和你的工作相关，不妨把这个内核单独拎出来，看看能不能在自己的项目里，用更自然、更靠谱的方式重新实现一遍。这样一来，等那个糟糕项目真的停摆或被砍时，你是在提前应对，而不是临时救火。

如果你本来就没直接参与，那事情反而简单：离远一点就好。私下里和熟悉的同事吐吐槽、互相安慰；在公开场合，就接受现实，别掺和进去。

带着你的团队一起走过这段过程

最后，你还需要管理好自己的团队。如果你能看出一个项目的问题，其他资深工程师多半也看得出来。不要试图给他们“洗脑”，也不要为了迎合公司而假装一个糟糕的项目其实很好——那只会摧毁信任。

更好的做法是：坦诚地说明现实情况，不必深入那些不必要的政治细节，告诉他们你会在这些约束下尽力而为。