建立基礎設施平台

制定具有可衡量目標的策略

「我們沒有達成目標」可能是你在為某件事工作數週或數月後，從你的利害關係人那裡聽到的最糟糕的事情。在基礎架構平台的世界中，這是有問題的，可能導致你的高階主管決定放棄這個想法，並將他們的預算花在其他領域（通常是更多產品團隊，這可能會使問題惡化！）防止這種情況並非難事 - 建立一個目標和一個策略來實現它，讓你的所有利害關係人都認同。

建立策略的第一步是找對人來定義問題。這應該結合產品和技術主管/預算持有者，並由中小企業協助提供組織中發生情況的背景。以下是幾個問題陳述範例

我們前 15 名產品團隊中沒有足夠具備基礎架構能力的人員，而且我們沒有資源可以聘僱我們需要的人數，導致我們的產品上市時間平均延誤 6 個月

過去 18 個月，我們的產品發生中斷總計 160 小時，損失超過 200 萬美元的收入

這些問題陳述誠實面對挑戰，而且容易理解。如果你無法提出問題陳述，也許你不需要基礎架構平台。如果你有許多問題想要透過建立基礎架構平台來解決，那就列出這些問題，但選擇一個作為驅動因素和你的重點。如果有多個問題陳述，可能會導致對你的基礎架構團隊將達成的目標承諾過多，而且無法兌現；優先處理太多不同結果的事情，而且無法真正達成任何目標。

現在將你的問題陳述轉換為目標。例如

提供前 15 名產品團隊可以輕鬆使用的基礎架構，以平均減少 6 個月的上市時間

在接下來的 18 個月內中斷時間少於 3 小時

現在你可以建立策略來解決問題。以下是如何進行的一些有趣想法

我們強烈建議進行這兩個階段。同時使用過去和未來的觀點，可以為您找出實現目標和解決問題所需採取的行動帶來新的見解。先進行事後檢討，因為我們的大腦似乎比較容易思考過去，然後再思考未來！如果您只有一段時間，請進行未來回溯階段，因為此階段的範圍稍微廣泛，因為未來尚未發生，可以促進更廣泛的構想和跳脫框架的思考。

希望在完成這兩個階段的其中一個或兩個階段後，您會有一份非常實用的清單，列出您需要採取的行動以實現您的目標。這是您的策略（附帶說明，願景和目標並不是策略！！！請參閱理查·魯梅特撰寫的《好策略，壞策略》）。

有趣的是，您可能會決定組建一個團隊來建構基礎架構平台並非您的策略，這很好！並非每個組織都需要基礎架構平台，您可以跳過本文的其餘部分，到馬丁的部落格上閱讀更有趣的主題！如果您很幸運，可以將建立基礎架構平台納入您的策略，那麼請繫好安全帶，準備接受更多傑出的建議。

找出客戶的需求

當我們這些敏捷主義者聽說某項產品已經建置完成，卻沒有任何使用者時，我們會翻白眼，因為我們知道他們一定沒有進行適當的使用者研究。因此，你可能會很驚訝地知道，許多組織會建置平台基礎架構，卻無法讓任何團隊使用它們。這可能是因為一開始就沒有人需要這個產品。也許你建置基礎架構產品的時間太晚了，他們已經建置了自己的產品？也許你建置的時間太早，而他們太忙於其他積壓事項，根本不在乎？也許你建置的產品並未完全滿足他們的使用者需求？

因此，在決定要建置什麼之前，請像對待面向客戶的產品一樣進行探索。對於以前沒有做過探索的人來說，探索是一種（通常）有時間限制的活動，由一群人（理想情況下是會建置解決方案的團隊）組成，他們試著了解問題空間/建置某項事物的原因。在探索期結束時，團隊應了解基礎架構產品的使用者是誰（使用者類型可能不只一種）、使用者有哪些問題、使用者做得好的是什麼，以及團隊將建置什麼基礎架構產品的高階概念。你也可以調查其他可能有助益的事情，例如人們正在使用什麼技術、人們以前嘗試過哪些方法但沒有成功、你需要了解的治理等。

透過將問題陳述定義為策略工作的一部分，我們了解組織的需求。現在我們需要了解這與我們的使用者需求有何重疊（我們的使用者是產品團隊，主要是開發人員）。務必專注於你的策略活動。例如，如果你的策略著重於安全性，那麼你可能會

• 強調安全性漏洞的範例，包括造成這些漏洞的原因（如果你有進行事後檢討，請使用事後檢討中的資訊）
• 訪談各種參與安全事務的人員，包括安全主管、技術主管、技術負責人、開發人員、品質保證人員、交付經理、業務分析人員、資訊安全人員。
• 使用工作坊（例如事件風暴）繪製產品現有的安全生命週期。在你的時間範圍內，針對你希望基礎架構平台提供的服務，與盡可能多的團隊重複進行此步驟。

