谷歌工程師3月復盤：7成ML項目栽在同一個坑里

3月結束，谷歌一位機器學習工程師在內部復盤會上甩出一組數字：他跟蹤的23個項目里，16個卡在"等人批"環節，平均延誤11天。不是模型調不通，不是數據出問題，是流程卡住了。

這事聽起來像職場老梗，但他把過程全記了下來。讀完你會發現，ML項目的死亡方式比你想象的更無聊。

「主動」是塊遮羞布，真正缺的是時間主權

這位工程師叫Tim，在谷歌做ML基礎設施。他3月初同時推進5個項目：一個要采購新GPU集群，兩個等法務審數據協議，一個等安全團隊開白名單，還有一個卡在預算審批。

Tim的應對很標準——提前發郵件、抄送老板、設日歷提醒。他管這叫"proactivity（主動性）"，是我們從小被夸的品質。但到3月第三周，5個項目全黃了，沒一個按時推進。

問題出在哪？他復盤時發現一個規律：每個項目都被切割成碎片，塞進別人的日程縫隙里。等安全團隊回復時，他切去寫另一個項目的文檔；等預算審批時，又去開會同步第三個項目的進度。一天下來，所有項目都在"進行中"，沒有一個在"推進中"。

Tim的日歷截圖顯示，3月第二周他有37個會議，其中28個與項目推進無直接關系。剩下9個"相關會議"里，只有3個是他主動發起的，其余是"被同步""被拉齊""被通知"。

他算了一筆賬：一個需要4小時深度工作的模型優化任務，被拆成8個30分鐘碎片，橫跨6天完成。實際有效工作時間2.5小時，上下文切換成本1.5小時。效率折損37%，還不算返工。

阻塞的本質：你的項目在別人優先級列表的第幾頁

ML項目有個特點：越往后期，對外部團隊的依賴越重。訓練階段可以關起門來調參，部署階段必須和安全、法務、運維、客戶 success 逐個握手。

Tim發現，這些"握手"的阻塞點高度集中。他統計的23個項目里，16個卡在"等待外部審批或資源"，占比70%。其中：

? 等安全評審：平均7天（承諾3天）
? 等法務審協議：平均14天（承諾5天）
? 等采購審批：平均21天（承諾10天）
? 等計算資源配額：平均5天（承諾2天）

承諾時間和實際時間的差距，Tim稱為"優先級幻覺"。對方口頭說"下周處理"，意思是"下周你的事會進入我的待辦列表"，而非"下周你會拿到結果"。

更隱蔽的是"軟阻塞"——事情在推進，但每步都要你親自催。Tim有個項目等安全團隊開白名單，對方確實在走流程，但流程有7步，每步需要他發郵件確認"是否到我了"。他發了11封跟進郵件，項目延期9天。

這種阻塞最難防。它不像"對方完全不理你"那樣容易識別，而是給你一種"在推進"的錯覺，直到 deadline 逼近才發現進度條是空的。

時間塊的暴力美學：把別人的事擠出你的日歷

Tim的解法很樸素，但執行起來需要一點狠勁：blocking，也就是"時間塊保護"。

具體操作：每周一上午，他在日歷上劃出3塊"不可侵犯時間"，每塊2-3小時，標注為"focus work"。這段時間內，郵件通知關、Slack 狀態設成"深度工作中"、手機扔抽屜。

關鍵是下一步：他主動給所有可能阻塞他的人發郵件，說明"我需要在X日前拿到Y，為此我將在周二下午2-4點專門處理相關事項，請提前準備或屆時同步"。

這不是在求對方配合，是在重新定義游戲規則。把"我等你"變成"我們約個時間一起解決"，把異步等待變成同步碰撞。

3月第四周，Tim用這個方法推進了2個卡了半個月的項目。一個安全評審從"排隊中"變成"周二下午現場過"，一個采購審批從"等老板簽字"變成"周四上午我直接去你工位"。

代價是得罪了兩個人。一位安全工程師在內部論壇吐槽"有人把評審當急診"，一位行政同事抱怨"突然要改日程"。Tim的回應是：在項目群里公開道歉，但繼續 block 下周的時間。

Plan B 不是備用方案，是主方案的一部分

時間塊解決的是"當下怎么推進"，但ML項目的周期往往以月計。Tim的第三個教訓是 planning，而且是一種帶點偏執的 planning。

他現在的習慣：任何需要外部依賴的任務，必須同時準備兩條路徑。

路徑A（理想情況）：按承諾時間拿到資源，按計劃推進。
路徑B（實際情況）：承諾時間翻倍，中間插入3次跟進，最終延期交付。

路徑B不是"萬一A失敗了怎么辦"，而是被當作默認假設寫進計劃。Tim說，他現在的項目文檔里，路徑B的篇幅是路徑A的3倍，包括具體跟進步驟、替代資源清單、以及如果完全拿不到資源時的"優雅降級"方案。

一個例子：某項目需要特定型號的GPU，正常采購周期4周。路徑A按4周排期，路徑B假設采購被拒，準備用現有資源做分布式訓練改造（增加2周開發時間，但保證不阻塞）。實際執行中，采購確實被拒，團隊無縫切換到B方案，最終延期2周而非6周。

這種 planning 的副作用是文檔變厚、會議變多、前期投入增加。Tim算過，一個項目的"規劃 overhead"從原來的8小時增加到15小時，但項目準時交付率從40%提升到75%。

他反問：你愿意多花7小時規劃，還是愿意在項目延期后花20小時救火？

Tim的3月復盤在公司內部小范圍流傳，有人留言說"這不就是項目管理101嗎"，也有人吐槽"谷歌流程病入膏肓，個人技巧治標不治本"。

但一個細節被很多人忽略：Tim在復盤最后附了一張圖，是他3月最后一周的日歷——上面有四塊連續的空白，標注著"預留緩沖，暫無安排"。

在谷歌，空白日歷比滿檔日歷更少見。這4塊空白是干嘛的？Tim沒說。可能是給突發阻塞留的應急時間，可能是給團隊突發奇想留的實驗窗口，也可能只是他想證明自己還能掌控點什么。

如果你現在打開自己的日歷，下周有多少塊連續2小時以上的空白？如果答案是零，你的下一個ML項目會卡在哪一步——你心里其實有數吧？