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

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

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

下面這篇文章，正是基于一位 Google 資深工程師在 Google 工作 9 年的親身經(jīng)歷，講清楚了兩個問題：為什么你不可能阻止所有糟糕項目，以及在現(xiàn)實世界中，工程師該如何更理性地使用自己的判斷力和影響力。

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

作者 | Lalit Maganti 責編 | 蘇宓

出品 | CSDN（ID：CSDNnews）

當年在我還是一名初級工程師的時候，我的經(jīng)理偶爾會在每周 1 對 1 的會議上向我傾訴他的一些不滿。他會指著另一個團隊正在做的項目，說：“我覺得這個項目不會成功，因為他們一開始就選錯了要解決的問題�！�

那時我常常會想：“既然你資歷這么深了，為什么不直接去跟他們談談你的擔憂呢？”在我看來，他明明有影響力，卻什么都不說，實在有點浪費。

頗具諷刺意義的是，就在上周，我也在向一位被我指導的同事解釋，為什么我覺得兄弟團隊的一個項目遲早要調(diào)整方向，因為他們的早期設計選擇存在缺陷。結果，我?guī)У倪@個工程師理所當然地問了我一個和我當年一模一樣的問題：“那你為什么不直接把你的看法告訴他們？”

這幾天，他的這個反問一直縈繞在我的腦海里，因為我意識到，這些年我對這件事的看法已經(jīng)發(fā)生了很大的變化。

根本答案其實是：正確和有效其實是兩回事。

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

有時候，所謂的資深，恰恰體現(xiàn)在你能意識到：和那些根本不會聽的人爭論，并不值得；你的判斷力，應該留在更合適的地方使用。

什么是“糟糕的項目”

我所說的“糟糕項目”，可能體現(xiàn)在很多方面：

• 用戶體驗層面（UX）：把產(chǎn)品做復雜了、再解決一個并不存在的問題、破壞了已有的工作流

• 技術層面：設計過度復雜、選錯技術棧、架構性能糟糕

• 政策層面：追逐風口、項目存在的主要目的只是為了支撐一次晉升

需要強調(diào)的是，在項目生命周期的很長一段時間里，一個項目到底“糟不糟”，其實是高度主觀做出的判斷。

軟件工程本質(zhì)上是一連串取舍的過程：這并不是要求所有工程師起初都能做出完美決定，而是在信息有限的情況下做出當下最合理的選擇。不同的工程師完全可能在這些選擇上產(chǎn)生分歧，而真相往往要到很久以后才會顯現(xiàn)——有時甚至是項目上線多年之后。

經(jīng)驗多了之后，你會對軟件項目產(chǎn)生一種很難解釋的“感覺”。有些項目一擺在你面前，你就會下意識地覺得：這事不太妙。

在我看來，這正是“糟糕項目”的征兆——還沒等問題全面爆發(fā)，你心里已經(jīng)大概知道它會怎么收場。

從我個人經(jīng)歷來看，最讓我印象深刻的一次發(fā)生在幾年前的 Google。

當時 Google 公司內(nèi)部高調(diào)宣布了一個“顛覆性”的項目，該項目牽扯到兩個規(guī)模極其龐大的組織。從技術角度來看，這一項目非常驚艷，設計優(yōu)雅，充滿了應對復雜問題的巧妙想法。

但我清楚地記得，發(fā)布會現(xiàn)場我轉(zhuǎn)頭對我的主管小聲說了一句：“這個項目根本不可能成功，對吧？”

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

我們當場就意識到了問題所在：這個項目的前提，是讓一個平臺團隊去要求一個旗艦產(chǎn)品團隊放棄對其核心用戶流程的控制權。

從技術上講，這確實是正確的選擇；但在現(xiàn)實中，沒有任何負責人或產(chǎn)品經(jīng)理會把如此核心的東西交給另一個團隊。在政治層面，這個項目從一開始就是一場幻想。

果不其然，該項目隨后在后臺默默推進了將近兩年。每次快要上線時，都會被以“還沒準備好”為由推遲。漸漸地，關于它的消息越來越少，直到有一天，我的郵箱里收到了那封幾乎不可避免的“戰(zhàn)略轉(zhuǎn)向”郵件：資源被重新分配，代碼被刪除。官方說法是公司“從這次嘗試中學到了很多”，但在我看來，它從一開始就注定失敗。

