成功交付長期的工程專案，通常需要根據「階段」具體交付的價值，並同時發現意料之外的未知議題。並不是隨意的設定「里程碑」。

成功的大型專案常常伴隨著神話。人們慶祝最終成果並且反思實現目標採取的正向步驟，不過很快的人們就忘記了一路上的失誤和不確定性。

這些「登月專案」教會了工程師一個糟糕的壞習慣：透過完全分離的設計、執行和交付流程來處理大型項目。

這種反模式通常以下面兩種情況表現出來：

1. 團隊面對一個多年的問題，感到不知所措，無法採取行動。常見的警訊是設計提案以「月」迭代反覆修改持續好幾個月，在寫任何一行程式之前就讓架構越來越複雜，為了那些甚至都不確定是否存在的問題進行優化，在開始建造東西之前就不斷增加「開發資源」的需求。
2. 團隊擁有完整的系統設計和執行計畫，但沒有規劃期間交付任何價值也沒有設定任何中途重新評估的機制和機會。直到專案結束才評估成果。警訊通常為高層對項目啟動猶豫不決、來自其他團隊相關的任務越來越多，導致專案無法完成。

上述兩個情況雖然可能成功交付專案，但伴隨著巨大的風險。

要解決交付大型複雜專案，且避免過度工程化投入過多資源，過度設計，並承擔高風險。常見的解決方案就是經常性重新劃分定義專案範圍，巧妙的細分為一系列「階段」。

面對不知道的未知

關於人們無法直接聯想伊拉克和大規模殺傷力武器的情況，2002 年美國前國防部長唐納德·拉姆斯菲爾德表示：

那些宣稱「某事還沒發生」的報導，總是令人感興趣。因為正如我們所知，存在著「知道的已知」——我們清楚了解的事情。同時也存在著「知道的未知」—— 我們知道自己有所不知的事情。

但除此之外，還有著「不知道的未知」—— 也就是我們根本不知道自己不知道的事情。若回顧歷史，無論是我們國家還是其他自由國家，往往是最後一種「不知道的未知」造成最棘手的問題。

如果去掉上面描述的背景，這會是專案管理和複雜系統開發領域最明智的一段描述。

知道的已知是最簡單的事情。我們已經建置過的東西。你需要一個勾選的 Checkbox 那就直接去執行。

知道的未知也不是太可怕。不知道資料庫是否能負擔工作負載？那就實驗測試。不知道我們需要多久時間可以建置一個特定功能，這就是開發者的任務，本來就存在未知挑戰。

不知道的未知才是問題。關於我們未曾看過的東西。一些功能甚至不知道需要開發。也不知道障礙就擋在角落。一些設計挑戰存在非常遙遠我們根本無法直接意識到它們。

你不知道你不知道什麼！就算盯著白板也不會出現。我們需要去找出它們，這應該才是規劃的基礎。

很多人認為「嚴謹的工程」就是選定一個目標，然後畫一條直線達成目標。這種想法太過樂觀了。工程之所以叫「工程」，就是因為它們是挑戰。這就是工程的本質！我們不可能預知所有事情，你不可能坐在那摸著下巴幾天就想出一個完美的逐步執行計畫 - 我們通常需要邊做邊搞清楚一些東西！

通常提前進行設計和規劃是必要的，但必須明白，最終解決方案遠遠不像單點那樣清晰，達成目標的道路也不可能是一條直線。你的專案策略只是定義了一個大略的解決方案範圍。我們的任務是在不偏離策略的框架下，尋找一個可接受的方案。

如果你在朝目標前進的過程中稍微左右偏移，沒關係，只要不要完全偏離錐體範圍就好。你需要保持大致上的方向正確。在每一步，我們都在消除未知的未知，同時向我們的最終目標前進。

隨意定義里程碑是個問題：它們沒什麼作用。

確實，專案需要計畫和一些評估，追蹤進度，然後過程可能還要通知公司同事報告我們成功完成「里程碑 M2」正往 「M3」前進。但做這些真的能降低專案風險，發現未知問題嗎？老實說，不能。

關於「階段」的重點在於它不是時間線上一個隨意的檢查點。它是一個利基點讓我們可以重新評估並定義下一步。它是所謂「不知道的未知」開始清晰浮現的地方。把它們當作一個站立之處；你會驚訝於從那裡能看到多遠。

如何設立好的階段？

這邊基本上就是全文的要點了：

