引言
近期在參與編寫平臺工程系列標準時，我發現開發者體驗 (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 我們一起加油💪🏻！
作者：京東零售 井亮亮
來源：京東雲開發者社群 轉載請註明來源