瞭解如何根據 平台工程能力模型來識別平台工程工作的目標、逐步解說常見案例，以及尋找衡量成功的方法。 透過將您的目標範圍限定為業務目標來衡量成功。
確定目標和關鍵場景
若要開始使用，請先使用 平台工程功能模型來評估您的組織目前所處的位置。 使用模型來繪製您的組織在六個核心平台工程功能中的位置：投資、採用、治理、佈建和管理、介面，以及測量和意見反應。 所有組織在某些功能上都比其他組織更先進。 一旦您知道您的組織目前所處的位置，您就可以選擇您想要發展的功能。 若要深入瞭解，請參閱 評估您目前的做法並設定未來目標。
您可以隨時間持續規劃和更新您的平台工程目標。 明確您希望從投資平台工程之旅中獲得什麼，可以大大有助於建立組織支援。
正如一位平台工程主管彼得在一家跨國科技公司中所說，“我不為平台工程做事，除非我能從中得到好處。” – 彼得，平台工程主管，跨國科技公司
當您思考目標時，請將其範圍限定為與平台工程工作相關的業務目標，而不是特定開發團隊的具體情況。 常見的高階平台工程目標包括：
- 提高應用程式品質，並減少發行期間的錯誤和問題。
- 提高安全性，並減少安全事件或偵測到的常見弱點和暴露 （CVE） 的數量，一旦投入生產。
- 透過在許可、可訪問性、隱私或政府監管等領域更好地合規來降低風險。
- 透過 內部原始碼 實踐降低複雜性、開銷和促進程式碼共享，加快實現業務價值的時間。
- 降低開發或營運成本、最大限度地減少重複並改善自動化。
選擇您的首要目標至關重要，因為您的目標決定了您對優先級的看法。
更好的是，與您的領導層和內部合作夥伴就 目標和關鍵結果 （OKR） 達成一致，有助於為您的當前投資階段建立可衡量的目標。 （如果您的組織使用其他專案，其他規劃方法也有類似的概念。最好的 OKR 是您可以根據具體度量設定的 OKR，因為它會消除主觀性。
要完成的場景和工作
確定您的目標後，選擇重要場景以推動任務清單和路線圖的制定。 例如，請參閱下列案例和要完成的相關聯工作。
案例：開始建置新的應用程式
- 了解並應用組織最佳實踐和政策
- 建立新的存放庫
- 佈置工具
- 佈建通用基礎結構
- 授予團隊成員存取權
- 建立 CI/CD 管線
- 佈建開發基礎架構
- 初始部署以測試「管道」
案例：將新成員新增至現有小組或移除
- 更新對工具和服務的權限
- 設定開發人員電腦
- 提升團隊成員對應用程式的熟悉度
- 建立應用程式沙箱環境
- 先建立並檢閱提取要求
案例：新增或更新現有應用程式的基礎結構
- 了解組織最佳實踐、可用選項
- 更新或新增基礎結構即程式碼成品
- 建立應用程式沙箱環境
- 驗證更新
- 將變更推出至其他環境
案例：新增或更新現有小組的工具
- 了解組織最佳實踐、可用選項
- 要求使用新工具
- 更新團隊成員對工具的存取權
- （如適用）將工具整合到用戶端或 CI/CD 管道中
案例：尋找或重複使用現有的 API、SDK 或服務
- 探索可用的 API、SDK 或服務
- 評估是否符合需求
- 如有任何問題，請與負責團隊聯繫
- 採用申請
案例：回應作業事件
- 問題通知
- 評估應用程式程式碼或基礎設施是否相關 （或兩者）
- 建立與生產環境相似的沙箱環境（若有差異）
- 進行更改、測試、帶外發布
案例：迅速處置安全性事件
- 問題通知
- 評估問題的廣度 （哪些系統）
- 了解客戶是否受到直接影響
- 建立與生產環境相符的沙箱環境（如果有差異）
- 進行更改、測試、帶外發布
- 與任何受影響的人溝通
案例：取代工具
- 了解工具使用情況
- 通知使用者逐步淘汰
- （選用）協調使用者移轉至新工具
案例：推出架構的新應用程式模型
- 試驗建議的架構
- 根據試點結果進行調整
- 更新最佳實務文件
- 建立範本、更新自動化、原則和治理
稽核應用程式合規性（GDPR、無障礙功能、基礎結構標準）
- 了解目前的合規性規則
- 驗證應用程式符合規則
- 建立修正偏差的期限
- 進行更改、測試、發布
許多案例適用於多個角色。 考慮如何衡量改進的指標。
從問題到概念
接下來，瞭解您的開發人員和其他角色在您識別的案例和作業中面臨的最大問題。 開始研究新產品以填補感知到的差距可能很誘人，但如果這些產品不能解決主要痛點，它們就不太可能被採用或讚賞。
有幾種方法可以幫助您進行此類調查，例如 假設進展框架。 即使您不使用像假設進展框架這樣的正式流程，您也應該就要完成的工作採訪開發人員，以確定討論範圍，然後確定他們在完成工作時遇到的最大問題。 一旦您充分了解了這些問題是什麼，就可以繼續制定解決這些問題的計劃。 這有助於確保您建置開發人員想要使用的功能。
為了能夠快速重複此過程，請確定可以直接在內部開發人員平台團隊中代表客戶聲音的人員。 這個角色通常被稱為產品經理（即使他們有不同的職位），隨著他們知識的增長，他們能夠準確預測較小決策的結果，並確定您何時需要進行更多面試。 這可讓您保持敏捷性，同時確保您專注於為內部客戶提供價值。
為您的初始投資辯護
一旦您擁有了一套經過驗證的問題和概念，您就可以很好地決定在哪裡投資。 但是，在評估解決方案時，請考慮所需的前期投資和長期維護。 最低投入的解決方案往往是一個好的起點，但通常決定您投資成功與否的是維護工作。
換句話說，除非您確實需要，否則不要創建針對旅程後期階段的解決方案。
在確定 最薄的可行平台（TVP）（就像平台的 最小可行產品）後，您應與一組願意提供回饋的開發團隊一起進行初步測試。 如果您的試點解決方案解決了這些團隊面臨的問題，那麼您應該不難找到有興趣參與的人。
當您試用新功能或變更時，您應該擷取一些關鍵指標，以便在推出概念之前衡量概念是否成功。
衡量成功並證明價值
衡量您的成功是產品思維的重要組成部分。 即使是適度投資的小成功也可以為更大的投資奠定基礎。
例如，可能很難為合規工作獲得資金或支持，因為它們可能被視為提供商業價值的開發團隊的營運稅。 產品思維可以改變這種看法。 透過產品思維，您試圖確保內部開發人員平台的客戶滿意，並確保專案關係人的業務目標得到滿足。 指標使您能夠使用事實來證明您正在提供商業價值。 設定 OKR 會有所幫助，特別是如果您有可用於協助消除主觀偏見的計量。 即使您今天沒有測量任何適用的指標，您也可以設定一個學習 OKR 來建立基準，然後在了解此基準後進行改進。
以下是您可以衡量的眾所周知的指標範例，以確定與您合作的團隊是否從您正在建立的內容中獲得價值。 專注於那些能幫助您衡量自己、開發團隊和客戶是否達成目標的指標。 例如，以下是一組指標，可協助您評估平台是否有助於有效的工程組織：
- 速度/實現業務價值的時間：完成第一個提取請求 （上線） 的中位數天數、建置和測試程序的中位數分鐘數 （例如：CI）、合併提取請求的時間中位數。
- 軟體品質：每個開發人員每月建立的事件 （問題） （計數標準化為開發人員數目）、 平均復原時間 （MTTR）、調查和補救安全性問題的平均時間。
- 平台易用性： 淨用戶滿意度 （NSAT）
- 蓬勃發展的生態系統：以下每個調查問題的平均分：“我有能力做到最好”、“大多數時候我都因我所做的工作而充滿活力”、“我所做的工作對我來說很有意義”。
然後，您可以按組織、團隊或項目細分這些指標。 您需要測量一些基準才能開始，但隨著您改進平台，您可以觀察這些指標的變化。
您或您的贊助商可能有興趣衡量的其他指標包括：
| Area | 範例指標 |
|---|---|
| 軟體交付效能 | DevOps 研究與評估 （DORA）：變更前置時間、部署頻率、變更失敗率、還原服務時間 （MTTR） |
| Operations | DORA （MTTR）、平均故障間隔時間 （MTBF）、平均確認時間、最終客戶可用性、延遲、輸送量指標、每個團隊的成本、每次部署的成本 |
| 平台功能採用指標 | 一段時間內使用工具或功能的團隊或開發人員數量、使用平台的存放庫百分比、最受歡迎的範本、管道等。 |
收集指標需要時間和精力，因此務必聚焦於所識別核心目標的關鍵指標，特別是那些支援 OKRs 的指標。 Application Insights 等 OpenTelemetry 型產品可以提供協助。
請務必衡量平台的易用性，並定期調查您是否擁有蓬勃發展的生態系統。 這些指標在內部系統中經常被遺漏，並且是衡量您是否實現更廣泛業務目標的領先指標，因為參與參與對於成功至關重要。 它還可以幫助您了解是否是時候進行進一步的客戶開發，以了解下一步該去哪裡。
其他提示
無論您如何開始，請記住，您應該規劃變更、從試驗的新應用程式開始、專注於增強現有的使用者體驗、採用最低許可權原則、規劃受控實驗，以及將自訂降到最低。
變革計劃
您的目標應用程式平台會隨著時間而演變，您可能無法一次移轉所有現有投資。 思考如何隨著時間的推移支援多個變化並規劃變更。
使用較新的應用程式驗證想法
當您試用新平台或平台功能時，請從合理大小的新應用程式開始。 這也為您提供了將平台作為產品進行管理的經驗。 避免開始重新平台化專案，因為您邊做邊學，而大型現有應用程式通常具有獨特的需求，而這些需求只有在重新平台化工作本身時才會發現。 因此，將您的成功與這些類型的努力結合起來可能會導致期望不匹配或後期問題。 從更新的東西開始可以讓您對自己的方向及其提供的價值充滿信心。 這降低了處理這些更大工作時的風險。 換句話說，如果您確信人們可以正確地開始並保持正確，那麼利用您從經驗中學到的知識來推動正確的活動就會變得更容易。 如果這種方法不可行，您需要進行仔細分析、設定期望並逐步介入，而不是嘗試一次改變所有內容。
在創建新重心之前，先專注於使用者體驗的現有重心
當新功能出現在他們已經喜歡和使用的東西中時，開發人員更有可能採用並堅持使用新功能。 當您評估概念以提供新功能時，請務必調查需要擴展現有 重心的選項。 例如，編輯器/IDE （Visual Studio、VS Code）、DevOps 套件 （GitHub、Azure DevOps）、現有的 CLI 或現有的內部入口網站可能比全新的入口網站或其他 UX 更有效。 若要深入瞭解，請參閱 使用者體驗。
假設最小權限原則
假設開發人員對下游系統的存取權限有限，例如佈建基礎設施。 您需要一種受控的方式來為自助服務體驗啟用此存取權。
受控實驗計劃
在推出重大或有風險的變更之前進行實驗。 並非所有事情都必須完全自動化才能開始。 自動觸發的手動工作流程是試點想法的好方法。
將應用程式平台自訂降到最低
避免自訂建置應用程式平台功能，這些功能可能會被軟體供應商隨著時間的推移發布的功能所掩蓋。 例如，執行階段託管、服務網格、身分識別系統等等。 如果您在懷疑可能類似的領域發現緊急需求，請規劃多種實施選項，因為長期維護可能會導致您隨著時間的推移而切換。