規劃和優先順序
瞭解如何根據 平臺工程功能模型識別平臺工程工作的目標、逐步解說常見案例，以及尋找測量成功的方法。 藉由將目標範圍界定為商務目標來衡量成功。
識別目標和關鍵案例
若要開始使用，請先使用 平臺工程功能模型來評估貴組織目前的位置。 使用模型來繪製貴組織跨六個核心平臺工程功能的圖表-投資、採用、治理、布建和管理、介面和測量和意見反應。 所有組織在某些功能中都比其他組織更進階。 一旦您知道組織目前所處的位置，您就可以挑選想要成長的功能。 若要深入瞭解，請參閱 如何使用模型。
您可以持續規劃和更新一段時間的平臺工程目標。 清楚瞭解您想要從投資平臺工程旅程中獲得的內容，對於協助建置組織支持還有很長的路要走。
作為一個平臺工程負責人曾經說過的，“我不會為平臺工程做點什麼，直到我有一些我可以從中得到的東西。” - 彼得，平臺工程主管，跨國科技公司
當您考慮您的目標時，請將其範圍設定為與平臺工程工作相關的商務目標，而不是特定開發小組的特定細節。 常見的高階平臺工程目標包括：
- 提高應用程式品質、減少發行期間的 Bug 和問題。
- 改善安全性、減少安全性事件數目，或在生產環境中偵測到常見弱點和暴露次數一次。
- 透過授權、輔助功能、隱私權或政府法規等領域的更佳合規性來降低風險。
- 藉由減少複雜度、額外負荷，以及透過 內部來源 實務促進程式代碼共用，以加速企業時間價值。
- 降低開發或營運成本、將重複專案降至最低，並改善自動化。
挑選您的最高目標非常重要，因為您的目標會推動您思考優先順序的方式。
更好的是，與 領導和內部合作夥伴就目標和關鍵結果（OKR） 達成一致，可為您的投資目前階段建立可衡量的目標。 （如果您的組織使用其他專案，其他規劃方法也有類似的概念。最好的OKR是您可以根據具體量值設定的OKR，因為它會移除主觀性。
要完成的案例和作業
識別目標之後，請選擇要推動待辦專案和藍圖的重要案例。 例如，請參閱這些案例和要完成的相關聯作業。
案例：開始建置新的應用程式
- 瞭解並套用組織最佳做法和原則
- 建立新的存放庫
- 布建工具
- 布建通用基礎結構
- 授與小組成員存取權
- 建立 CI/CD 管線
- 布建開發基礎結構
- 測試「管道」的初始部署
案例：將新成員新增或移除至現有的小組
- 更新工具、服務的存取權
- 設定開發人員計算機
- 增加應用程式上的小組成員
- 建立應用程式沙盒環境
- 建立並檢閱第一個 PR
案例：新增或更新現有應用程式的基礎結構
- 了解組織最佳做法、可用的選項
- 更新/新增基礎結構作為程序代碼成品
- 建立應用程式沙盒環境
- 確認更新
- 推出其他環境的變更
案例：為現有小組新增或更新工具
- 了解組織最佳做法、可用的選項
- 要求使用新工具
- 更新小組成員對工具的存取權
- （如果適用）將工具整合到用戶端或 CI/CD 管線
案例：尋找或重複使用現有的 API、SDK 或服務
- 探索可用的 API、SDK、服務
- 評估它是否符合需求
- 與擁有小組聯繫以取得任何問題
- 採用應用程式
案例：回應作業事件
- 問題的通知
- 評估應用程式程式代碼或基礎結構相關 （或兩者）
- 建立鏡像 Prod 的沙箱環境（如果不同）
- 進行變更、測試、頻外發行
案例：快速補救安全性事件
- 問題的通知
- 評估問題的廣度（哪些系統）
- 了解客戶是否直接受到影響
- 建立鏡像 Prod 的沙箱環境（如果不同）
- 進行變更、測試、頻外發行
- 與受影響的任何人通訊
案例：取代工具
- 瞭解工具使用方式
- 通知使用者淘汰
- （選擇性）協調使用者移轉至新工具
案例：推出新的架構應用程式模型
- 試驗建議的架構
- 根據試驗結果進行調整
- 更新最佳做法檔
- 建立範本， 更新自動化， 原則， 治理
稽核應用程式合規性 （GDPR、輔助功能、基礎結構標準）
- 瞭解目前的合規性規則
- 確認應用程式符合規則
- 建立偏差修正的期限
- 進行變更、測試、發行
許多案例適用於多個角色。 思考如何測量改進的計量。
從問題到概念
接下來，尋求了解開發人員和其他角色面臨的最大問題，以及您所識別的案例和工作。 開始調查新產品以填補感知的空白是誘人的，但如果這些產品不能解決一個主要的痛點，他們不太可能被採用或欣賞。
有數種方法可協助您進行這類調查。 其中一個是 假設進展架構。 即使您未使用假說進展架構之類的正規化程式，您也應該採訪開發人員，瞭解要完成討論的工作，然後找出完成其工作的最大問題。 一旦您對這些問題有很好的瞭解，請繼續制定解決問題的計劃。 這有助於確保您建置開發人員想要使用的功能。
若要能夠快速重複此程式，請識別可以直接在內部開發人員平臺小組上代表客戶聲音的人員。 此角色通常稱為產品經理（即使他們擁有不同的職稱），而且隨著知識的成長，他們能夠準確地預測較小決策的結果，並決定何時需要進行更多面試。 這可讓您保持靈活度，同時仍確保您專注於將價值傳遞給內部客戶。
為您的初始投資做案例
一旦您有一組經過驗證的問題和概念，就可以決定投資地點。 不過，請考慮評估解決方案時所需的預先投資和長期維護。 可解決問題的最低工作解決方案往往是正確的起點，但通常是最終決定投資是否成功的維護工作。
換句話說，除非您真的需要，否則不要建立以旅程後續階段為目標的解決方案。
一旦您識別出最薄可行的平臺 （TVP） （適用於您平臺的 MVP），請試驗一組願意提供意見反應的開發小組。 如果您的試驗解決方案解決了這些小組面臨的問題，您就不應該找不到有興趣參與的人。
您應該在試驗新功能或變更時擷取一些關鍵計量，以便測量概念是否成功，再推出。
測量成功並證明價值
衡量您成功程度是產品思維的重要組成部分。 即使是以適度投資的小成功，也能為更大的投資奠定基礎。
例如，為合規性工作提供資金或購買可能會很困難，因為它們可以視為開發小組的營運稅，而開發小組會提供商業價值。 產品思維可能會改變這種認知。 透過產品思維，您正努力確保內部開發人員平臺的客戶滿意，並符合專案關係人的業務目標。 計量可讓您使用事實來證明您提供商業價值。 設定 OKR 有助於，特別是如果您有計量，您可以使用來協助消除主觀偏見。 即使您目前未測量任何適用的專案，您也可以設定學習OKR來設定基準，然後在已知此基準之後調整。
以下是您可以測量的已知計量範例，以判斷您正在使用的小組是否從您正在建置的專案中取得價值。 零入那些可協助您測量您和開發小組客戶是否達到目標的人員。 例如，以下是一組計量，可協助您評估平臺是否為有效的工程組織做出貢獻：
- 業務價值的速度/時間：完成第一個提取要求的中位數天數（上線）、建置和測試程式的中位數分鐘數（例如：CI）、合併提取要求的中位數時間。
- 軟體品質：每個開發每月建立的事件（已標準化為開發人員數目）、平均補救時間 （MTTR）、調查和補救安全性問題的平均時間。
- 平臺方便使用： 凈用戶滿意度 （NSAT）
- 蓬勃發展的生態系統：下列每一個被調查問題的平均分數：“我有權盡我最大的努力”，“大多數日子我都為我所做的工作所激發，”我所做的工作對我有意義。
然後，您可以依組織、小組或項目細分這些計量。 若要開始，您需要測量一些基準，但您可以在改善平臺時監看這些計量變更。
您或贊助者可能有興趣測量的其他計量包括：
| 區域 | 範例計量 |
|---|---|
| 軟體傳遞效能 | DevOps 研究與評估（DORA）：變更前置時間、部署頻率、變更失敗率、還原服務的時間（MTTR） |
| Operations | DORA （MTTR）， 平均失敗時間 （MTBF）， 認可平均時間， 終端客戶可用性， 延遲， 輸送量計量， 每個小組的成本， 每個部署的成本 |
| 平臺功能採用計量 | 一段時間內使用工具或功能的小組或開發人員數目、使用平臺的存放庫百分比、最受歡迎的範本、管線等。 |
收集計量需要時間和精力，因此請務必專注於您識別的核心目標的重要計量，尤其是支援OKR的目標。 OpenTelemetry 型產品，例如 Application Insights 可以協助。 無論如何，請務必定期測量平臺的使用便利性，並調查您擁有蓬勃發展的生態系統。 內部系統通常會遺漏這些計量，而且是您是否符合更廣泛的業務目標的主要指標，因為參與參與對成功至關重要。 它也可協助您瞭解是否是時候進行進一步的客戶開發，以瞭解下一步的位置。
其他祕訣
無論您如何開始，請記住，您應該規劃變更、從試驗的新應用程式開始、專注於增強現有的使用者體驗、採用最低許可權原則、規劃受控制的實驗，以及最小化自定義。
變更的計劃
您的目標應用程式平臺會隨著時間而演進，而且您可能無法一次移轉所有現有的投資。 思考一段時間后如何支援多個變化，並規劃變更。
使用較新的應用程式驗證想法
當您試驗新的平臺或平臺功能時，請從大小合理的新應用程式開始。 這也可讓您以產品身分管理平臺。 遠離重新格式化項目開始，因為您一開始學習，而大型現有應用程式通常會有獨特的需求，這些需求只會在重新平臺工作本身期間發現。 因此，將成功與這類工作結合，可能會導致預期不符或晚期中斷問題。 從較新的項目開始，您可以放心地向它提供的價值方向。 這降低了應對這些更大努力的風險。 另一種方式是，如果您相信人們可以開始正確並保持正確，那麼使用您從經驗中學到的內容來推動正確的營銷活動會變得更容易。 如果這種方法是不可能的，您會想要仔細分析、設定預期，並逐步執行，而不是嘗試一次變更所有專案。
在建立新使用者之前，先專注於用戶體驗的現有重力中心
當開發人員出現在已喜歡和使用的內容中時，更可能採用並堅持新功能。 當您評估概念以提供新功能時，請務必調查採用擴充現有「重力中心」的選項。例如，編輯器/IDE（Visual Studio、VS Code）、DevOps 套件 （GitHub、Azure DevOps）、現有的 CLIS 或現有的內部入口網站可以比全新的入口網站或其他 UX 更有效率。 若要深入瞭解，請參閱用戶體驗。
假設最低許可權的原則
假設開發人員對於布建基礎結構之類的專案，只能存取下游系統。 您將需要一種受控制的方式，才能啟用自助式體驗的存取。
規劃受控制的實驗
在推出重大或有風險的變更之前進行實驗。 並非所有項目都必須完全自動化才能啟動。 自動觸發的手動工作流程是試驗想法的絕佳方式。
最小化應用程式平臺自定義
避免自定義建置應用程式平臺功能，這些功能可能會因軟體廠商一段時間而發行。 例如，運行時間裝載、服務網格、身分識別系統等等。 如果您在您懷疑的區域中發現迫切需要，請規劃多個實作選項，因為長期維護可能會導致您隨時間切換。