作者：京東零售 井亮亮

引言

近期在參與編寫平臺工程系列標準時，我發(fā)現(xiàn)開發(fā)者體驗 (DevEx) 是一個不可忽視的關(guān)鍵因素，它對于構(gòu)建一個成功的平臺工程起到了重要的作用，DevEx 可以稱之為平臺工程的基礎(chǔ)?；谖易罱膶W習和思考，我決定寫這篇文章，想深入探討一下 DevEx 對于內(nèi)部開發(fā)平臺的重要性，也希望為從事內(nèi)部開發(fā)平臺的同學們帶來一些新的思考。

了解平臺工程

平臺工程是設(shè)計和構(gòu)建工具鏈和工作流的學科，可在云原生時代為軟件工程組織提供自助服務(wù)功能。平臺工程師提供的集成產(chǎn)品通常被稱為“內(nèi)部開發(fā)人員平臺”，涵蓋了應用程序整個生命周期的運營需求。 --定義來自 platformengineering.org

關(guān)于平臺工程的定義和思考，我在上一篇《扯淡的DevOps，我們開發(fā)根本不想做運維！》文章也提到了，關(guān)于定義目前雖然從文字內(nèi)容上有些差異，但大部分的意思較為一致：主要是倡導自助服務(wù)，將底層基礎(chǔ)支撐工具的復雜性和不確定性去減少，減化工作流程，最終用戶在使用過程中的認知成本降低，從而改善了最終用戶的體驗，和提高生產(chǎn)效率。

為什么需要平臺工程

在公司內(nèi)部，有負責中臺的研發(fā)團隊，有負責前臺的研發(fā)團隊，還有團隊專注于開發(fā)者平臺的研發(fā)。這些從事內(nèi)部開發(fā)者平臺的同學，實際上就是平臺工程團隊。與其他團隊相比，平臺工程團隊最大的區(qū)別在于他們需要具備產(chǎn)品思維。這些團隊的同學可以稱做平臺工程師，那么每個平臺工程師最少是個兼職產(chǎn)品經(jīng)理。

然而，在實際情況中，這些平臺工程師可能過于專注于技術(shù)實現(xiàn)，而會忽略用戶的需求和反饋。他們可能會認為自己負責的工具平臺自己是最了解的，因此很少會去調(diào)研真正用戶的需求和反饋，日復一日不斷地開發(fā)新的產(chǎn)品和功能。

這里拋個問題，可以思考一下：為什么企業(yè)在選擇上云時，往往不直接使用公有云控制臺，而是通過企業(yè)的云管平臺提供服務(wù)呢？

表面來看，直接使用公有云控制臺似乎是最簡單高效的選擇。然而，當使用以后我們深入分析后發(fā)現(xiàn)，這種選擇可能會帶來一系列的嚴重問題。最終可能會造成資源浪費、資源安全性問題。另外，使用公有云控制臺的使用成本也較高，從而也降低了用戶的體驗。

在平臺工程的倡導下，應該降低開發(fā)人員的認知負荷和使用成本，企業(yè)通過 云管平臺 來提供服務(wù)，可以有效降低開發(fā)人員使用認知成本，提升用戶的體驗，讓開發(fā)人員能夠更專注于構(gòu)建自己的應用程序。

了解 DevEx

開發(fā)者體驗 (DevEx) 指的是軟件開發(fā)人員在日常工作中遇到的整體環(huán)境、工具、實踐和文化。它涵蓋了從設(shè)置開發(fā)環(huán)境的便捷性，到工作流程的效率，到工具和流程的有效性，以及整體的支持其創(chuàng)造性和技術(shù)努力的工作文化。

一個最常見的誤解是，開發(fā)者體驗 (DevEx) 主要受內(nèi)部開發(fā)者工具的影響。然而，根據(jù)調(diào)研發(fā)現(xiàn)，除了工具因素外，環(huán)境因素和人為因素同樣對開發(fā)者體驗產(chǎn)生重大影響。

環(huán)境因素包括辦公環(huán)境、團隊文化等。一個良好的工作環(huán)境能夠激發(fā)創(chuàng)造力，提高工作效率。例如，一些公司為了營造輕松愉悅的辦公氛圍，提供了各種娛樂設(shè)施，如啤酒桶、咖啡角、彈球臺、乒乓球臺等設(shè)施，旨在讓開發(fā)者緩解工作壓力，有助于提升開發(fā)體驗。

