引言
近期在參與編寫平臺工程系列標準時，我發現開發者體驗 (DevEx) 是一個不可忽視的關鍵因素，它對於構建一個成功的平臺工程起到了重要的作用，DevEx 可以稱之爲平臺工程的基礎。基於我最近的學習和思考，我決定寫這篇文章，想深入探討一下 DevEx 對於內部開發平臺的重要性，也希望爲從事內部開發平臺的同學們帶來一些新的思考。
瞭解平臺工程
平臺工程是設計和構建工具鏈和工作流的學科，可在雲原生時代爲軟件工程組織提供自助服務功能。平臺工程師提供的集成產品通常被稱爲“內部開發人員平臺”，涵蓋了應用程序整個生命週期的運營需求。 –定義來自 platformengineering.org
關於平臺工程的定義和思考，我在上一篇《扯淡的DevOps，我們開發根本不想做運維！》文章也提到了，關於定義目前雖然從文字內容上有些差異，但大部分的意思較爲一致：主要是倡導自助服務，將底層基礎支撐工具的複雜性和不確定性去減少，減化工作流程，最終用戶在使用過程中的認知成本降低，從而改善了最終用戶的體驗，和提高生產效率。
爲什麼需要平臺工程
在公司內部，有負責中臺的研發團隊，有負責前臺的研發團隊，還有團隊專注於開發者平臺的研發。這些從事內部開發者平臺的同學，實際上就是平臺工程團隊。與其他團隊相比，平臺工程團隊最大的區別在於他們需要具備產品思維。這些團隊的同學可以稱做平臺工程師，那麼每個平臺工程師最少是個兼職產品經理。
然而，在實際情況中，這些平臺工程師可能過於專注於技術實現，而會忽略用戶的需求和反饋。他們可能會認爲自己負責的工具平臺自己是最瞭解的，因此很少會去調研真正用戶的需求和反饋，日復一日不斷地開發新的產品和功能。
這裏拋個問題，可以思考一下：爲什麼企業在選擇上雲時，往往不直接使用公有云控制檯，而是通過企業的雲管平臺提供服務呢？
表面來看，直接使用公有云控制檯似乎是最簡單高效的選擇。然而，當使用以後我們深入分析後發現，這種選擇可能會帶來一系列的嚴重問題。最終可能會造成資源浪費、資源安全性問題。另外，使用公有云控制檯的使用成本也較高，從而也降低了用戶的體驗。
在平臺工程的倡導下，應該降低開發人員的認知負荷和使用成本，企業通過 雲管平臺 來提供服務，可以有效降低開發人員使用認知成本，提升用戶的體驗，讓開發人員能夠更專注於構建自己的應用程序。
瞭解 DevEx
開發者體驗 (DevEx) 指的是軟件開發人員在日常工作中遇到的整體環境、工具、實踐和文化。它涵蓋了從設置開發環境的便捷性，到工作流程的效率，到工具和流程的有效性，以及整體的支持其創造性和技術努力的工作文化。
一個最常見的誤解是，開發者體驗 (DevEx) 主要受內部開發者工具的影響。然而，根據調研發現，除了工具因素外，環境因素和人爲因素同樣對開發者體驗產生重大影響。
環境因素包括辦公環境、團隊文化等。一個良好的工作環境能夠激發創造力，提高工作效率。例如，一些公司爲了營造輕鬆愉悅的辦公氛圍，提供了各種娛樂設施，如啤酒桶、咖啡角、彈球檯、乒乓球檯等設施，旨在讓開發者緩解工作壓力，有助於提升開發體驗。
另外，項目的穩定性、目標的明確性、績效考覈方式的清晰性也是影響開發者體驗的重大因素。如果項目團隊經常調整組織架構，項目目標不明確，績效考覈 A/A+ 的定義模糊不清，開發人員會感到非常困惑和不安，會極大影響研發同學的工作效率和體驗。
因此，DevEx 是平臺工程的基石，是促進開發人員效率提升的最佳路徑。
DevEx 在平臺工程中的意義
提升開發人員的效率一直以來都是一個追求的目標，但如何衡量開發人員的效率卻一直是一個難題。僅僅追求需求交付週期或開發交付週期是相對比較片面的，未能考慮到開發人員的工作是一個複雜且多樣化的任務。那麼，怎麼來衡量開發人員的生產力呢？
然而，一些企業在追求提高開發人員生產力方面取得了一些發現，他們發現注重開發人員的體驗，以開發人員體驗爲目標的方法（DevEx）可以極大地促進開發人員的效率。根據 Gartner 的調研報告，78% 的受訪企業已經制定或計劃制定 DevEx 提升計劃。DevEx 提供了一個度量框架，該框架將開發人員的反饋、認知負荷成本和專注程度綜合在一起，爲開發人員提供了清晰、可操作的衡量維度。
在平臺工程領域，DevEx 是一個至關重要的因素。關注它不僅可以提高開發人員的工作效率，還可以加快交付週期，並提升開發者的幸福感。通過關注開發人員的體驗和提供良好的工具和環境，企業爲開發人員創造一個舒適且高效的工作環境，從而可以提高整體的開發效率和質量。
落地 DevEx
DevEx 是最大化提升開發效率的關鍵，假設你是平臺工程團隊，不知道有沒有主動思考過一個問題：“爲什麼開發人員不願意使用我們的工具？”，作爲平臺工程團隊一定要牢記以下7個方法：
1、瞭解你的用戶（開發者）
“顧客就是上帝”，雖然我們不是甲乙方，雖然我們同在一家公司，甚至一個辦公室，但你是否真的瞭解用戶的需求？你是否將用戶視爲上帝？是否真的瞭解用戶的需求和痛點？
在平臺工程團隊，瞭解用戶訴求，不僅僅是產品經理的職責，更應該是整個平臺工程團隊的工作，不僅要了解用戶痛點，而且還要清楚知道用戶平時都是以什麼方式在使用你的平臺。
•線上調查問卷：調查問卷是最直接的渠道，可以定期主動收集用戶的心聲。
•線下培訓活動：面對面的產品培訓，或通過用戶拜訪以及其他方式，面對面收集用戶的意見。
•保持好奇心：多關注用戶羣、神燈暢聊的消息，當聽到有抱怨或吐槽聲音，要及時跟進解決並思考。
2、向專職 UX 崗位學習
如果把開發人員當初用戶來看的話，其實 DevEx 要做的事，和公司內的專職 UX 崗位同學的職責差不多。 UX 崗位大部分精力都在和用戶溝通調研，最終形成用研報告。
“唯一好的假設就是我們的假設是錯的”，我特別喜歡這句話，講的非常有道理，因爲當我們開始假設的時候，我們就已經錯了。通過假設做出了某個需求的時候，要麼是沒人需要的功能，要麼是解決了沒有人遇到的問題。因爲所有的功能，都應該是發現出來的，而不是假設出來的。功能都是經過：發現、設計、開發、交付這4個階段，但最難的就發現問題，通常 UX 崗位同學在用研過程中是最容易發現問題的。
3、以用戶爲中心的心態
任何產品都應該以用戶爲中心，在平臺工程團隊更加重要，因爲常常我們自己也是用戶，特別容易把角色搞混，所以更應該時刻強調，誰纔是真正的用戶，且要時刻確保這種心態。
•一定不要假設用戶的需求。
•所有的需求用用戶視角去描述，解決【哪些用戶】的【什麼問題】，將需求的目標轉移到用戶身上。
4、自動化你的系統
自動化在提升 DevEx 方面具有重要作用，無論是在成本、效率還是穩定性方面。通過自動化工具和流程，都可以自動完成繁瑣的任務，減少開發人員的負擔。例如，自動化構建和部署流程可以減少手動操作的錯誤，並加快交付時間。自動化測試可以提高產品質量和穩定性，減少問題的出現。此外，自動化還可以幫助提高產品的一致性，減少人爲因素的影響，提高穩定性和可靠性。
總的來說，自動化在提升 DevEx 方面是至關重要的。通過減少手工環節和自動化流程，可以降低用戶使用產品或工具的步驟，從而提高開發者體驗。
5、明確崗位和職責
在過去，大部分公司裏面有這樣一個崗位，叫 SCM 工程師或者配置管理工程師，但這些年隨着 DevOps 的發展，自動化構建和持續集成/持續交付的成熟，開發人員通常會通過工具自動化完成這些工作，從而減少了專職的需求，因此這個崗位或者叫法正在慢慢消失。
目前，在公司中負責平臺或者工具的團隊，雖然有專職的團隊，但崗位名稱大部分仍然是前端/後端軟件開發工程師崗，這就無法明確這部分同學的具體職責，但雖然平臺工程的發展和推動，目前在一些公司中，已經有一些叫平臺工程師這個崗位角色，這個角色正在逐步替代測試開發、工具開發、運維開發、甚至替代SRE的崗位角色。因此，我覺得通過明確的崗位和角色，可以更好明確崗位對應的具體職責，更好推動平臺工程的落地。
6、Shifting down
在軟件開發過程中，通過轉移的方式，將開發人員身上的職責進行減輕，通過轉移到其他角色或者平臺上，從而降低開發人員的負擔，從而提升 DevEx。
**左移：**將測試左移，測試在開發過程中早期階段進行，可以更早發現和解決Bug，使用自動化測試工具或者測試框架來驗證代碼，不過這種做法對測試要求較高，如果測試人員能力達不到，一味地推動測試左移，甚至可能會給開發增加負擔哈哈。
**右移：**上線效果A/B實驗，通過比較實驗的方法來驗證上線功能效果。
**下移：**下移的整體思路就是將開發人員從工具和平臺中解放出來，平臺工程師負責構建和維護工具平臺，爲開發人員提供穩定的基礎設施和工具，這樣，開發人員可以專注於業務邏輯和創新，可以加快開發速度，從而也提升了 DevEx。
7、建立衡量 DevEx 的指標
最後一點，是建立 DevEx 指標，從而衡量 DevEx，並提升 DevEx ，老實說這點確實比較難，但想一想業務開發團隊都能指定一些 KPI 去衡量，那麼平臺工程團隊也應該這樣做，或者可以說可以嘗試這麼做。
度量 DevEx
大師彼得·德魯克說過：“如果你無法衡量它，你就無法管理它。”，在 23 年發佈的一篇研究論文中揭示了度量和提升開發者生產力的一種全新框架，該框架稱之爲 DevEx 框架**，**作者爲 Abi Noda、Margaret-Anne Storey 博士、Nicole Forsgren 博士、和 Michaela Greiler 博士。
影響 DevEx 的因素
針對開發效率或開發者生產力的度量，爲什麼一直以來都比較困難，主要有兩大原因：一方面軟件開發的過程是不可重複且創造性的工作，另一方面開發人員在工作中容易受到外部干擾的影響。
①軟件開發過程非標準：軟件開發的過程不是重複性的勞動，且是創造性的工作，產出物並非標準的可衡量的，無法通過衡量流水線車間工作一樣的辦法來衡量軟件開發工作。
②外部干擾的影響：除了公司提供的工具效率影響外，也還有開發項目的難易程度、開發者和其他角色的溝通成本、歷史代碼的技術債務等因素都會影響開發效率。
DevEx 框架提出了反饋週期、認知負荷、專注狀態三個維度。倡導通過關注這三個維度，從而推動開發者生產力的提高。
•**反饋週期：**在開發過程中，可以快速的反饋對於提供開發人員的工作效率至關重要。例如，構建、測試或開發環境設置效率低下，導致反饋週期延長，將直接影響開發人員工作的積極性和生產力。
•**認知負荷：**在開發過程中，如果開發人員需要花費大量時間理解代碼、理解工具的使用方法或者查找文檔上，這會導致認知負荷增加，從而影響工作效率。
•**專注狀態：**在開發過程中，如果開發人員頻繁被打斷或干擾，不能進入到專注狀態，那麼生產力就會收到嚴重影響。我們的 “No meeting day” 其實也是組織爲大家能夠進入到專注狀態的一種手段和方式。
衡量 DevEx 的指標
對於提升開發者體驗，衡量指標是非常重要。下圖是 DevEx 框架提供的一個示例，用於瞭解當前存在的問題，從反饋週期、認識負荷、專注狀態三個維度進行評估。建議在每個維度上選擇要一兩個關鍵指標進行度量。同時，也需要從全局上考慮，制定一些宏觀指標，如員工滿意度、需求交付週期等，作爲全局考覈的北極星指標。
爲了衡量開發者體驗（DevEx），需要綜合考慮主觀和客觀數據。除了從相關工具或系統中獲取客觀數據外，還需要調查開發人員的看法、態度和意見。這些主觀的數據在某些情況下可以提供相對準確的反饋。
例如，儘管構建過程可能非常高效，但如果構建操作的步驟過於複雜，可能會干擾開發人員並影響其體驗。因此，從整體構建過程的角度來看，開發者體驗可能相對較差。這種主觀反饋可以補充客觀數據，提供更全面的視角。
除了反饋週期，認知負荷對開發者體驗的影響最大。認知負荷可以從兩個狀態來看：
•**進入狀態：**這是開發人員完全投入並享受工作的狀態，通常需要約 23 分鐘的時間來進入。如果頻繁中斷這種工作狀態，例如穿插其他任務，那麼進入狀態所需的時間可能會更長。
•**等待狀態：**例如等待重新編譯、等待代碼評審、等待部署、等待服務啓動等。這些等待狀態的累計時間將構成認知負荷的一部分。
常見的 DevEx 度量指標。例如，可以選擇度量自動化測試效率（反饋週期）、平均部署時長（反饋週期）、執行路徑數（認知負荷）、可選擇操作數（認知負荷）、代碼庫複雜性（認知負荷）、技術債務（認知負荷）和深度工作時間（專注狀態）、XX自動化率（綜合維度）、平臺NPS滿意度值（綜合維度）。
通過綜合考慮以上指標，可以幫助組織更好地發現真實的開發者體驗，找出可能存在的問題，並針對性地進行優化，通過不斷地改進和度量，從而提升 DevEx 。
結語
根據 StackOverflow 的調查，約有 62% 的受訪者每天花費超過 30 分鐘的時間在搜索答案和解決問題上，而 25% 的人甚至花費超過 1 小時。此外，根據 CNCF 雲原生的 Landscape 展示，目前已有 2000+ 張卡片，覆蓋了各個維度的能力，但這也導致了開發人員認知負擔的日益加重。
在公司內部，我們目前擁有行雲、泰山等各種開發者工具。然而，這些工具對於開發者在反饋週期、認知負荷、專注狀態方面仍然有很大的提升空間。因此，希望我們所有的平臺工程團隊，都能致力於實現提升 DevEx 爲目標，2024 我們一起加油💪🏻！
作者：京東零售 井亮亮
來源：京東雲開發者社區 轉載請註明來源