技術上的優(yōu)雅固然重要，但政治現(xiàn)實，以及是否真正解決了正確的問題，同樣重要，甚至同樣致命。

為什么你無法阻止他們所有人

當我開始逐漸注意到這些“糟糕項目”，也覺得自己多少有些經(jīng)驗可以分享時，我很自然地產(chǎn)生了一種沖動：把它們一個個指出來。主動聯(lián)系負責項目的團隊，直接告訴他們“這事不太對勁”，再用事實和邏輯解釋原因，試圖說服對方。

我確實這么做過——但時間并不長。很快我就意識到，這種做法背后的成本，遠遠超出了我最初的預期。

首先，軟件公司天生就傾向于“快速行動”。速度和交付被高度重視，而“擔憂”本身就意味著減速，意味著要重新審視那些原本沒有納入計劃的事情。所以，除非你的問題嚴重到足以壓過那股“先上線再說”的慣性，否則你開口的結果，大概率不會帶來任何實質(zhì)改變。更現(xiàn)實的情況是：你很可能會被直接忽略。

與此相關的還有一個問題：就算對方認真對待了你的意見，這種事也不能做得太頻繁。一兩次，你可能會被視為“在把關質(zhì)量的人”；次數(shù)多了，很快就會被貼上“負能量”“總是找麻煩”的標簽——一個制造問題的人，而不是解決問題的人。更殘酷的是，你很少會因為阻止了“災難的發(fā)生”而獲得認可。因為什么都沒發(fā)生，大家很快就忘了這件事。

此外，每一次反對，都有可能直接影響到某個人的晉升材料，或者某位 VP 的“心頭好項目”。你可能會因此燒掉一些橋梁，甚至結下一些“敵人”。在大公司里，有少數(shù)人不同意你是正常的業(yè)務成本；但如果這樣的人太多，它就會開始反過來影響你自己的本職工作。

最后，還有心理層面的消耗。你只有一個人，而公司里有成百上千名工程師，分布在你“也許能幫得上忙”的各個角落。你的精力是有限的，但大公司制造糟糕想法的能力幾乎是無限的。

以我的親身經(jīng)驗來說，過度投入到“阻止壞項目”這件事里，很容易讓人變得憤世嫉俗，對整個世界失去耐心——而這絕對不是一個好的狀態(tài)。

像管理銀行賬戶一樣管理影響力

既然你不可能阻止所有糟糕項目，那該怎么辦？答案是：變得更有策略。

不要試圖修復一切，而是把你的影響力當作一個銀行賬戶。每個月，你都會因為認真工作、幫助同事、成功交付項目、減少摩擦而獲得一些“影響力收入”。

而當真正重要的時刻到來，你需要準備好“取款”。每一次你提出反對或表達擔憂——無論多小——本質(zhì)上都是在開一張支票。但不同的支票，面額差別很大：

• 5 美元支票：在代碼評審里摳一個小細節(jié)。便宜，日常開銷。
  

• 500 美元支票：挑戰(zhàn)一個架構決策，或?qū)椖抗?jié)奏提出異議。需要一定積蓄。

• 5 萬美元支票：試圖干掉一個 VP 的“寵物項目”。這是一次巨額支出，可能幾年才負擔得起一次。

真正的問題出現(xiàn)在：你把每一個微小的低效都當成 5 美元花掉。如果你對所有小事都說“不”，那么當真正需要開出那張大額支票、去阻止一場真正的災難時，你的賬戶早就空了。

一旦“透支”，你就進入了政治破產(chǎn)狀態(tài)。人們不再邀請你參加會議，不再征求你的意見，開始繞開你做事。破產(chǎn)之后，你的影響力會迅速歸零——不僅無法再影響方向，甚至會開始影響你自己把事情做成的能力。

什么時候該花這筆“影響力”

既然我們已經(jīng)接受了“不可能對所有事情都發(fā)聲”這個現(xiàn)實，接下來就要判斷：什么時候值得出手。