另外，項目的穩(wěn)定性、目標的明確性、績效考核方式的清晰性也是影響開發(fā)者體驗的重大因素。如果項目團隊經(jīng)常調(diào)整組織架構(gòu)，項目目標不明確，績效考核 A/A+ 的定義模糊不清，開發(fā)人員會感到非常困惑和不安，會極大影響研發(fā)同學的工作效率和體驗。

因此，DevEx 是平臺工程的基石，是促進開發(fā)人員效率提升的最佳路徑。

DevEx 在平臺工程中的意義

提升開發(fā)人員的效率一直以來都是一個追求的目標，但如何衡量開發(fā)人員的效率卻一直是一個難題。僅僅追求需求交付周期或開發(fā)交付周期是相對比較片面的，未能考慮到開發(fā)人員的工作是一個復雜且多樣化的任務(wù)。那么，怎么來衡量開發(fā)人員的生產(chǎn)力呢？

然而，一些企業(yè)在追求提高開發(fā)人員生產(chǎn)力方面取得了一些發(fā)現(xiàn)，他們發(fā)現(xiàn)注重開發(fā)人員的體驗，以開發(fā)人員體驗為目標的方法（DevEx）可以極大地促進開發(fā)人員的效率。根據(jù) Gartner 的調(diào)研報告，78% 的受訪企業(yè)已經(jīng)制定或計劃制定 DevEx 提升計劃。DevEx 提供了一個度量框架，該框架將開發(fā)人員的反饋、認知負荷成本和專注程度綜合在一起，為開發(fā)人員提供了清晰、可操作的衡量維度。

在平臺工程領(lǐng)域，DevEx 是一個至關(guān)重要的因素。關(guān)注它不僅可以提高開發(fā)人員的工作效率，還可以加快交付周期，并提升開發(fā)者的幸福感。通過關(guān)注開發(fā)人員的體驗和提供良好的工具和環(huán)境，企業(yè)為開發(fā)人員創(chuàng)造一個舒適且高效的工作環(huán)境，從而可以提高整體的開發(fā)效率和質(zhì)量。

落地 DevEx

DevEx 是最大化提升開發(fā)效率的關(guān)鍵，假設(shè)你是平臺工程團隊，不知道有沒有主動思考過一個問題：“為什么開發(fā)人員不愿意使用我們的工具？”，作為平臺工程團隊一定要牢記以下7個方法：

1、了解你的用戶（開發(fā)者）

“顧客就是上帝”，雖然我們不是甲乙方，雖然我們同在一家公司，甚至一個辦公室，但你是否真的了解用戶的需求？你是否將用戶視為上帝？是否真的了解用戶的需求和痛點？

在平臺工程團隊，了解用戶訴求，不僅僅是產(chǎn)品經(jīng)理的職責，更應該是整個平臺工程團隊的工作，不僅要了解用戶痛點，而且還要清楚知道用戶平時都是以什么方式在使用你的平臺。

?線上調(diào)查問卷：調(diào)查問卷是最直接的渠道，可以定期主動收集用戶的心聲。

?線下培訓活動：面對面的產(chǎn)品培訓，或通過用戶拜訪以及其他方式，面對面收集用戶的意見。

?保持好奇心：多關(guān)注用戶群、神燈暢聊的消息，當聽到有抱怨或吐槽聲音，要及時跟進解決并思考。

2、向?qū)Ｂ?UX 崗位學習

如果把開發(fā)人員當初用戶來看的話，其實 DevEx 要做的事，和公司內(nèi)的專職 UX 崗位同學的職責差不多。 UX 崗位大部分精力都在和用戶溝通調(diào)研，最終形成用研報告。

“唯一好的假設(shè)就是我們的假設(shè)是錯的”，我特別喜歡這句話，講的非常有道理，因為當我們開始假設(shè)的時候，我們就已經(jīng)錯了。通過假設(shè)做出了某個需求的時候，要么是沒人需要的功能，要么是解決了沒有人遇到的問題。因為所有的功能，都應該是發(fā)現(xiàn)出來的，而不是假設(shè)出來的。功能都是經(jīng)過：發(fā)現(xiàn)、設(shè)計、開發(fā)、交付這4個階段，但最難的就發(fā)現(xiàn)問題，通常 UX 崗位同學在用研過程中是最容易發(fā)現(xiàn)問題的。

3、以用戶為中心的心態(tài)

任何產(chǎn)品都應該以用戶為中心，在平臺工程團隊更加重要，因為常常我們自己也是用戶，特別容易把角色搞混，所以更應該時刻強調(diào)，誰才是真正的用戶，且要時刻確保這種心態(tài)。

