注意平台執行差距

商業價值

承諾建立內部開發人員生產力平台的決策是一個經濟決策。有利的論點取決於效率、品質和上市時間的優點，超過其建構和演進過程中產生的財務、人才和機會成本。如果您無法說明平台的商業案例，那麼您就沒有能力負責任地採用它。您的計算必須考慮商用服務的能力，因為除非您的平台提供商業產品無法提供的功能、特定於您的環境或便利性，否則您最好將其留給市場並避免維護負擔 - 畢竟，您的平台策略取決於減少非差異化工作的數量，而不是增加它！

建立數位平台的決策只是您證明數位平台商業價值的責任的開始。平台策略的動機可能在高層面上令人信服，但在決定提供哪些功能以及如何提供這些功能時，涉及許多細緻的決策。為了進一步複雜化問題，隨著技術進步、組織需求的演變以及雲端供應商和其他供應商發布與您自建解決方案競爭的新產品和改良產品，您的功能的商業理由將隨著時間而改變。

為了為您的組織提供承諾的價值，請規劃相較於面向最終使用者的產品，持續改善與產品創新所佔的比例更大。為了使平台易於管理且成本受到控制，與可操作性相關的項目必須在待辦事項清單中佔有一席之地。您的使用者重視一致性、穩定性和可靠性，勝過一系列新功能。此外，您提供的每項產品都必須在某一天被棄用，以利於市場上的新產品、內部建置的後續產品，甚至將能力的責任移交回您的產品開發團隊。棄用是平台產品生命週期的基本部分，如果不考慮它，可能會損害您最初希望透過提供它而獲得的業務利益。

產品思維

您絕不能忘記，您正在建置旨在取悅其客戶的產品 - 您的產品開發團隊。任何妨礙開發人員順利使用您的平台的事物，無論是 API 可用性中的缺陷或文件中的空白，都對平台業務價值的成功實現構成威脅。優先考慮開發人員體驗 - 沒有人使用的產品不是成功的產品，無論其技術優點如何。為了對您的內部平台獲得投資報酬，您的產品開發團隊需要使用它並善加利用它。為了實現這一點，他們需要欣賞它、理解它並了解它的功能。正如 Max Griffiths 在他的文章 基礎設施即產品 中所描述的，平台產品需要客戶同理心、產品所有權和智慧測量，就像其他類型的產品一樣。

內部產品的優點之一是您有高度投入產品演進和成功的使用者。與任何客戶群一樣，您的同事將會是懷疑者、中立者和熱情者的混合體。利用熱情者並協助他們成為平台的早期採用者和擁護者，將極大地提升組織中對平台的觀感。傳達您的路線圖、接受回饋並從使用者身上收集經驗，將有助於您的平台持續相關。幸運的是，你們都為同一家組織工作，因此您有豐富的溝通管道可用。內部平台需要行銷。它看起來不會與向公眾行銷產品相同，但它仍然是行銷。

維護善意是採用成功的關鍵。因此，如果您有任何不可避免的中斷，請傳達它們，並可能調整您的計畫以減少對使用者的影響。如果事情出錯，您發生中斷（提示：您會發生），那麼道歉和透明度將使他們放心。抵制依賴管理命令作為採用策略的誘惑。您可能有被俘虜的使用者，但強迫他們使用產品，聲稱這是為了他們自己的好處，並不會培養出富有成效的關係。

營運卓越

當您採用內部平台時，您要求您的產品開發團隊給予極大的信任。您的平台現在是組織用來履行其功能的系統的主要依賴項。您的營運能力必須足夠，才能證明這種信任是合理的。

這表示你的平台團隊需要對軟體基礎架構的基本原理有深入的了解，例如網路、擴充和災難復原。如果你的平台工程團隊在底層技術上有困難，他們將無法為你的產品開發團隊建置穩健的產品。此外，現代營運卓越的範疇已超越基礎架構，並擴展到確保可靠性的實務。這本書 網站可靠性工程 對這個領域的最新技術有很好的說明。如果你的平台組織在 SRE 實務（例如可觀察性、監控和 SLO）方面沒有技能，你不僅有風險會破壞產品團隊的信任，而且有風險會在不知情的情況下這麼做。

