從效能公式解構研發效能

這幾年,雲原生、Web3.0、元宇宙等技術的出現和應用,正在深刻地改變着我們這個世界。以數字技術應用爲主線的數字化轉型是此次人類文明變革的核心動力。在這一變革過程中,軟件研發模式的發展起到了重至關重要的作用。從早期瀑布式、精益敏捷、DevOps,再到BizDevOps,其實背後一直在解決的是效能的問題。

效能公式

我們常常聊效能,但研發效能對於不同的人來說,有着不同的定義。對於處在研發一線的個人來說,效能就是提升自己的工作效率,提升工作的幸福感;而對於企業經營者來說,效能就是在不確定性的環境下,確定性地獲得最大的商業成功。

因此,提升效能,就是讓每個人能夠高效、專注的工作,工作更有成就感;提升效能,就是讓一羣人幹成一件值得驕傲的事。

我們之前定義過,研發效能就是組織持續、順暢、高質量交付有效價值的能力。從提升效能的角度,研發效能就是提升個體和協同效率,最大化價值。將這個三個變量組合在一起,形成的效能公式就是:

個體效率 x 協同效率 x 價值 = 研發效能

個體效率

對於個人而言,個人的工作效率其實是最影響幸福感的。事情做不好,很大部分原因是,事情理不清、理不順。老師通過看一個學生的課桌和書包,基本就可以判斷這個學生的學習成績好不好了。桌面乾不乾淨、書本整不整齊、教材和教輔分類是否清楚、考卷有沒有分門別類整理等,這些都直接影響着學習的效率。所謂“學霸兩支筆,學渣文具多”,如果絕大多數時間和專注力花在找書本找文具上,學習自然是好不了的。

另一個影響的效率的重要因素,是那些高頻且低效或易於出錯的工作。簡單重複性強的工作,引入自動化的手段就可以解決。高危操作,出錯和返工的成本都極高。將這些問題,交給工具來完成,可以極大地減少由於人爲操作導致的問題。

所以,我們希望在日常工作中,事情能夠有條理的按部就班,要的東西找得到,看得見。重複繁瑣的事情,讓工具代替手工,更輕鬆地做,省心、安心、放心。我簡單總結,就是三個關鍵詞:找得到、看得見、輕鬆做。

今年,雲效分別升級了全站搜索、個人工作臺、代碼合併、智能測試和應用發佈等能力,旨在讓:

零散信息找得到:通過個人工作臺,我們可以將自己關心的工作內容展現在一個頁裏,“我的項目、我的任務、我的提交、我的發佈”,個人工作臺就是自己的專屬線上辦公桌。像整理自己桌面一樣整理好自己的工作臺,讓任務輕鬆觸達;同時,通過全站搜索能力,無論是需求、任務、缺陷、代碼、應用、變更等等,都能通過 CMD + K 找到。

 

任務、進度看得見:每個人對自己關心的任務、關心的進展,都能輕鬆地看見。就像觀測地鐵到站表一樣,非常清晰地知道當前任務經過了哪些階段,當前處在什麼階段,到結束,還需完成哪些階段。

代碼提交輕鬆合:開發者有大量的代碼合併和評審的場景,通過輔於自動化的檢測能力,幫助開發者在代碼合併的時候,輕鬆判斷合併條件,有針對性地進行評審,放心輕鬆地合併代碼。讓代碼合併省心。

迴歸測試輕鬆測:測試工作在軟件研發過程中,承擔着非常重要的質量守護工作,測試工作從寫case、準備環境、準備數據...,瑣碎而重複,對於這樣的工作,我們建議這樣的工作交給工具來做,雲效除了接口測試、UI測試這些傳統的測試工具之外,推出智能流量回放測試。採用智能流量回放測試,可以自動生成測試用例,自動生成測試數據,自動Mock,大幅節省迴歸測試的成本。讓質量內建安心。

應用上線輕鬆發:軟件的發佈在雲研發時代是一個高頻操作,同時也是高危操作。雲效應用發佈平臺AppStack,推出面向雲原生的應用發佈能力,將資源、流程和工具以應用爲核心組織在一起,從應用的創建、代碼變更、部署發佈整個流程固化下來,減少過程中由於人爲操作不當而引起一系列問題。同時,部署是最後的臨門一腳,輔於發佈過程中的可觀測能力和部署模式的支持,有效降低發佈過程中的風險,應用的發佈上線不再熬夜加班。讓應用發佈放心。

只要善於發現,可提升、改進的機會還有很多。不要低估持續不懈地優化和改變,進步的力量,始於每一點微小的改變。

協同效率

如果說個體效率的提升,影響的是工作倖福感的話,那麼協同效率的提升反映的就是組織的成熟度和活力。

軟件研發是典型的集體性創造活動。人多了,就會有分工,分工有很多好處,亞當·斯密最早提出了分工理論,通過比較優勢,分工可以提高效率。但隨着組織的發展,職能分工帶來最直接的問題就是:效率豎井。