如果你只在探索中做一件事，請進行事件風暴。找一個團隊或一群團隊，他們將在實體房間裡使用實體牆，或透過電話使用虛擬白板，成為你的客戶。在此圖表上繪製一條具有起點和終點的時間軸。對於基礎架構平台探索，從專案開始到在生產環境中向使用者提供服務，繪製地圖會很有幫助。

然後請大家將專案開始到在生產環境中上線的所有事項，以單一顏色的便利貼繪製出來。

接著請團隊以另一種顏色標示出任何痛點、令人沮喪的事項或總是無法順利進行的事項。

若時間充裕，你可以標示出任何其他資訊，以了解潛在使用者面臨的問題空間，例如使用的技術或系統、不同部分所需時間、可能參與不同部分的不同團隊（如果你決定在會議後深入探討某個領域，這項資訊會很有用）。在會議期間和會議結束後，促進者（也就是執行探索的團隊）應確保他們了解每張便利貼的背景，並深入探討並進一步調查有需要的興趣領域。

在執行一些探索活動並了解使用者提供面向客戶產品所需的內容後，接著優先處理能最快速提供最大價值的事項。有許多線上資源可以協助你塑造探索成果，其中一個不錯的資源是 gov.uk

提早讓使用者參與

「那對我們來說行不通」可能是你聽過關於基礎架構平台最糟糕的一句話，特別是在你已完成所有正確的事項，並真正了解使用者（開發人員）和其最終使用者的需求之後。事實上，讓我們來探討你如何陷入這種情況。當你將正在建立的基礎架構產品分解成史詩和故事，並真正開始深入了解細節時，你和你的團隊將會對產品做出決策。你做出的某些決策可能看起來很小且無關緊要，因此你不會向使用者驗證每個小細節，而且你當然不希望每次在定義小實作細節時就減緩或停止建置進度。這樣做沒問題！但是，如果你幾個月來都沒有收到關於你所做的這些小決策的回饋，而這些決策最終組成了你的基礎架構產品，那麼你所建置的內容可能無法為你的使用者發揮作用的風險將會持續增加。

在傳統的產品開發中，您會定義一個可行性最低產品 (MVP)，並取得早期回饋。我們在一般情況下會遇到一件事，但在基礎架構平台中更為明顯，那就是如何知道什麼是「可行」的產品。回顧建立基礎架構平台的原因，可能是當您降低安全性風險，或縮短團隊的上市時間時，就是可行的，但如果您不向使用者（產品團隊的開發人員）發布產品，直到根據此定義「可行」時，那麼「這對我們不起作用」的回應會越來越有可能出現。因此，在思考基礎架構平台時，我們喜歡將最短價值路徑 (SPV) 視為我們希望第一批使用者加入的時間。最短價值路徑聽起來就是這樣，您能盡快獲得價值的時間，無論是對您的團隊、使用者、組織或混合。我們喜歡 SPV 方法，因為它能幫助您持續思考何時有最早的學習機會，並推動更薄的切片。因此，如果您沒有注意到，這裡的重點是盡早讓使用者加入，以便找出什麼有效、什麼無效，並決定您應該將下一個開發工作投入何處，以改善這個基礎架構產品，以便在組織中更廣泛地使用。

傳達您的技術願景

也許不出所料，這裡的關鍵是要確保您及早說明您的技術願景。您希望防止多個團隊建立與您相同的事物（這會發生！）。確保您的利害關係人知道您在做什麼以及為什麼。這不僅會建立對您解決方案的信心，而且是獲得產品早期見解的另一個機會！

您的願景不必是一些高保真 UML 傑作系列（儘管許多常見的建模格式非常有用）。拿一個白板和一個麥克筆/乾擦拭記號筆，盡情發揮。當您嘗試傳達想法時，事情會變得一團糟，因此能夠輕鬆擦拭並重新開始是關鍵！對於這些類型的圖表，請嘗試避免立即跳入 CAD 程式，它們會讓您遠離創作過程。

話雖如此，有一些有用的工具足夠輕量，可以在這個階段實作。例如

一旦能夠建立技術願景，請使用它來傳達你的進度！將它帶到你的衝刺展示中。使用它來引導與團隊的設計對話。將它帶到你的下一次威脅建模練習中。我們在這篇文章中僅觸及 C4 圖表的皮毛。網路上有許多很棒的文章更深入地探討這個主題 - 探索的起點是這篇InfoQ 文章。

而且不要就此止步！請記住，儘管上述技術將有助於引導對話目前；軟體是一個生命體，在你退休後可能還會存在很長一段時間。能夠將你的技術願景傳達為一系列能夠引導你手邊工作的決策，是另一個有用的工具。

設身處地為使用者著想

如果你在組織中擁有任何內部工具或服務，而你發現這些工具或服務非常容易上手且沒有痛苦，那麼你很幸運！根據我們的經驗，當你取得你想要的東西時，這仍然令人驚訝。因此，想像一個世界，你花費時間和精力來建立你的基礎架構平台，而加入團隊的人會說「哇，這太容易了！」無論你建立基礎架構平台的原因為何，這都應該是你的目標！如果你必須強制使用你的基礎架構產品，事情並不總是會進展順利，所以你必須實際努力讓大家想要使用你的產品。