第一步，是保持謙遜，認真評估自己是否真的具備判斷的專業(yè)能力。資深往往會帶來很多觀點，但這些觀點并不一定都是建立在深度經(jīng)驗之上的。

舉個例子：我有一些前端經(jīng)驗，但我并不認為自己有資格給出深入的前端建議——我的知識只是“夠用”，而不是那種長期負責、反復踩坑積累出來的深度理解。高質(zhì)量的判斷，離不開高質(zhì)量的信息來源。如果你意識到自己只是一個“有看法的旁觀者”，那就停在這里。

你還必須真正接受一個事實：你說出來的話，并不等于真理。你是在提出一種視角，而不是下達命令。所以，如果某個團隊聽完你的擔憂，依然決定按原計劃推進，你需要接受這個結果，然后繼續(xù)前行——說到底，你只是工程師，不是對他們有直接權力的 CEO。

在這些前提下，我通常用三個因素來決定是否要開口：

1. 這個項目離我的團隊有多近？

2. 如果它失敗，對我的團隊影響有多大？

3. 如果它失敗，對整個公司的影響有多大？

距離感。

項目越接近你，開口的“價格”就越低。如果是在你自己的團隊里，成本幾乎為零——信任基礎高，一次快速溝通往往就能解決問題。如果是在你所在的大組織內(nèi)，成本就會上升：你需要消耗社會資本，甚至押上個人聲譽。若是完全在組織之外？那成本往往高得無法承受。你幾乎沒有杠桿，不同的匯報鏈條，想要阻止它，意味著一次巨額取款。

團隊影響。

有時，別的團隊做的事情會深度影響你的工作。以我負責的 Perfetto（性能分析工具）為例，它在 Google 內(nèi)部有大量用戶，有時會有團隊希望我們?yōu)橐粋�非常復雜的集成方案“背書”。這是一種典型風險：事情順利，他們拿功勞；一旦出問題，你的管理層可能會指望你去幫忙收拾一個并非你造成的爛攤子。在這種情況下，開口的收益很高，因為你是在保護自己的團隊。

公司層級

最后要看“爆炸半徑”。有些項目是自洽的，失敗了也只是自己倒下；另一些則深度耦合在核心系統(tǒng)里，一旦失敗，會造成廣泛破壞，或者留下多年難以清理的技術債。這類項目，對長期健康來說是致命的。

面對糟糕項目，具體該怎么做

不僅要考慮什么時候表達意見，還要考慮怎么表達。根據(jù)具體情境，可采取的行動范圍非常大。

當你選擇介入

最激進的做法，是直接說：“這事不該做”，并嘗試徹底叫停項目。這幾乎總是需要向上升級，牽涉到你和對方團隊的負責人，也要求你對“自己是對的”以及“這個項目會造成實質(zhì)傷害”有極強的確信。在某些情況下，這是唯一正確的選擇，尤其是當沉默可能對你的項目或團隊造成致命后果時。

稍微溫和、但依然風險不小的做法，是不直接升級，而是直接向項目團隊提出強烈關切。通常表現(xiàn)為一次嚴肅的會議，或一份措辭強硬的“擔憂/反駁”文檔。目標不是強行否定，而是讓團隊自己得出結論：這個項目也許并不是一個好主意。

再往下，就是更小尺度的干預——把事情往正確方向“推一推”。這很適合那些“方向沒錯，但方式不對”的情況。我在 Perfetto 上經(jīng)常遇到：有團隊提交設計文檔，提出一種我一看就知道未來會很痛苦的復雜用法。我會和他們坐下來，理解他們真正的問題，然后引導他們走向一個更好的解決方案�；ㄒ粋�小時，省下幾個月。如果做得好，你甚至會被視為“幫忙的人”，而不是拖慢進度的阻礙者。

當你選擇不介入

有時你會得出結論：直接介入的 ROI（回報率）太低了——政治因素太多，或者問題太小，不值得消耗任何影響力。此時該怎么做，取決于你的團隊被卷入的程度。

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

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

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

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

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

結語

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

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

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

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

至于剩下的呢？

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

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