關於效率豎井,我們以前講過很多次。不同的職能分工,職能間的關注點不同,優先級不一致,經常出現扯皮的現象。同時,在整個交付過程中,出現阻塞、等待、返工的情況。彼此溝通過程中,概念不一致,雞同鴨講,聊不到一塊兒。這樣的後果是,每個團隊看上去,繁忙而高效,而整體卻效率低下。

協同的目標,就是讓一羣人確定性地共同完成一件大事。整個協同應該是一條通路,通是關鍵。在DevOps中,打破Dev和Ops的牆是爲了通,在BizDevOps中,打通Biz和DevOps的牆,也是爲了通。這裏我把它歸納爲兩個關鍵詞:連接和透明

通過一個需求,與應用的變更建立關聯,通過一個需求,與代碼合併請求建立關聯。雙向互聯互通,基於統一的數據模型,將這些核心作業對象關聯起來,形成一張價值網,這樣就建立起來了從協作到工程的完整鏈路。

連接的意義,遠大於在研發流程中,將工具簡單的拼裝在一起。有了核心工作對象的關聯,就像接通了整個研發協同系統的血液循環,活了過來,整個系統也就具有了生命力。

連接建立了基礎,透明化就不再話下。這樣,整體的工作進展,從需求、代碼、發佈完全打通,工作進展更準確、透明。迭代進展能夠及時、準確地看到;工作安排是否合理,通過工作負載也能展露無疑。

有了連接做爲基礎,數據在各環節就能共享,任務和進展可以輕鬆看得見,效能現狀也能輕鬆看得見。

一羣人,安排了哪些活、在哪一天,工作量是否過大等等。對於管理者而言,效能現狀也能做到胸有成竹,團隊效能有沒有“病”,要不要“吃藥”,有了數據的支撐,就能做到對症下藥了。

同時,通過關係和信息的配置,將流程固化在工具上。讓過程管理不再侷限於紙面文章,而是可運行、可重複、可推廣。

然而,無論是提升個體效率,還是協同效率。在軟件研發工作中最大的問題,其實是機會的浪費。

價值

選擇比努力重要。資源這麼多,只能選擇最有價值的事情來幹。如果說連接是血液循環系統的話,那麼價值就是這個系統支撐的魂。但實際的工作中,往往容易丟了“魂”。丟了“魂”的工作是怎麼樣的呢?

是工作說不清楚價值;是需求很多,但不知道哪個更重要;是我的工作和老闆關心的工作不一致;是需求層層分解、任任層層轉交,導致信息嚴重失實。

人就那麼多,時間也很有限,選擇一件對的事情,並且做好分解和傳遞很重要。所以,我認爲做好價值最大化的兩個關鍵因素是:選擇和傳遞

關於選擇,收益和成本是最簡單的兩個變量,通過收益除於成本就可以簡單得到一個基礎投資收益得分,基於此做爲選擇需求的參考。

一定會有朋友說,價值模型有很多,單純靠這兩個變量是否過於簡單。其實,從本質上講,無論多麼複雜的價值模型,背後的底層邏輯都是收益和成本。有了這兩個簡單的變量,爭論便有了基礎,而不是看誰嗓門大、關係親疏、職級高低來決定做哪個需求。這就很有意義,讓價值的爭論發生在越早越好。

同時,有了評估選擇的基礎,我們就可以做到:以終爲始(在開始的時候,就以最終想達成的結果來進行評判選擇)和量出而入(在排入需求的時候,就以輸出的時候爲標準,無論是質,還是量)。

從收到一個前線的原始需求,轉化爲一個產品主題,再逐層分解,直到開發任務,這是整個價值傳遞的過程。研發的整個流程,其實就是價值流,價值流上的各環節是增值活動。這樣,整個價值鏈上的每個事情都是有價值的,每個事情也都能說明價值。

同時,對於業務、產品或技術來說,用一套話語體系說話。從原始輸入,到產品需求,再到技術任務,雲效通過關聯所有的核心對象,讓事事有着落,件件能溯源。

寫到最後

通過讓事情找得到、看得見、輕鬆做,提升工作的幸福感,提升個體效率。通過連接和透明化,建立彼此協作的橋樑和信任,提升協同效率。通過價值有效選擇和傳遞,最大化價值。整體共同作用,提升研發效能。

基於這個邏輯,讓我們從面向流程到面向價值進化,從提升效率到提升效能進化。當然,雲效也無法兼顧到研發活動的方方面面,我們願意和我們的夥伴和用戶一起努力,做一點點改變。進化,其實就是每一點點進步。

感謝我的同事們努力的工作,讓進步一點點發生。最後,歡迎大家對我們的產品提出更多的想法和建議。

原文鏈接

本文爲阿里雲原創內容,未經允許不得轉載。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章