在大多數(shù)企業(yè)里，提升生產(chǎn)力的劇本總是驚人地相似：購買更貴的工具、聘請更貴的顧問、進行更復雜的重組，以及現(xiàn)在的——引入 AI。然而，盡管投入巨大，摩擦依然存在：優(yōu)先級模糊、會議泛濫、信息孤島、工具割裂。
Atlassian 的專家指出，當我們還在為這些問題頭疼時，軟件工程團隊其實已經(jīng)找到了一把鑰匙：DevEx（開發(fā)者體驗）。
許多人誤以為 DevEx 就是給程序員提供零食、游戲室和彈性工時。錯了。
DevEx 的本質(zhì)是消除摩擦。它的誕生不是為了討好工程師，而是為了解決工程限制。它的核心目標是：降低認知負荷，讓高價值工作順暢流動。
如果把這套邏輯剝離開來，你會發(fā)現(xiàn) DevEx 解決的是所有知識工作者的通用痛點：
目的流 (Purpose Flow)：知道為什么要做這件事。
工作流(Work Flow)：從想法到完成，中間沒有無意義的阻礙。
知識流 (Knowledge Flow)：不需要求人就能找到需要的信息。
智能流 (Intelligence Flow)：用 AI 處理低價值任務(wù)。
軟件團隊之所以高效，是因為他們建立了一套支持上述“流”的儀式和系統(tǒng)：
文檔化：他們痛恨口口相傳，崇尚文檔和代碼注釋（知識流）。
透明化：所有人都能在?Jira/看板上看到任務(wù)狀態(tài)，減少了“對了，那件事怎么樣了”的低效會議（工作流）。
自動化：CI/CD 流水線自動處理集成和部署，而不是靠人肉上傳（智能流）。
反觀市場、HR 或財務(wù)團隊，往往缺乏這種“默認公開、默認自動化”的系統(tǒng)，導致大量時間浪費在協(xié)調(diào)和信息搬運上。
作為領(lǐng)導者，你不需要讓財務(wù)人員學寫代碼，但你可以讓企業(yè)學習軟件團隊的“設(shè)計思維”。
1、告別“偶然的復雜性”
很多企業(yè)的流程是“長”出來的，而不是“設(shè)計”出來的。安全部門加一道審批，合規(guī)部門加一個檢查，最后變成了一個沒人想要但誰也動不了的龐大系統(tǒng)。
行動：像設(shè)計產(chǎn)品一樣設(shè)計你的工作系統(tǒng)。主動審查流程，砍掉那些為了“以防萬一”而設(shè)立的低價值卡點。
2、把 AI 當作隊友，而不是工具
不要只是把 AI 作為一個聊天機器人掛在旁邊。像軟件團隊把 AI 嵌入代碼編輯器一樣，把 AI 嵌入到業(yè)務(wù)流程的核心，讓它自動處理報銷分類、簡歷篩選或合同比對。
生產(chǎn)力從來不是一個“人”的問題，而是一個“系統(tǒng)”的問題。獲勝的組織不是擁有最勤奮員工的組織，而是擁有設(shè)計得最好的工作系統(tǒng)的組織。
DevEx 是這套系統(tǒng)的藍圖?，F(xiàn)在，是時候把它交給全公司的每一位知識工作者了。
每個人都在購買生產(chǎn)力工具，但工作依然艱難——DevEx 證明了設(shè)計“工作方式”比單純“努力工作”更重要。
領(lǐng)導者們正大量投入資金幫助團隊提升生產(chǎn)力。然而，很少有人能解釋到底是什么在拖慢他們的腳步。
對提升企業(yè)生產(chǎn)力的追求通常包括購買生產(chǎn)力工具、更新運營模式、聘請顧問，當然還有人工智能。盡管投入巨大，問題依然未解，從董事會會議室到茶水間，這種無力感無處不在。
與此同時，組織中的一部分人已經(jīng)學會了如何更快地交付更高質(zhì)量的工作。軟件團隊是世界上最高效的團隊之一。這并非因為他們更聰明或技術(shù)更強，而是因為他們學會了設(shè)計工作發(fā)生的方式，而不僅僅是工作本身。
開發(fā)者體驗 (DevEx)為企業(yè)如何更清晰地運作并更快交付高質(zhì)量結(jié)果提供了一份藍圖。
在大多數(shù)組織中，你會發(fā)現(xiàn)相同的模式反復出現(xiàn)：
團隊對優(yōu)先級缺乏清晰認知，導致精力浪費在錯誤的事情上。
工作通過會議來協(xié)調(diào)，使進展緩慢且繁瑣。
信息被鎖在郵件、個人大腦或私人頻道中。
工具之間缺乏集成，只能靠人工在多個地方翻譯和重建信息。
領(lǐng)導者缺乏數(shù)據(jù)來做出明智決策。
這些都是組織工作系統(tǒng)中內(nèi)嵌的摩擦現(xiàn)象；它們是員工體驗問題。
這些挑戰(zhàn)無處不在，但軟件團隊通過重新設(shè)計工作體驗（而不僅僅是流程）來應(yīng)對這些挑戰(zhàn)。DevEx 的出現(xiàn)正是為了應(yīng)對軟件開發(fā)者面臨的摩擦積累。其目標是減少不必要的摩擦，使開發(fā)者能夠以更低的認知負擔輕松完成高質(zhì)量的工作。
DevEx 并非誕生于工程文化；它誕生于工程限制。同樣的原則適用于每一個團隊。
DevEx 常被誤解為討好開發(fā)者，給他們乒乓球桌和披薩來誘惑他們更努力工作。事實并非如此。
當你剝離表象，DevEx 解決的是拖慢每一位知識工作者的普遍問題：
2.1 目的與背景 (Purpose & context)：開發(fā)者若不了解什么重要、為什么重要以及成功是什么樣子，就無法有效構(gòu)建軟件。這是良好開發(fā)者體驗的輸入要素。市場營銷、人力資源和財務(wù)團隊都面臨同樣的模糊性問題。
2.2 工作可見性與協(xié)調(diào) (Work visibility and coordination)：軟件團隊創(chuàng)建了工作的共享可見性，因此工作能在更少的交接和實時互動中取得進展。它減少了來回拉鋸、會議、不必要的依賴和等待時間。這些問題對業(yè)務(wù)型團隊來說更為嚴重，因為他們沒有像工程團隊那樣的共享工具。
2.3 知識的可獲得性與獲取 (Knowledge availability and access)：軟件團隊在文檔、決策日志和信息自助服務(wù)方面投入巨大。這對速度、團隊學習和創(chuàng)新至關(guān)重要；沒有這些，團隊就會淹沒在信息債務(wù)中。這是大多數(shù)組織中最大的績效殺手之一。
當你觀察專注于 DevEx 如何幫助軟件團隊時，結(jié)論顯而易見：DevEx 是企業(yè)績效的藍圖。軟件團隊只是先行一步采用了它。
專注于改進 DevEx 之所以有效，是因為它優(yōu)化了交付工作的團隊的工作方式。四個“流”決定了任何組織的績效表現(xiàn)：
3.1 目的流 (Purpose flow)：團隊知道什么重要、為什么重要，以及他們的工作如何與結(jié)果相關(guān)聯(lián)。
3.2?工作流(Work flow)：團隊在將工作從構(gòu)思推向完成的過程中，經(jīng)歷的摩擦最小化。
3.3 知識流 (Knowledge flow)：團隊可以在需要的時間獲取所需信息，無需向他人索取。
3.4 智能流 (Intelligence flow)：利用 AI 減少低價值任務(wù)和摩擦。
“工程團隊擁有一套明確的‘儀式’和系統(tǒng)機制來支撐這些工作流，而大多數(shù)業(yè)務(wù)團隊卻不具備。頗具諷刺意味的是，這種工作方式上的‘錯位’，恰恰是技術(shù)與業(yè)務(wù)團隊在協(xié)作交匯時產(chǎn)生摩擦的根源之一?！?/span>
在 Atlassian，我們每天都能看到這些儀式和系統(tǒng)的益處。當團隊默認擁有共享的上下文和開放的知識時，協(xié)調(diào)開銷就會降低。決策更快，質(zhì)量提升，團隊不再依賴會議來保持一致。這并非工程領(lǐng)域獨有；這是一種普遍的高績效模式。
在我合作過的所有公司中，從銀行到科技公司，再到現(xiàn)在的賽車行業(yè)，有一個共同的事實依然存在：當工作系統(tǒng)自然生長時，摩擦也會隨之增加。
多年前我在一家大型銀行工作時第一次清楚地看到這一點。我當時負責重新設(shè)計工作系統(tǒng)，目標是提升軟件交付的速度和質(zhì)量。
軟件團隊的工作理論上很簡單：把一個想法轉(zhuǎn)化為代碼，并安全地將代碼部署到生產(chǎn)環(huán)境。但軟件團隊并非孤立運作。他們必須應(yīng)對由負責網(wǎng)絡(luò)安全、金融犯罪、風險、變革管理和架構(gòu)的治理團隊提供的需求，每個團隊都在試圖優(yōu)化其合理的預(yù)期結(jié)果。
隨著時間的推移，新法規(guī)和要求不斷引入，每個治理團隊都在交付路徑中增加了自己的檢查點和審查。單獨來看，每個要求都非常合理。但合在一起，它們創(chuàng)造了一個沒有人會有意設(shè)計的工作系統(tǒng)。每個團隊都在為自己的結(jié)果優(yōu)化，而不是為整個系統(tǒng)的結(jié)果優(yōu)化。
結(jié)果，優(yōu)先級變得模糊，工作進展如蝸牛般緩慢，每個人花在會議上協(xié)調(diào)流程的時間比實際交付工作的時間還多。
這不是人的問題，而是善意規(guī)則的堆積讓大家的工作變得更難。這是一個系統(tǒng)問題。
在重新設(shè)計過程中，我們從“偶然的復雜性”轉(zhuǎn)向了“有意設(shè)計的流程”。我們將軟件團隊的體驗置于優(yōu)先位置，并制定了一套關(guān)于工作應(yīng)如何進行的清晰原則。治理并未消失；我們有意地整合了它，創(chuàng)造了透明度，而不是被動地層層疊加需求。
當我們把工作系統(tǒng)當作需要設(shè)計而非繼承的東西時，一切都開始加速。團隊有了更高的清晰度，交接減少了，團隊終于有了空間專注于重要的事情。為了保持系統(tǒng)良好運作，我們不斷審查工作系統(tǒng)，尋找改善成果的機會。
這段經(jīng)歷塑造了我今天看待企業(yè)生產(chǎn)力的方式。
從那時起，我與競相發(fā)布內(nèi)容的市場團隊、打造員工體驗的人力資源團隊、規(guī)劃周期的財務(wù)團隊以及處理復雜交付的運營團隊合作過。每個團隊都想加快節(jié)奏。每種類型的團隊都會遇到同樣的系統(tǒng)性障礙。問題從來不是人，而是工作方式的設(shè)計。
持續(xù)表現(xiàn)優(yōu)異的團隊不需要對抗系統(tǒng)；他們依賴于有意設(shè)計的工作系統(tǒng)。
改善工作系統(tǒng)并不總是需要一個正式規(guī)劃的轉(zhuǎn)型項目。小規(guī)模的干預(yù)可能對組織績效的四個流產(chǎn)生巨大的影響。
以下是四個簡明扼要的行動，幫助你開始改善工作系統(tǒng)：
了解你當前的工作系統(tǒng)：向團隊詢問如何改進工作方式。沒有人比那些正在努力工作的人更了解什么在阻礙工作。了解今天的工作流，以便明天改進它。
減輕認知負荷：簡化并連接工具和流程。大多數(shù)企業(yè)組織中的團隊都在應(yīng)對不必要的步驟、上下文切換和決策稅。
解鎖知識：從以會議和郵件驅(qū)動，轉(zhuǎn)變?yōu)榻⒐蚕砗妥灾R的文化。能夠在需要時獲取所需信息，無需向他人索取，是高績效的基礎(chǔ)。
把 AI 當作隊友：AI 創(chuàng)造額外能力并減少手工勞動。把它嵌入你的工作系統(tǒng)，而不是事后才想起的附加品。
DevEx 向我們展示了當我們有意設(shè)計工作體驗時的可能性。下一個前沿是將這些原則應(yīng)用于整個企業(yè)。
生產(chǎn)力不是運營模式的問題，而是系統(tǒng)問題。DevEx 給了我們解決這個問題的藍圖。獲勝的組織不會是那些擁有最勤奮員工的組織，而是那些設(shè)計工作最出色的組織。
作者：Andrew Boyagio（安德魯·博亞吉）
譯者：木青 ? 編審：@lex
原文鏈接：https://www.cio.com/article/4122240/developer-experience-is-a-blueprint-for-enterprise-productivity.html