• 「階段」是一個緊密，具體可交付的成功。涉及某個任務的完成，通常可以是局部功能或最終成品的簡化版
• 「階段」提供實際的價值。如果公司決定停止專案，我們應該也能從「階段」中獲得一些成果或經驗可能是一個輕量化的系統或可用的獨立元件。
• 「階段」位於錐形策略中。成功可能會曲折前進，但每一步應與我們想要達到的方向一致。
• 「階段」讓我們可以學習到東西！通過建造項目的小版本，我們大幅減少了未知未知的範圍。在開始時看似開放式且難以解決的問題，一旦解決方案範圍被縮小，現在就只看似顯而易見的下一步了。

部署一個簡單但效能不好的儲存系統是相對具體的一個交付。重構 API 解耦客戶端和後端簡化應用開發是可以帶來具體價值且讓我們學習到那些 API 對應用有用。使用現成的元件而不是自訂的元件仍然與我們想要的方向一致。這些「階段」都讓我們更靠近最終成果，減少未知。

利用「階段」

一系列表達明確的「階段」會持續帶來好處。

當高層詢問專案還需要多少時間是否讓你產生壓力?
透過每一步產出的實際價值及成果，向他們展示你的進度，並藉此評估項目執行狀況。

專案因為你的關係造成時間壓力?

先提供簡化的版本解決阻塞問題。就可以專注於改進系統核心，無需不斷進行跨團隊協調。

工程師過度優化?

請說服他們先建置單純的東西。不需要客製化自己的鍵/值儲存系統，這個階段 MySQL 可能就堪用了。以後會有優化的機會，到那時我們就會知道是否需要優化！如果我們不需要，就不要這樣做！

取消專案或將資源轉移到其他地方?

幸虧我們沒有浪費過多的時間在項目！要繼續或者取消或就擺著，至少我們都從前面的「階段」取得價值。

激勵團隊努力實現遠大的目標?

我們都很難對遙不可及的目標感到興奮。相反，你應該讓團隊對上線一個「階段」成果感到興奮。發布一個具體實際的系統或有用的組件，即使是小範圍的，遠比達成一個任意的里程碑更令人興奮。

不知如何提前解決問題?

不建議！Dropbox 儲存系統使用客製化設計的 Vandermonde 矩陣來解決資料跨地區備份時的成本問題。它會分析我們網路的架構、硬碟和網路頻寬的相對成本，目標是將成本降到最小。

是不是很複雜的感覺，而它的第一個版本時壓根沒想過要用線型代數的知識，只是先把基本的架構建立起來，而隨著時間推移才有了後續的功能。

如果你讀到這裡決定要停止計畫，直接開始動手，那麼你忽略了一個關鍵點。別忘了錐形策略。「階段」只有在提供方向的時候才算是「階段」。

當 Dropbox 第一次設計儲存系統的時候，我們不考慮上面的進階省錢技術。但如果後來無法進行這些改進，那將肯定是一場災難。關鍵是，我們以簡單且可擴展的方式設計了早期的版本，同時確認了我們的長期目標。這是一門藝術。通常，一家公司中最好的工程師將通過能夠做到這一點來區分自己。

可擴展架構是一個太大的話題，無法在一篇文章中描述，但最基本的原則是專注於簡單。巧妙設計的系統以優雅和簡單為特點，而不是複雜。「階段」成果越簡單，就越不會把你逼入死角，也就越容易在面對不知道的未知時可以適應和修改。

「階段」雖然好用，但也要小心下面三個陷阱：

「階段」目標在簡化項目。若花了大量時間建置的東西最後都丟棄，那一定是方向搞錯了。這個時候請思考一下錐形策略。

並非全部的專案都需要拆分「階段」，也沒有專案需要大量「階段」。有時候大型專案只是需要時間並非全是迷霧。

局部最佳解

老實說，如果不是因為要嘗試逐步交付價值，通常你可能會在某個階段做出更大的改變。有時候就是需要承擔風險大改，但要明白大改伴隨著巨大的風險。大多數複雜的大型項目還是採用「階段」的方式才不會影響最終目標。

如果不認真思考策略和設計就直接開工，那麼很可能會偏離策略。而實際上你可能甚至不知道符合最終目標的方向是什麼意思。「階段」不是不用詳細思考的藉口。它們是一種工具，用於有意識地、有計劃地分階段進行項目，並在了解「不知道的未知」之前避免過度複雜。

與其將一個項目分割成任意的里程碑，不如通過交付具體的「階段」成果來提供價值。「階段」可以通過最小化相依性和提供獨立檢查點來降低專案風險。最重要的是，它們通過結構化逐步交付成果的方式來簡化複雜的專案，這種方式可以消除不知道的未知。制定有效的「階段」是一門藝術，通常需要極度專注於簡單，以避免在通往終點的過程中偏離策略。

• Stepping Stones not Milestones