你的平台組織也必須具備成熟度，才能有效率地管理事件並從中學習。非上班時間支援、警示系統和無責備事件回顧應該優先處理。你可能需要建立流程、修改雇主合約中的措辭，並編列預算以提供合理的補償，才能做到這一點，以及 讓隨叫隨到成為一種足夠愉快的體驗，以鼓勵廣泛參與。這也會影響你的規劃。當你需要進行重大變更（例如遷移）時，你需要投資於優雅地進行這些變更，以最大程度地減少使用者的停機時間。

軟體工程卓越

平台組織不只是營運部門，因此它需要的遠超過營運能力。即使你沒有計畫撰寫大量的自訂應用程式，你的腳本、範本和組態檔案也會快速累積複雜性。如果你想要保留快速且安全地變更平台的能力，你需要以正確的方式建置它。

我們最喜歡的基礎架構環境中軟體工程卓越的摘要是基礎架構即程式碼的三項核心實務，正如 Kief Morris 在他的書 基礎架構即程式碼 中所定義的

• 將所有內容定義為程式碼
• 持續測試並傳送所有進行中的工作
• 建立小而簡單的區塊，以便獨立變更

如果您的組織能夠持續應用這些做法，更有可能能夠執行平台願景。沒有它們，您也許可以在某個時間點讓基礎架構處於良好狀態，但您將無法維持開發團隊不斷變化的需求所要求的演進步調。

使用內部產品也會對產品開發團隊提出要求。良好的產品開發團隊知道其相依項提供的服務等級，將其納入自己的設計，並使用工程實務來減輕可能影響其服務等級目標的風險。當這些相依項在內部提供時，這一點甚至更重要，因為無論您的平台品質多高，都不太可能達到商業 SaaS 供應商的精緻程度。

健康的團隊

個人技能很重要，但要長期維持卓越，需要強大的團隊層級紀律。當你的平台系統被業務的其他部分依賴時，不能只讓少數忙碌的個人負責維護專業知識。你需要有明確任務的自主團隊，避免個人代碼或系統所有權。他們必須投資於知識分享、文件編寫和入職培訓。一個人中樂透絕不應該對你的平台的可行性構成威脅。

為了讓這些平台工程團隊保持生產力，他們的工作規劃系統需要成熟。他們必須有價值描述的待辦事項清單，並有優先順序處理的流程，否則緊急事項可能會壓垮重要事項。事件和計畫外工作是不可避免的，但如果團隊花費太多時間在繁瑣的工作上，那麼它將永遠沒有能力投資於其產品的改進。團隊不應嘗試一次管理過多的平台產品。

我們發現認知負載的概念，正如 Matthew Skelton 和 Manuel Pais 在其著作 團隊拓撲 中所討論的，對於保持團隊任務的可控性很有用。如果一個團隊不斷在完全不同的任務之間切換，那麼認知負載就會太大，當這種情況發生時，團隊不僅會降低執行日常工作的效率，而且新團隊成員也很難獲得他們需要的所有系統工作的信心。

入門

如果你們組織中還沒有這些能力，這是否會讓你無法採用平台策略？你可能會問，你如何才能在沒有經驗可得的教訓的情況下建立這些能力？

秘訣不是在執行品質上妥協，而是在一開始就對你的野心範圍保持謙虛。一個平台計畫，無論多小，都應該產生業務價值，以產品思維為指導，以卓越的運營和軟體工程實施，並由能夠維持新平台服務的團隊結構作為後盾。達不到這個標準，你希望提供的助力很可能會成為阻力，損害你組織中開發人員對你新興平台的聲譽。

