為什么資深工程師會放任糟糕項目失敗？

在大公司里待久了，很多工程師都會有一種相似的體驗：你越來越早地看出某些項目哪里不對勁，卻越來越少地選擇開口。不是因為看不出來問題，而是因為你已經見過太多“明明邏輯上站不住腳，卻依然按既定軌道一路向前”的項目。

技術討論往往只是表層，真正決定一個項目命運的，常常是組織結構、資源分配、晉升機制，以及那些沒人寫進設計文檔里的隱性規則。于是，一些項目在技術上并不差，卻從一開始就注定難以落地；另一些問題顯而易見，卻始終沒人愿意成為第一個站出來“潑冷水”的人。

隨著資歷增長，工程師開始意識到一個更現實的問題：在復雜組織里，“說對的話”并不等于“能產生效果”。影響力是有限的，發聲是有成本的，而大多數失敗項目，并不是缺少聰明人，而是缺少合適的時機、位置和方式去阻止它。

下面這篇文章，正是基于一位 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（回報率）太低了——政治因素太多，或者問題太小，不值得消耗任何影響力。此時該怎么做，取決于你的團隊被卷入的程度。

如果它和你們團隊的工作關系很大，比較穩妥的做法，是私下提前做點準備：要么慢慢降低對它的依賴，要么在外面套一層抽象，防著哪天它突然“沒了”。還有一種更偏長期的思路：就算是糟糕的項目，往往也藏著一點“好點子”——可能是它想解決的問題本身，或者背后的某種判斷。如果這正好和你的工作相關，不妨把這個內核單獨拎出來，看看能不能在自己的項目里，用更自然、更靠譜的方式重新實現一遍。這樣一來，等那個糟糕項目真的停擺或被砍時，你是在提前應對，而不是臨時救火。

如果你本來就沒直接參與，那事情反而簡單：離遠一點就好。私下里和熟悉的同事吐吐槽、互相安慰；在公開場合，就接受現實，別摻和進去。

帶著你的團隊一起走過這段過程

最后，你還需要管理好自己的團隊。如果你能看出一個項目的問題，其他資深工程師多半也看得出來。不要試圖給他們“洗腦”，也不要為了迎合公司而假裝一個糟糕的項目其實很好——那只會摧毀信任。

更好的做法是：坦誠地說明現實情況，不必深入那些不必要的政治細節，告訴他們你會在這些約束下盡力而為。

結語

那我最后是怎么回答那位被我指導的同事的？

“我學到的一點是：正確和有效不是一回事。我可以去告訴他們我的擔憂，但他們大概率不會聽。我會消耗掉一些善意。六個月后，沒人會記得我是對的，只會記得我是那個試圖阻止他們工作的人。”

在職業早期，你很容易相信：好點子會憑實力勝出，只要解釋得足夠清楚，大家總會講道理。我花了很長時間，才接受一個現實：大公司并不是這樣運作的。

但這并不意味著你就不再關心了。它意味著你要更有策略地使用自己的信譽。選擇那些你真的能改變結果的戰斗：沉默會傷害你團隊的戰斗；你出錯的成本很低，但項目失敗代價極高的戰斗。

至于剩下的呢？

和同事私下吐槽，悄悄準備預案，然后觀察。有時候你會學到新東西；有時候你會發現自己錯了，項目真的成功了；還有的時候，你會帶著一點苦澀的滿足感，看著事情精準地按你當初預判的方式崩塌。

這當然不如“修好一切”來得痛快。但它確實有效，也讓我還能保持清醒。