?一定不要假設(shè)用戶的需求。

?所有的需求用用戶視角去描述，解決【哪些用戶】的【什么問題】，將需求的目標轉(zhuǎn)移到用戶身上。

4、自動化你的系統(tǒng)

自動化在提升 DevEx 方面具有重要作用，無論是在成本、效率還是穩(wěn)定性方面。通過自動化工具和流程，都可以自動完成繁瑣的任務(wù)，減少開發(fā)人員的負擔。例如，自動化構(gòu)建和部署流程可以減少手動操作的錯誤，并加快交付時間。自動化測試可以提高產(chǎn)品質(zhì)量和穩(wěn)定性，減少問題的出現(xiàn)。此外，自動化還可以幫助提高產(chǎn)品的一致性，減少人為因素的影響，提高穩(wěn)定性和可靠性。

總的來說，自動化在提升 DevEx 方面是至關(guān)重要的。通過減少手工環(huán)節(jié)和自動化流程，可以降低用戶使用產(chǎn)品或工具的步驟，從而提高開發(fā)者體驗。

5、明確崗位和職責

在過去，大部分公司里面有這樣一個崗位，叫 SCM 工程師或者配置管理工程師，但這些年隨著 DevOps 的發(fā)展，自動化構(gòu)建和持續(xù)集成/持續(xù)交付的成熟，開發(fā)人員通常會通過工具自動化完成這些工作，從而減少了專職的需求，因此這個崗位或者叫法正在慢慢消失。

目前，在公司中負責平臺或者工具的團隊，雖然有專職的團隊，但崗位名稱大部分仍然是前端/后端軟件開發(fā)工程師崗，這就無法明確這部分同學的具體職責，但雖然平臺工程的發(fā)展和推動，目前在一些公司中，已經(jīng)有一些叫平臺工程師這個崗位角色，這個角色正在逐步替代測試開發(fā)、工具開發(fā)、運維開發(fā)、甚至替代SRE的崗位角色。因此，我覺得通過明確的崗位和角色，可以更好明確崗位對應的具體職責，更好推動平臺工程的落地。

6、Shifting down

在軟件開發(fā)過程中，通過轉(zhuǎn)移的方式，將開發(fā)人員身上的職責進行減輕，通過轉(zhuǎn)移到其他角色或者平臺上，從而降低開發(fā)人員的負擔，從而提升 DevEx。

左移：將測試左移，測試在開發(fā)過程中早期階段進行，可以更早發(fā)現(xiàn)和解決Bug，使用自動化測試工具或者測試框架來驗證代碼，不過這種做法對測試要求較高，如果測試人員能力達不到，一味地推動測試左移，甚至可能會給開發(fā)增加負擔哈哈。

右移：上線效果A/B實驗，通過比較實驗的方法來驗證上線功能效果。

下移：下移的整體思路就是將開發(fā)人員從工具和平臺中解放出來，平臺工程師負責構(gòu)建和維護工具平臺，為開發(fā)人員提供穩(wěn)定的基礎(chǔ)設(shè)施和工具，這樣，開發(fā)人員可以專注于業(yè)務(wù)邏輯和創(chuàng)新，可以加快開發(fā)速度，從而也提升了 DevEx。

7、建立衡量 DevEx 的指標

最后一點，是建立 DevEx 指標，從而衡量 DevEx，并提升 DevEx ，老實說這點確實比較難，但想一想業(yè)務(wù)開發(fā)團隊都能指定一些 KPI 去衡量，那么平臺工程團隊也應該這樣做，或者可以說可以嘗試這么做。

度量 DevEx

大師彼得·德魯克說過：“如果你無法衡量它，你就無法管理它?！?，在 23 年發(fā)布的一篇研究論文中揭示了度量和提升開發(fā)者生產(chǎn)力的一種全新框架，該框架稱之為 DevEx 框架，作者為 Abi Noda、Margaret-Anne Storey 博士、Nicole Forsgren 博士、和 Michaela Greiler 博士。

影響 DevEx 的因素

針對開發(fā)效率或開發(fā)者生產(chǎn)力的度量，為什么一直以來都比較困難，主要有兩大原因：一方面軟件開發(fā)的過程是不可重復且創(chuàng)造性的工作，另一方面開發(fā)人員在工作中容易受到外部干擾的影響。

