engineering

我在科技大廠的專案交付心法

交付專案不容易，首要任務是讓領導團隊滿意

Photo by Anna Samoylova / Unsplash

原文: How I ship projects at big tech companies
作者: Sean Goedecke

過去十年，我在科技業交付過許多專案。每當專案攸關重大，需要確保成功時，我常被指派領導，因為我擅長此事。在大型科技公司交付專案，和寫程式是截然不同的技能，很多寫程式高手都不擅長交付。

以下是我領導專案的思考方式，以及我觀察到大家常犯的錯誤。

交付不容易

最常見的錯誤，就是以為交付很簡單。專案的預設狀態其實是「無法交付」：無限期延宕、取消，或推出半成品後慘遭滑鐵盧。專案不會寫完程式、關閉所有 Jira 單就自動交付。專案能交付，是因為有人扛起這份吃力不討好的工作。

這表示幾乎所有情況下，交付都必須是首要任務。你不能有其他優先事項。如果你花所有時間琢磨使用者體驗（例如），你就無法交付！身為團隊工程師，鑽研 UX 固然值得嘉許，但身為專案負責人，這就是本末倒置。你應該珍惜團隊中負責 UX 的工程師，並盡力支援他們。但你的首要之務，必須是交付專案。這份工作太難，你沒辦法用剩餘時間兼顧。

根據我的經驗，專案幾乎都是靠一個人撐到最後才得以交付。當然，這不代表此人寫了所有程式或做了所有工作，也不代表沒有團隊合作就能交付。

重點是，專案中必須有一個人對全局有完整的掌握：技術架構如何，以及它服務的產品或商業目標是什麼。好的團隊和公司都懂這點，會確保每個專案都有一位負責的工程師（通常稱為「技術主管」或「 DRI 」）。不好的團隊和公司則不會這樣做，專案的成敗取決於是否有工程師自願扛起這個責任。

什麼是交付？

為什麼這麼多工程師覺得交付很簡單？我知道這聽起來很誇張，但我認為很多工程師並不了解在大型科技公司中，交付的真正意義。

交付是什麼？它不是指部署程式碼，甚至不代表讓使用者使用新功能。交付是公司內部的一種社會共識。具體來說，當公司重要人士認為專案交付了，專案才算交付。如果你部署了系統，但你的主管、副總或執行長很不滿意，那麼你就沒有交付。（也許你交付了「某個東西」，但你沒有交付真正的專案。）只有當公司高層認可你交付了，你才知道你真的交付了。副總在 Slack 上的祝賀訊息是個好兆頭，內部部落格宣告勝利也是。如果是小專案，主管的口頭嘉獎就夠了。

這聽起來可能有點像繞圈子，但我認為這很重要。當然，如果你部署的東西使用者喜歡，而且賺大錢，那你肯定交付了。但那是因為滿足使用者和賺錢會讓你的領導團隊開心。如果你交付的東西使用者討厭，而且沒賺錢，但你的領導團隊很開心，那麼你還是交付了。你可以對此抱持任何看法，但事實就是如此。如果你不喜歡這樣，你或許應該去真正重視使用者滿意度的公司工作。

那些認為交付只是完成規格或部署程式碼的工程師，註定會不斷地將專案導入失敗的交付。

溝通

如果交付的主要工作是讓公司領導團隊對專案滿意，那實際上該怎麼做？首先，你必須清楚公司想從專案中得到什麼。有時是從少數使用者身上榨取更多錢（例如企業功能）。有時是花錢增加使用者總數（例如吸睛的免費功能）。有時是為了安撫某個大客戶而開發的特定功能。有時只是某位有影響力的副總或執行長的愛寵專案，你需要配合他們的願景。原因有很多，如果你想交付專案，你就必須知道哪些原因適用於這個案例。並據此調整你的工作和溝通方式！例如，企業功能通常不需要華麗的使用者介面，但需求非常嚴格；終端使用者功能需要精雕細琢；愛寵專案則需要你和特定決策者積極溝通，等等。

其次，無論專案目標為何，你的領導團隊（你的報告鏈中關心專案的人）相較於你，對專案的技術背景幾乎一無所知。這表示他們會信任你的評估、技術問題解答，以及對技術問題的預測。維持這份信任應該是你的首要任務。如果他們不相信你有能力完成工作並讓他們隨時掌握進度，你就無法交付。他們會取消專案來降低風險，或者讓專案默默推出，沒有任何關注或慶祝（記住，沒有慶祝的發布不算交付！）。或者，他們會把你晾在一邊，去找另一個工程師，然後由他正式或非正式地交付專案。無論哪種方式，你都會在績效考核時感受到，而且他們下次會找別人負責。

