淺談攜程大住宿研發效能提升實踐
一、前言
管理大師彼得·德魯克在《有效的主管》一書中簡明扼要地指出:“效率是‘以正確的方式做事’,效能則是‘做正確的事’。效率和效能不應偏廢,我們希望同時提高效率和效能,但若效率與效能無法兼得時,我們首先應著眼於效能的提升”。攜程大住宿研發效能提升的指導思想就是基於做正確的事展開,並以“持續快速,高質量的交付有效價值”作為研發效能改進的核心目標。透過持續不斷的改進探索,讓團隊思考更加有效,工作更加高效。
在落地研發效能提升的過程中,我們遇到了很多的挑戰,總結下來核心的現象有以下四種:
1. 目標不一致,導致協作低效:大住宿擁有36個規模大小不一的敏捷團隊。有小型的10以下的特性團隊,也有50人以上的全功能敏捷團隊。各團隊相對獨立又存在無法規避的協作關係。當A團隊的目標依賴B團隊的支援,就會存在取捨和協同。當AB團隊目標不對齊時,先完成自身目標還是支援對方完成目標的過程會增加非常多額外的協作溝通成本。
2. 視角割裂,產生無效價值:產品只負責產出需求,開發只管任務完成,最終交付驗收發現不是想要的功能。這是大住宿在敏捷轉型前遇到最頻繁的問題。團隊成員視角割裂導致各角色只關注於自己熟悉的領域,而忽略目標價值的交付,最終會產生非必要的浪費。
3. 基建薄弱,導致額外成本增加:有一種誤會是隻要轉型敏捷研發效率就能10倍數提升。實踐發現,基建的薄弱在一定程度上反而增加團隊的負擔。比如為了持續頻繁的釋出,自動化測試的缺失帶來額外的人工迴歸成本;比如程式碼質量不可靠導致測試頻繁的返工等,在一定程度上不僅影響了團隊交付效率,還導致了使用者滿意度的下降。
4. 度量困難,缺少客觀衡量資料:大住宿的敏捷轉型試點,從一塊物理白板,一堆便籤,幾隻油性筆開始。缺少電子資訊的沉澱,需要完成度量的費力度和成本非常的高。當時為了收集度量的資料,需要人工記錄過程資訊,然後透過Excel梳理整合,再進行分析處理。人為的記錄和分析讓資料缺失一定的客觀性,無法很好的衡量團隊的改進效果,也無法有效引導團隊改進方向。
為了改善以上問題,我們從想好、做好、做快這幾個維度齊頭並進,持續最佳化,深度耕耘:
使用OKR工作法拉通產研,深度協作
使用MVP實踐,圍繞價值交付
透過深度敏捷實踐,打造敏捷企業文化
透過DevOps實踐,支撐團隊快速交付
二、OKR工作法-上下同欲、對齊目標
明確一致的目標是組織內各個部門和全體成員的合作基礎,共同的目標是組織建立和存在的客觀基礎,是完善和發展組織的客觀依據,也是為組織創造更大價值的必備因素。OKR工作法(Objectives&KeyResult,目標與關鍵結果)是一種企業、團隊、員工個人目標設定與溝通的優秀實踐與工具,是透過結果去衡量過程的方法與實踐。同時,OKR還是一種能夠促進員工與團隊協同工作的思維模式。大住宿OKR工作法的落地推進,有效的促進了團隊成員間的緊密協作,同時也迎來了更多的挑戰:
如何讓整個組織的力量都聚焦在重要事項上,助力戰略落地
如何管理組織內的目標橫向對齊,消除“部門牆”的障礙,協作更高效
如何透明化組織、團隊的目標,暴露重複、多餘、無價的任務,節省成本
面對挑戰,大住宿正在持續不斷的探索改進中:
1. 推行產研一體,聚焦整體價值交付。以敏捷團隊為單位,團隊的PO/TO與團隊共創價值,將每個人的工作與團隊目標聯絡起來。以季度為週期進行規劃覆盤,月度review進度和風險的節奏實施落地。無論是技術還是業務的需求,都聚焦到價值的交付上,團隊內部形成良性平衡。
2. 試點部門級別產研一體的季度OKR覆盤活動。為了更好的達到上下和左右對齊目標,提高協作效率,大住宿從今年Q1開始試行部門級產研一體的季度規劃和覆盤活動。各團隊會前準備好覆盤材料;會上回顧覆盤材料並進行討論、反饋和建議;會後根據會議內容形成下一季度的OKR調整內容和建議。透過活動讓大家看到各部門、崗位等相關方的相互依賴關係,明確自己的價值定位、實現團隊間的緊密高效協作。從而打破筒倉效應,最大程度整合組織資源。
3. 藉助IDEV目標管理工具更有效的透明OKR。IDEV是公司提供的統一產品研發管理平臺,大住宿在去年接入IDEV後,不僅提高了產品研發過程的透明性,也率先實現了需求數字化管理。結合實踐管理發現需求目標的明確,可以更好的支撐需求的交付。經過溝通和設計,IDEV平臺開發目標管理功能來支援團隊的數字化目標管理。透過每個需求關聯專屬的KR對齊目標,並使用關聯功能管理依賴團隊間的需求。工具支撐的資訊透明讓團隊更高效的彼此對齊,相互支撐,保證了團隊步調一致,從而完成最終目標的實現。
三、MVP實踐-共識價值,杜絕浪費
O代表一種追求和方向,KR是衡量目標達成的關鍵結果。為了更好地支援KR的達成,團隊統一使用MVP思維。在規定的時間盒內選取最合適的需求,並用最低的成本,最快的速度,向使用者交付產品的主要功能及特色資訊,並透過及早的接觸使用者,獲取客戶反饋和市場驗證來改進產品,迭代升級,以避免做無效需求。
為了更好的落地MVP實踐,大住宿主要採取了以下2個措施:
1. 合理拆分需求,降低試錯成本。需求拆分越小,需求越容易理解,改動成本越低,缺陷暴露越早,價值流動越快,也能更早的交付給使用者,提前得到反饋。但如果需求拆分的過小,分批開發也會帶來測試和釋出的成本增加。如何透過合理的拆分需求,降低試錯成本?
大住宿研發效能改進計劃實施中首先對產研需求進行了規範化的治理,共同約定IDEV上建立的每一個需求都是最小維度的可獨立交付,可獨立驗收且可獨立衡量價值維度。由於產研視角上的差異會產生不合理的拆分需求,研發團隊如果無腦的接受產品拆分,會缺失對需求整體性的認知,也會面臨技術實現相互衝突,還可能會對程式碼架構造成影響。在規範化需求後大住宿又進一步培訓加強產研團隊共同拆分需求機制落地。
2. MVP思維貫穿需求整個生命週期。MVP在實際實踐中容易陷入一個誤區,做完一個MVP就沒有後續。大住宿在 MVP實踐中提倡將思想貫徹到產品的整個生命週期當中。上線的MVP及時的驗證並基於反饋快速的調整尋找下一個方向,迭代迴圈,最終達成目標。敏捷團隊在需求評審會上共識第一次價值,然後在需求上線後及時的驗收,進行第二次價值同步。針對沒有達到目標需求,快速調研分析後會儘快在最近的迭代週期內安排再次上線驗證。整個團隊均始終圍繞價值持續交付。
四、敏捷實踐-敏捷升級,助力效能
敏捷是研發效能提升的又一助力工具。敏捷開發是一種應對快速變化需求的軟體開發模式,核心是小步快跑,快速迭代。
大住宿從2014年開始推行敏捷轉型,敏捷讓團隊實現價值驅動管理。傳統開發模式除了瀑布接力開發外,還有一個是任務驅動管理。任務驅動管理模式下,客戶第一次看到實現的功能可能是在驗收階段,這時候發生需求變化或功能新增都會讓開發團隊的返工成本變得無法預估。還可能為了趕進度,犧牲掉質量。而敏捷開發模式幫助團隊重心放在實現對客戶有價值的需求上,讓團隊關注真正有價值的東西。
大住宿的敏捷轉型是從Scrum開始試點,研發團隊從只關注怎麼實現需求到共同關注優先要實現哪些需求,如何更快的實現。但一支高效能的敏捷團隊,不僅需要高有效的執行落地能力還需要持續不斷的改進能力。缺失任何一種能力,都只會讓敏捷停留在“偽敏捷”上。
酒店研發在轉型路上,也常會因為執行落地不到位而遭遇一些低效的情況:
站會變成彙報會議,只有進度同步沒有阻塞反饋。
回顧會無人說話,事不關己或變成批鬥大會。
計劃會上需求方案還未確認清楚就開始迭代開發,迭代過程中反覆確認,溝通成本增加,工作效率低下。
針對以上問題我們做了如下的改進措施來幫助團隊提高執行,持續改進。
增加敏捷培訓,邀請團隊成員參與到敏捷管理活動中,從實操活動中加強團隊成員對於敏捷中每個角色,每個會議的深層理解。
明確團隊各階段的完成定義並督促落地執行到位。
針對性的開展主題回顧會議,邀請相關干係人共同參與,保持頻繁的反饋,持續改進。
早期的Scrum團隊更多的關注在軟體過程中的活動,而忽略了開發過程中的各種等待時長。Kanban方法的加入幫助酒店團隊看清各種等待不增值的環節。透過Kanban方法拉通產品、設計、互動、開發、測試、BI等各職能各環節的價值流動,並透過IDEV需求管理平臺實現上下游價值的流動視覺化。
改進前團隊的關注重心從“敏捷排期”階段到“待驗收”上線階段。
改進後團隊的關注重心從“需求規劃”階段開始到“完成”階段的整個產品生命週期。
Scrum和Kanban都是幫助團隊儘早交付和持續改進的過程方法,方法各有千秋,合適的才是最好的。只有不斷的實踐,不斷的總結,不斷的調整,才能真正意義上幫助團隊提升。
酒店研發在方法的選擇上,也是基於團隊自身情況進行決策,比如:
有版本限制的團隊,採用Scrum,節奏感可以幫助團隊提高協作效率。
創新型業務,關注快速交付的團隊,採用Kanban,重點聚焦需求價值流動和及時反饋。
單週交付的團隊,採用了Scrum+Kanban混合方式,有效平衡速度和節奏要求。
Scrum
Kanban
實踐核心:化繁為簡
實踐核心:視覺化價值流
定義團隊角色:Scrum Master、PO、Team
無特殊規則
定義迭代,固定時間盒概念(兩週迭代)
限制WIP(work in progress)
Sprint開始後建議不允許新增需求
只要生產力允許,即可新增需求
儘早交付價值
持續改進
八年的敏捷文化薰陶,大住宿大部分的敏捷團隊已從“守”的階段進入“破”和“離”的階段。
1. 守, 團隊能按照scrum的流程去實施敏捷,如團隊中有三個角色(PO\SM\Team),團隊按照四會(站會,計劃會,評審會,回顧會)開展工作等等。
2. 破, 團隊能根據自身的狀況,去突破敏捷原有的部分規則,去到更高的層次,比如根據敏捷的價值觀去增加其它的一些東西,例如增加TO的角色、增加code-review會議等。
3. 離, 團隊的成員已經非常熟悉敏捷的流程和規範,對敏捷的價值觀駕輕就熟。團隊根據自身狀況制定相關的實踐,比如PO/TO共創團隊OKR等。
敏捷實踐的升級讓端到端的產品、開發、利益相關人更順滑的聚合在一起,採用合作共贏的協作方式幫助團隊價值最大化。
五、DevOps實踐-提升質量,加速交付
除了採用目標對齊,共識價值,高效的敏捷實踐等改進措施,想要達到持續頻繁的交付還需要持續整合持續釋出能力的支撐。DevOps強調透過一系列手段來實現既快又穩的工作流程,使每個想法(比如一個新的軟體功能,一個功能增強請求或者一個 bug 修復)在從開發到生產環境部署的整個流程中,都能不斷地為使用者帶來價值。CI/CD作為DevOps的重要組成部分,核心價值便是效能與質量,一方面將整個軟體研發流程自動化,降低人力成本,另一方面提供了相應的質量檢查與測試工具,以期建立一個完整的質量度量體系。
酒店研發引入公司CI/CD解決方案,建立完善的準備環境/測試/資源構建/映象構建一整個流程的鏈路,使它可幫助專案以更快的速度和更高的質量來交付。
以大住宿某前端研發團隊的流水線為例,團隊從以下三個目標出發:
程式碼效能
產品功能
產品效能
透過設定程式碼規範檢查,單元測試、UI測試、效能測試等任務來提升自動化覆蓋率,提升整合效率,強化整體程式碼質量,提前發現問題,最終實現加快交付頻率的目標。並透過採集流水線資料,視覺化專案流水線執行概況、近期質量趨勢,幫助團隊用資料思考,利用資料,持續提升效率。
小結:OKR工作法保障團隊方向正確;MVP實踐幫助團隊聚焦目標價值;敏捷實踐專注快速交付價值,擁抱變化;DevOps助力快速交付,強化自動化能力。四大措施持續改進,最終達到研發效能提升的目的:持續快速,高質量地向使用者交付產品。
六、如何衡量研發效能得到了提升?
管理大師彼得·德魯克還說沒有度量就沒有管理。度量最重要的目的是洞察出問題,進行指導改進,並衡量改進的效果。數字化時代的到來,很多企業已具備自動採集效能資料以實現度量所需的各種實時資料包表。大住宿在去年接入公司統一產品研發管理平臺IDEV後,不僅提高了產品研發過程的透明性,也率先實現了需求數字化管理。
大住宿藉助大量的客觀資料從目標、價值、質量、效率這4個維度的進行分析找到團隊的痛點,並引導團隊做真正能解決問題的行為來持續改善。
1. 核心目標占比
核心目標價值的佔比幫助團隊對齊目標和資源整合。我們透過目標管理工具,規範需求與目標的關聯,再透過度量單位時間內圍繞目標的交付需求佔比來反映團隊的目標對齊度。試點實踐中遇到最大的問題是資料的失真。資料的準確與團隊關聯目標的規範息息相關,需要透過對團隊進行不斷的培訓和宣導來幫助團隊養成習慣,以此保障資料的準確性。
2. 需求價值指數
需求是價值的承載體現,假設交付需求均具有價值,那麼交付需求的數量越多,代表交付的價值越多。但單以需求個數無法很好的反映團隊的交付價值。每個需求的規模和價值大小不一。比如單位時間內可能只交付了一個收益很高的需求,並不能說明團隊的產出變少。團隊需求價值指數從更客觀的維度衡量團隊在單位時間內是否產出高價值的內容,以此杜絕高成本低收益的投入。需求價值指數由團隊負責的需求個數、人員數、預估價值、實際價值、需求價值正態分佈情況等綜合評估得出 。
3. 交付質量
研發交付質量是指使用者感受到的質量,可以理解為線上使用者保障的缺陷。影響交付質量的一個重要因素就是交付過程質量。大住宿主要以單位時間內的缺陷數量趨勢來衡量團隊交付質量。為了降低缺陷數量,研發團隊透過質量內建、提前驗收等各種方法來前置保障交付過程質量。並透過分析線上以及過程缺陷,進行歸因改進。從自動化,Mock工具、開發自測等各個方面著手落實改進措施,持續提升交付質量。
4. 響應能力
需求的響應週期和團隊持續釋出的能力體現團隊的持續和快速。交付週期指對使用者需求、業務機會的響應速度。酒店研發採用從建立需求開始,到需求上線所經歷的平均時長來度量交付週期;透過開始code到釋出上線所經歷的平均時長來度量開發週期;透過單位時間內的有效釋出次數來衡量團隊對外響應和價值的流動速度。經過一段時間的最佳化改進,大住宿2周內交付的需求佔比呈穩定提升趨勢。
七、總結
我們可以透過各種措施來提升改進,但研發效能的提升沒有“銀彈”,研發效能的提升沒有最好,只有更好。需要我們從目標、價值、質量、效率每一個領域都進行深入地挖掘和思考,共同努力把持續改進的焦點從區域性資源效率轉向價值流動效率,以此保證全域性和系統的持續最佳化。
OKR工作法:上下同欲、對齊目標
MVP實踐:共識價值,消滅浪費
敏捷實踐:敏捷升級,助力效能
DevOps實踐:提升質量,加速交付
大住宿依然在探尋更好的效能提升方法的路上,就像敏捷宣言中提到的“我們一直在實踐中探尋更好的軟體開發方法,身體力行的同時也幫助他人。”也希望本篇淺淺的實踐總結可以幫助到對研發效能有期待有困惑的你。
來自 “ 攜程技術 ”, 原文作者:Mia & YY;原文連結:http://server.it168.com/a2022/1212/6779/000006779987.shtml,如有侵權,請聯絡管理員刪除。
相關文章
- KubeSphere 助力提升研發效能的應用實踐分享
- 效能優化,實踐淺談優化
- 攜程:2017年大住宿資料白皮書
- 淺談研發數字化在汽車之家的落地實踐
- 人力節省 50%,研發效能提升 40%,阿里 Serverless 架構落地實踐阿里Server架構
- 關於研發效能提升的思考
- 淺談軟體效能提升相關的概念
- 淺談研發專案經理
- 攜程財報:2020年Q1攜程住宿營收同比下降62%營收
- GTest(基於YApi)介面研發效能提升10倍 實戰API
- 實踐指南-前端效能提升 270%前端
- CSDN周賽第30期:贏圖書《軟體研發效能提升實踐》和定製周邊
- 研發內部控制淺談(一)(轉)
- 研發內部控制淺談(二)(轉)
- 研發內部控制淺談(三)(轉)
- 研發內部控制淺談(四)(轉)
- VC列印實踐淺談 (轉)
- 平臺工程助力企業提升研發效能
- 開源實踐 | 攜程在OceanBase的探索與實踐
- 開源實踐 | 攜程在 OceanBase 的探索與實踐
- 攜程大資料實踐:高併發應用架構及推薦系統案例大資料應用架構
- 提升前端工程化,攜程Design2Code從零到一的實踐前端
- 攜程小程式內嵌webview實踐指南WebView
- 平臺工程如何助力企業提升研發效能?
- AI DevOps | ChatGPT 與研發效能、效率提升(中)AIdevChatGPT
- 攜程DBA負責人俞榕剛:OceanBase在攜程的落地和實踐
- 攜程MySQL遷移OceanBase最佳實踐|分享MySql
- 阿里云云效助力企業10倍研發效能提升阿里
- 淺談效能測試
- Hadoop叢集從180到1500,攜程大資料實踐之路Hadoop大資料
- 攜程 Redis On Rocks 實踐,節省 2/3 Redis成本Redis
- 攜程個性化推薦演算法實踐演算法
- 淺談:前端路由原理解析及實踐前端路由
- 淺談 Laravel Container 及其專案實踐LaravelAI
- 小程式 Serverless: 解放生產力,驅動研發效能提升Server
- 乾貨分享 | 阿里專家親授如何提升研發效能阿里
- Game On Serverless:SAE 助力廣州小邁提升微服務研發效能GAMServer微服務
- 研發效能提升 36 計第一課:網際網路時代研發效能的挑戰和應對之道