①軟件開發(fā)過程非標準：軟件開發(fā)的過程不是重復性的勞動，且是創(chuàng)造性的工作，產(chǎn)出物并非標準的可衡量的，無法通過衡量流水線車間工作一樣的辦法來衡量軟件開發(fā)工作。

②外部干擾的影響：除了公司提供的工具效率影響外，也還有開發(fā)項目的難易程度、開發(fā)者和其他角色的溝通成本、歷史代碼的技術(shù)債務(wù)等因素都會影響開發(fā)效率。

DevEx 框架提出了反饋周期、認知負荷、專注狀態(tài)三個維度。倡導通過關(guān)注這三個維度，從而推動開發(fā)者生產(chǎn)力的提高。

?反饋周期：在開發(fā)過程中，可以快速的反饋對于提供開發(fā)人員的工作效率至關(guān)重要。例如，構(gòu)建、測試或開發(fā)環(huán)境設(shè)置效率低下，導致反饋周期延長，將直接影響開發(fā)人員工作的積極性和生產(chǎn)力。

?認知負荷：在開發(fā)過程中，如果開發(fā)人員需要花費大量時間理解代碼、理解工具的使用方法或者查找文檔上，這會導致認知負荷增加，從而影響工作效率。

?專注狀態(tài)：在開發(fā)過程中，如果開發(fā)人員頻繁被打斷或干擾，不能進入到專注狀態(tài)，那么生產(chǎn)力就會收到嚴重影響。我們的 “No meeting day” 其實也是組織為大家能夠進入到專注狀態(tài)的一種手段和方式。

衡量 DevEx 的指標

對于提升開發(fā)者體驗，衡量指標是非常重要。下圖是 DevEx 框架提供的一個示例，用于了解當前存在的問題，從反饋周期、認識負荷、專注狀態(tài)三個維度進行評估。建議在每個維度上選擇要一兩個關(guān)鍵指標進行度量。同時，也需要從全局上考慮，制定一些宏觀指標，如員工滿意度、需求交付周期等，作為全局考核的北極星指標。

為了衡量開發(fā)者體驗（DevEx），需要綜合考慮主觀和客觀數(shù)據(jù)。除了從相關(guān)工具或系統(tǒng)中獲取客觀數(shù)據(jù)外，還需要調(diào)查開發(fā)人員的看法、態(tài)度和意見。這些主觀的數(shù)據(jù)在某些情況下可以提供相對準確的反饋。

例如，盡管構(gòu)建過程可能非常高效，但如果構(gòu)建操作的步驟過于復雜，可能會干擾開發(fā)人員并影響其體驗。因此，從整體構(gòu)建過程的角度來看，開發(fā)者體驗可能相對較差。這種主觀反饋可以補充客觀數(shù)據(jù)，提供更全面的視角。

除了反饋周期，認知負荷對開發(fā)者體驗的影響最大。認知負荷可以從兩個狀態(tài)來看：

?進入狀態(tài)：這是開發(fā)人員完全投入并享受工作的狀態(tài)，通常需要約 23 分鐘的時間來進入。如果頻繁中斷這種工作狀態(tài)，例如穿插其他任務(wù)，那么進入狀態(tài)所需的時間可能會更長。

?等待狀態(tài)：例如等待重新編譯、等待代碼評審、等待部署、等待服務(wù)啟動等。這些等待狀態(tài)的累計時間將構(gòu)成認知負荷的一部分。

常見的 DevEx 度量指標。例如，可以選擇度量自動化測試效率（反饋周期）、平均部署時長（反饋周期）、執(zhí)行路徑數(shù)（認知負荷）、可選擇操作數(shù)（認知負荷）、代碼庫復雜性（認知負荷）、技術(shù)債務(wù)（認知負荷）和深度工作時間（專注狀態(tài)）、XX自動化率（綜合維度）、平臺NPS滿意度值（綜合維度）。

通過綜合考慮以上指標，可以幫助組織更好地發(fā)現(xiàn)真實的開發(fā)者體驗，找出可能存在的問題，并針對性地進行優(yōu)化，通過不斷地改進和度量，從而提升 DevEx 。

結(jié)語

根據(jù) StackOverflow 的調(diào)查，約有 62% 的受訪者每天花費超過 30 分鐘的時間在搜索答案和解決問題上，而 25% 的人甚至花費超過 1 小時。此外，根據(jù) CNCF 云原生的 Landscape 展示，目前已有 2000+ 張卡片，覆蓋了各個維度的能力，但這也導致了開發(fā)人員認知負擔的日益加重。

?審核編輯 黃宇