如何維持與領導團隊的信任？這本身就可以寫成一篇文章（或一本書），以下是我的摘要：

最好是有過去成功交付的紀錄
展現對專案的信心（如果你顯得擔心，他們也會擔心）
展現專業能力，你要營造出類似 NASA 任務控制中心的氛圍
專業簡潔地溝通，不要讓他們追著你要進度：每天或每週在固定地方發布進度

比起零 bug 準時交付，做到這些事情更重要。根據我的經驗，如果專案因為技術原因必須延遲，只要你清楚、自信地溝通（最好能提前預警），你並不會受到懲罰。事實上，如果出現一些問題導致延遲，反而對你更有利，就像緊急搶修事故的工程師比預防事故的工程師更容易獲得讚賞一樣。

上線到正式環境

即便如此，你通常還是得讓專案上線到正式環境。最常見的問題是忽略關鍵細節。有時是技術細節：也許我們仰賴 Memcached 儲存使用者文件，但很多文件超過 Memcached 的區塊大小限制。有時是協調的細節：也許負責 Memcached 的平台團隊預估的流量只有我們專案的十分之一，所以他們召開了副總級會議，並延遲了專案。有時是法律細節：也許使用者資料的敏感度超出預期，而我們的系統沒有安全處理這些資料的必要機制。這些問題可能來自任何地方，而且很難預料。處理這些問題需要對系統有深入的技術理解，並且能夠快速應變。

例如，你可能已經讀了第一個例子，現在正在想「嗯，你可以把文件拆分到多個 Memcached 鍵值，或者增加區塊大小，或者換成 Redis 等等……」。這些都是可能的解決方案！但要知道哪種方案可行，更重要的是，哪種方案不會拖延專案時程，除非你對系統有深入的了解，否則是不可能的。

這一點尤其重要，因為問題本身甚至不需要是真的。在專案上線前，其他團隊或工程師很常提出潛在問題（例如「嘿，我們確定使用者資料放得進 Memcached 嗎？」）如果沒有人出面解釋為什麼這不是問題（或者如果是問題，如何在發布前解決），專案就會被延遲，而且你必須負責。為什麼？因為你的主管（或他們的主管）不知道這是不是個嚴重的問題。這就是他們付你薪水的原因！如果你沒有主動處理，他們自然會選擇謹慎行事，不交付。

你必須保持彈性，這樣當這些問題出現時，你才不會被其他工作卡住。這通常意味著不要完全埋頭於實作（也就是將任務委派給專案中的其他工程師）。理想情況下，在專案初期，你應該至少有 20% 的時間不用寫程式，在最後幾天增加到 90-100%。如果你這樣做，當問題出現時，你就能夠全心全意地處理它們。

現在可以交付嗎？

功能切換是我見過最好的方法，但測試環境也行，等等。關鍵是讓你的作品被盡可能多的人看到：你自己，其他工程師，最好還有領導團隊、產品團隊、設計團隊等等。即使是很粗糙的版本，花五分鐘實際操作一下功能，就能發現沒人預料到的問題。讓他們親眼看到，也能讓領導團隊安心，相信你一切都在掌控之中。

預測問題的最佳方法就是及早部署。一般來說，一個有幫助的問題是我現在馬上可以交付嗎？不是這週，不是今天：而是現在這一刻。如果不行，我需要做哪些改變才能交付一些東西？如果交付需要部署，現在可以在功能切換後部署嗎？如果我們在等其他團隊修改，我可以讓系統不再嚴格要求他們的修改嗎？例如，如果平台團隊正在設定快取層，我可以讓我的功能在找不到快取的情況下仍然可以運作（雖然速度會慢一點）。

記住，你的首要任務是維持與領導團隊的信任。沒有什麼比備案更能建立信任，因為在緊急情況下，備案代表你掌控全局。如果真的發生最壞的情況，你在當天無法發布，如果你的主管可以跟他們的主管說「我們的選擇是延遲四天，或者明天發布但犧牲 X 功能」——即使犧牲 X 功能是不可行的——他們也會比較樂意接受。這表示他們更有可能將延遲解讀為你有效處理的不可避免的問題，而不是你犯的錯誤，代表他們不能再依賴你。

我認為很多工程師不部署，基本上是出於恐懼。如果你想交付，你應該反其道而行：你應該盡可能及早、盡可能多地部署，而且你應該盡可能及早進行最可怕的變更。記住，你對專案的掌握最全面，這表示你應該是最不怕可怕變更的人。其他人面對更多未知數，會更不願意按下那個大按鈕。（如果還有其他工程師也了解全局，而你在等他，那很不幸：他可能才是真正交付你專案的人）。