在常規產品開發中，我們可能有具備使用者研究、服務設計、內容撰寫和使用者體驗專家等能力的人員。在建立平台時，很容易忘記填補這些職位，但如果你希望組織中的人員喜歡使用你的平台產品，這同樣重要。因此，請確保你的團隊中有人負責基礎架構產品的端到端服務設計，無論是開發人員、BA 或 UX 人員。

入門的簡單方法是繪製你的使用者歷程。讓我們以加入為例。

即使不了解這趟旅程的背景，有些事情可以留意，它們可能會發出使用者體驗不友善的訊號

• 開發人員使用者與平台團隊之間的交接
• 有些迴圈可能會讓開發人員使用者在入門時退步
• 缺乏自動化 - 平台團隊做了很多事
• 我們的開發人員使用者在入門前有 9 個步驟要完成，中間可能會等待和延遲

理想情況下，您希望入門流程看起來像這樣

如您所見，入門過程中沒有平台團隊參與，因此完全是自助服務，而且我們的開發人員使用者只需遵循三個步驟。要為您的使用者帶來如此棒的體驗，您需要思考可以自動化什麼，以及可以簡化什麼。簡單的使用者旅程與簡單的程式碼庫之間會有取捨（如「不要把事情複雜化」中所述）。兩者都很重要，因此您需要一位強而有力的產品負責人，確保這種取捨符合您最初提供平台的原因，例如如果您建立平台的目的是為了能更快地將產品推向市場，那麼順暢且快速的入門流程就非常重要。

實際上，您的入門流程可能更像這樣

特別是在您發布 MVP 時（請參閱前一節）。將這種思考應用於團隊在使用您的產品時可能必須經歷的任何其他互動或流程。透過創造絕佳的使用者體驗（當然，還要有一個基礎產品供人們使用），您不僅應該擁有滿意的使用者，還應該在組織內部獲得極佳的宣傳，讓其他團隊也想加入。請不要忽視此建議，也不要讓您的組織強制使用您這個難以使用的基礎架構平台，讓所有開發人員團隊都感到難過 :(

不要過於複雜化

所有軟體都會損壞。不要對事情太悲觀，但您編寫的每一行程式碼都有很高的機率會很快過時。每個 If 敘述、設計模式、每一行組態都有可能損壞或產生奇怪的副作用。這些可能會表現為難以重現的錯誤或全面中斷。您的平台並無不同！僅僅因為您的產品沒有花俏、有回應的 UI 或高可用性的 API，並不表示它不會產生錯誤。而且，如果您建立的東西是一個平台，其他團隊正在其上建置自己的服務，會發生什麼事？

當您開發其他團隊依賴的基礎架構平台時；您的客戶的開發環境就是您的生產環境。如果您的平台發生問題，您可能會讓其他人也跟著遭殃。您真的不希望冒險在其他團隊的開發流程中造成停機。這會侵蝕信任，甚至可能傷害您試圖幫助的人與您的關係！

軟體中出現錯誤的主要（且可怕的）原因之一與複雜性有關。支援的功能越多，平台嘗試執行的動作越多，出錯的可能性就越大。但是，平台團隊中出現複雜性的主要原因是什麼？

對於那些可能還不熟悉的人來說，康威定律指出，組織往往會設計反映其自身內部溝通結構的系統。從軟體的角度來看，這表示系統通常會設計成具有某些「但書」或「解決方法」，以因應組織歷史中某個時間點的快照。雖然這並非一定是不好的，但它很容易影響我們在現場做出的設計決策。如果您正在建構 API，團隊內部可以輕鬆處理這類型的設計決策。但是，如果您正在為許多不同的團隊（及其眾多不同的細微差別）建構一個具有許多不同整合的系統，這就會變成一個更大的問題。

那麼，在撰寫大量與業務流程緊密結合的細緻元件，以及建構一個可以支援組織成長的平台之間，最佳平衡點在哪裡？

一般來說，您作為團隊撰寫的每個元件都是另一個需要衡量、維護和支援的事項。當然，您可能會受到現有的架構負債、合規限制或安全防護的限制。我們在此要傳達的重點是，在為您的解決方案引入另一個元件之前，請三思。您開發的每個活動部分都是對上線後支援的投資，也是另一個潛在的失敗模式。

衡量重要事項

一篇關於建構更好的基礎架構平台的文章，如果不提到衡量事項，就不算完整。我們之前提到要確保您定義一個具有可衡量目標的策略。那麼，成功是什麼樣子？這是您可以透過程式碼擷取的內容嗎？也許您想透過減少營運摩擦來增加使用者的部署頻率？也許您的真正目標是提供一個穩定且安全的成品存放庫，供團隊依賴？花點時間看看您是否可以將這個成功指標轉換成一個輕量化的儀表板。能夠慶祝您的勝利，對您的團隊士氣和幫助建立組織對您平台的信心都有很大的幫助！