針對技術資產中理解良好的部分的小型、重點平台服務難度較低。它們不會讓你放棄從整體角度考慮平台，但它們讓你能夠開始並從那裡建立。例如，提供一個日誌叢集，可以減輕產品團隊的運營負擔並提高跨服務的可見性，這具有明確的業務價值，不需要複雜的財務建模來建立。它仍然需要產品思維來確保它服務於其客戶（它的可用性、新鮮度和搜尋使用者介面是否滿足開發人員的需求？）但這種產品思維不需要像提供統一開發人員入口那樣成熟。它仍然需要軟體工程、運營技能和一個健康的團隊來做好，儘管不如為組織的所有微服務建立一個可觀察側車那麼多。

首先要問自己的問題是我們能建構什麼最小的東西 [1] 來幫助產品團隊？第二個問題是，在適當時機，我們該如何升級或遷移？最先進的技術正在快速演進，而且供應商鎖定並不會因為供應商就是你自己的組織而減少痛苦。如果淘汰你的平台服務需要歷經多年的痛苦轉型，那麼可能就是時候回到繪圖板，簡化你的產品。你不需要準備好詳細的行事曆和大量的替代技術，但考量實際的產品生命週期（三到五年）和用於替換解決方案的架構接縫，將迫使你的設計更簡單、更解耦。

我們建議採用你的平台應為自願。這在兩個方面支持你的平台策略。首先，當產品團隊有能力選擇退出平台服務時，這會鼓勵你保持服務的鬆散耦合，這將在推出新一代服務或使用商業產品取代服務時，對平台有幫助。其次，當你的平台組織依賴於產品團隊對平台優勢的欣賞時，這會對你的平台組織施加強大的壓力，讓他們將客戶滿意度放在首位。強制遷移到平台是一種捷徑，長期而言有侵蝕團隊產品思考紀律的風險。

你可能會發現一個簡單的分類系統對設定關於新平台功能成熟度的預期很有用，例如指出一個新功能處於測試階段。你可能希望將服務等級目標 (SLO) 和支援層級與成熟度分類關聯起來，因為一個實驗性功能不需要提供與核心功能或你的平台相同的高可用性。例如，它可能不需要全天候支援。一旦該功能提升為完全支援，平台使用者可以期待足夠強大的 SLO，讓他們可以在其上建構任務關鍵元件，但在那之前，一組要求較低預期讓平台團隊有自由進行實驗，並在對產品做出強而有力的（且長期的）承諾之前驗證他們的假設。

如果你能記住上述事項，你將獲得額外的優勢。你的平台團隊將管理少數非常有效產品的產品組合。他們的認知負擔會很小，而且他們的焦點將能夠持續放在縮短開發團隊的上市時間，而不是只放在維持運作上。

結論

數位平台是技術產品的投資組合。與所有產品一樣，平台透過使用產生價值。透過適當的基礎業務論證、審慎的產品管理和有效的技術執行，數位平台可透過降低產品開發團隊的認知負擔並加速組織的創新來獲得成功。平台在金錢、人才和機會成本方面需要大量投資。它們透過正面影響產品開發團隊快速有效開發高品質面向客戶產品的能力來償還這筆投資。

開發數位平台是一項策略決策，不可輕忽。除了直接的財務考量之外，數位平台也會對組織內部的關係施加壓力。產品開發人員已經體驗過商業雲端供應商的產品，為了滿足這些提高的期望，平台工程團隊必須在產品管理和技術實作方面都成熟。產品開發團隊也必須學會成為平台組織的良好合作夥伴，並承擔其服務營運的責任。

數位平台是力量倍增器，因此在開發競爭優勢和引入重大生產力阻礙之間有一條細線。您在產品生命週期中做出的決策將決定您走向哪一邊。好消息是，就像其他類型的軟體開發一樣，如果您從小處著手、設身處地為客戶著想、從成功（和失敗）中學習，並牢記您的整體願景，您就有機會成功。