許多平台工程師常遇到一個令人沮喪的循環：花了大把時間建構出技術上非常完美、功能強大的內部開發平台，但最後發現開發者根本不想用，或者管理層完全不理解這項投資的價值。這種現象在業界非常普遍，核心原因在於平台團隊將其視為技術問題，而實際上這是一個說服與溝通問題。
在 KubeCon 上的分享中，Lucas Hornung 與 Christian Matthaei 提出了他們將技術願景轉化為業務價值並成功推行的經驗。對於剛接觸平台工程或正苦於推動技術變革的工程師來說，最重要的一點是：技術採納率的高低，通常與技術本身好不好無關，而與你如何溝通有關。
從技術語言轉換為業務價值
工程師習慣用技術參數說話，例如 GitOps 能提高一致性或減少配置漂移。但對於沒有技術背景的管理層來說，這些詞彙沒有意義。要讓非技術人員理解你的工作，必須從為什麼開始，而不是怎麼做。
管理層在乎的是風險、成本與效率。如果你想獲得資源或支持，就必須增加自己的能見度，主動與利益相關者溝通，傾聽他們在業務運作中遇到的真實痛點。不要期待管理層會神奇地發現你的解決方案有多優秀，你必須主動將技術願景翻譯成業務能理解的語言。
利用量化指標開啟對話
為了讓價值變得可衡量，可以使用 DORA 指標。DORA 指標是指一套衡量軟體交付效能的標準，包含部署頻率、變更前導時間、服務恢復時間以及變更失敗率。這類指標之所以重要，是因為它能將技術討論轉化為業務討論。
當你能向管理層展示部署速度提升了百分之多少，或者系統恢復時間縮短了多少時，你才真正拿到了進入決策層對話的入場券。然而，量化指標僅能開啟對話之門，它無法單獨驅動開發者的行為改變。
將隱形痛點具象化
很多開發者在面對糟糕的流程時，會習以為常，認為這就是工作的一部分，因此不會主動要求改變。這時，單純強調技術優勢（例如 GitOps 技術上更好）是沒有說服力的。
有效的做法是創造敘事，將隱形的痛點具象化。與其說 GitOps 能提升穩定性，不如描述一個具體場景：當一名工程師在週五下午手動部署導致錯誤，而另一名輪值工程師在凌晨兩點被分頁喚醒處理故障時，那種痛苦是什麼感覺。
當你把技術目標轉化為我能睡個好覺時，開發者才會感受到這個平台與他們個人的利益相關。透過建立可共鳴的角色原型，讓開發者在故事中看到自己的影子，才能真正提高平台的採納率。
走出舒適圈的工程師
平台工程師的職責往往被定義在維護基礎設施與工具鏈，但實際上，要成功部署一個平台，工程師必須學習產品經理的思考方式。這包括如何進行利益相關者管理、如何講故事以及如何進行內部行銷。
如果你發現開發者不願意使用你開發的工具，請先停止檢查程式碼或增加新功能，試著檢視你的溝通方式。不要只給對方看樂譜（技術規格），而要直接演奏音樂（展示最終價值與體驗）。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。