敏捷管理數(shù)字化轉型項目這兩個詞放在一起我在不同企業(yè)里見過太多次了。有的團隊把這兩件事做成了漂亮的雙人舞有的團隊卻把敏捷做成了每周兩次的“追債會”項目照樣延期業(yè)務照樣不滿意。我印象最深的是一個做了大半年的數(shù)據(jù)中臺項目二十多個模塊幾百條需求按傳統(tǒng)里程碑排得滿滿當當結果到了測試階段才發(fā)現(xiàn)業(yè)務口徑全是各說各話返工成本高到差點把整個項目組打散。后來我們硬是把管理模式換成雙周迭代才一點一點把項目拉了回來。這篇文章想聊的就是這個過程里反復被驗證過的東西敏捷管理到底解決數(shù)字化轉型項目里的什么問題落地時有哪些真正管用的動作以及那些文檔里不會寫、只有踩過坑才知道的挑戰(zhàn)和對策。無論你是項目經(jīng)理、產品負責人、技術負責人還是被拖著一起做敏捷改造的業(yè)務方這幾個月里你在真實項目里遇到的大部分困惑應該都能在這里找到一點參照。1. 數(shù)字化轉型項目為什么非得換管理打法1.1 傳統(tǒng)計劃驅動模式的失靈現(xiàn)場很多數(shù)字化轉型項目一開始還是按老套路走花兩個月做需求調研出一份厚厚的高保真需求文檔定死里程碑按瀑布往下推。表面上看計劃周密、責任清晰實際上問題從需求收集階段就埋下了。業(yè)務部門在項目最開始的時候往往根本說不清楚自己要什么。不是他們不配合而是數(shù)字化帶來的變化本身就是探索性的。你問一個銷售負責人“你希望CRM系統(tǒng)有什么功能”他只能告訴你要“跟單方便一點”“報表好看一點”但客戶是怎么從線索變成訂單的、中間有哪些關鍵動作、這些動作之間什么數(shù)據(jù)會改變這些細節(jié)他從來沒有系統(tǒng)梳理過。等系統(tǒng)做出來他發(fā)現(xiàn)業(yè)務流程根本不是自己腦海里那個流程于是提出幾百條修改意見開發(fā)團隊又回頭翻需求文檔發(fā)現(xiàn)文檔里寫的和實際需要的完全是兩回事。傳統(tǒng)管理模式在設計時前提是“需求可以提前完整獲取變化越晚代價越大”所以它要求盡量晚變化。可數(shù)字化轉型項目的本質恰恰相反需求從一開始就是模糊的業(yè)務路徑要邊試邊定技術方案也要邊做邊驗證。用計劃驅動的方式去管一個探索性的項目等于要求一輛車在沒有地圖的山路上按固定時刻表行駛時刻表排得再精細也是廢紙。1.2 數(shù)字化項目的三個不確定性來源我習慣把數(shù)字化轉型項目里的不確定性分成三類每一類都會直接沖擊傳統(tǒng)管理模式的根基。第一類是業(yè)務不確定性。數(shù)字化轉型表面上是在上系統(tǒng)實際上是在重構業(yè)務流程。流程重構意味著業(yè)務方自己也不知道未來的流程長什么樣今天確認的規(guī)則下周可能因為一個外部政策或者市場競爭變化就要調整。這種不確定性發(fā)生在業(yè)務側靠提前做需求文檔解決不了。第二類是技術不確定性。很多數(shù)字化項目涉及系統(tǒng)集成、數(shù)據(jù)打通、接口適配新舊系統(tǒng)之間有多少雷只有做到那一步才知道。老系統(tǒng)的數(shù)據(jù)質量差到什么程度外圍接口文檔和實際邏輯有多少出入這些問題不開發(fā)到對應模塊根本暴露不出來。技術上的不確定沒法靠專家評審消除只能靠真實環(huán)境里的嘗試來逐步降低。第三類是組織不確定性。數(shù)字化轉型要動的不只是IT系統(tǒng)還有組織里的權力結構、匯報關系、績效考核方式。某部門上了自動化報表原來靠手工處理數(shù)據(jù)的崗位怎么辦數(shù)據(jù)中臺把各業(yè)務線的數(shù)據(jù)集中起來以后誰有權限看什么、數(shù)據(jù)歸誰管這些組織層面的問題一旦處理不好項目推進會變得異常緩慢拖的是人不是事。1.3 敏捷管理到底在解決什么很多人把敏捷管理理解成“快”以為敏捷就是把大任務切成小塊、快速交付。這話只對了一半。敏捷真正解決的不是“快”而是“讓錯誤早點暴露”。迭代越短反饋循環(huán)就越快。開發(fā)團隊做完兩周的內容業(yè)務方可以馬上看到可運行的東西說出真正的意見這個意見比任何文檔評審都真實。對于數(shù)字化轉型項目這種不確定性極高的場景早點暴露錯誤、早點調整方向比嚴格按計劃執(zhí)行要重要得多。敏捷的另一個核心價值是信息透明?？窗迳系目ㄆ腥舜笱鄣尚⊙廴急M圖一條線拉下來該誰在哪個環(huán)節(jié)卡住了一目了然。傳統(tǒng)管理模式下信息分散在各自主管的腦子里出問題往往是等到內測階段才爆雷敏捷管理模式逼著所有人在同一個場域里同步狀態(tài)問題剛冒頭就被盯上了。我個人的經(jīng)驗是敏捷不是銀彈但它是玩“模糊開場”的項目時目前最靠譜的一套組織方式。它未必能讓項目不延期但能讓延期發(fā)生得早一點、可控一點、有解釋一點。2. 動手之前先把敏捷的本土化方案定清楚2.1 選型不是所有團隊都適合同一個框架敏捷管理并不是只有一種打法。我跟很多項目組聊過發(fā)現(xiàn)大家一提敏捷就默認是Scrum這其實是個很大的誤區(qū)。Scrum、看板Kanban、Scrumban混合模式適合的場景差別很大。Scrum的特點是固定節(jié)奏、固定儀式、固定角色適合需求相對明確但開發(fā)過程需要強迭代的產品型項目。比如一個面向內部用戶的OA系統(tǒng)改造功能邊界大致清楚通過高質量沖刺把功能一個個打磨出來。看板的特點是限制在制品數(shù)量、管理流動效率適合需求持續(xù)流入、優(yōu)先級變化頻繁的運維型和支撐型項目。數(shù)據(jù)接口開發(fā)、數(shù)據(jù)質量治理這類工作很難切成標準的用戶故事用看板管理流動狀態(tài)比機械跑迭代更合適。Scrumban混合模式是我在真實項目里用得最多的一種。核心思路是保留Scrum的節(jié)奏感固定的周例會、回顧會但引入看板的流程管理和在制品限制。它特別適合數(shù)字化轉型項目里的數(shù)據(jù)組比如數(shù)據(jù)管道建設有明確的開發(fā)任務但又不能按用戶故事完全拆分混著用反而靈活。選型的關鍵不是標準不標準而是夠用。團隊不再為“我們是不是不夠敏捷”而糾結就看“當前的工作性質適合用什么方式排布優(yōu)先級和反饋節(jié)奏”。2.2 試點范圍先拿一個模塊做樣板很多項目一上來就要“全公司推廣敏捷”這是災難的開始。我的建議是永遠先拿一個模塊做試點。試點模塊怎么選三條標準第一業(yè)務價值清晰做完之后能明顯看到變化第二相關業(yè)務人員愿意投入時間而不是被迫配合第三模塊邊界不要太大最好是一個月內能跑完一個完整迭代的。我經(jīng)歷過一個反例某制造企業(yè)的數(shù)字化轉型項目試點選了公司最核心的ERP切換。當時覺得核心系統(tǒng)影響大、成功后說服力強結果整個模塊涉及八個子系統(tǒng)、十幾個外圍接口試點團隊一半時間都在處理歷史數(shù)據(jù)遷移迭代節(jié)奏完全跑不動。后來換了供應鏈庫存預警模塊團隊第一次跑完雙周迭代時業(yè)務方親眼看到庫存積壓的自動分析報表出現(xiàn)在眼前才真正理解敏捷是什么感覺。試點的作用不只是驗證方法更重要的是積累可信案例。業(yè)務部門的信任不是聽你講道理講出來的是看到一個真實可用的東西擺在面前才有的。2.3 四個前置輸入需要提前準備正式開始迭代之前有四樣東西必須準備好不然后面全是坑。第一是用戶故事地圖。把業(yè)務方想實現(xiàn)的整體能力從左到右鋪開然后從橫向切出一個個版本范圍。它幫助團隊搞清楚這一期迭代到底解決用戶哪一段旅程上的問題而不是無休止地羅列功能清單。第二是完成的定義DoD。每一張卡片做到什么樣才算“完成”必須先約定清楚。是代碼寫完了還是聯(lián)調過了還是業(yè)務驗證過了數(shù)字化轉型項目中經(jīng)常是開發(fā)覺得“我完成了”業(yè)務卻覺得“我沒看到東西”。DoD的意義就是把兩邊對“完成”的主觀理解變成客觀標準。第三是節(jié)奏感。選雙周還是一周一迭代團隊要達成一致。節(jié)奏一旦定下來計劃會、評審會、回顧會的時間就是固定不變的就像人的生物鐘讓團隊進入循環(huán)。第四是角色邊界。產品負責人、敏捷教練、開發(fā)團隊、業(yè)務代表誰決策、誰支持、誰執(zhí)行。很多項目沖突的根源不是能力問題是邊界模糊。產品和業(yè)務爭奪優(yōu)先級開發(fā)和測試爭奪需求理解所有問題都可以追溯到角色邊界沒寫清楚。3. 落地推進一套可以直接用的雙周迭代實操法3.1 迭代節(jié)奏怎么定節(jié)奏是整個敏捷運行的骨架。我在大多數(shù)數(shù)字化轉型項目里推薦雙周迭代理由很簡單一周太短很多任務剛進入開發(fā)就要評審團隊的儀式負擔過重一個月太長反饋循環(huán)太慢業(yè)務方等得失去耐心。單周迭代適合需求明確、團隊成熟、改動量小的小型項目。雙周迭代是大多數(shù)項目的甜點區(qū)。月度迭代不是不能用但只適合底層技術預研項目比如評估一個新的數(shù)據(jù)架構方案這時候業(yè)務反饋本來就少重點是技術驗證。節(jié)奏表可以參照這種模板迭代周期兩周四天左右開發(fā)第1天到第4天一天聯(lián)調測試第5天到第6天周五下午做評審和回顧。評審會上開發(fā)團隊給業(yè)務方現(xiàn)場演示兩周的成果業(yè)務方直接反饋評審結束后產品負責人組織下一輪迭代計劃會。迭代中間最多增加一次全組同步的站會其余時間按看板自轉。迭代計劃會上只做一件事把下一迭代的目標講清楚把拆分好的卡片分配到人頭。業(yè)務方不是每張卡片都要來但目標那部分必須來確認因為迭代目標就是他們的需求優(yōu)先級體現(xiàn)。3.2 五個核心儀式的具體開法敏捷管理的五個儀式每個都有明確產出。弄明白每個儀式到底要達成什么結果才不會淪為走形式。迭代計劃會第1天2小時以內目標是確定本迭代“做什么事、達成什么目標”。不是把所有需求細節(jié)重新講一遍而是基于需求池里排好優(yōu)先級的卡片讓團隊對目標和工作量達成一致。參會人產品負責人、開發(fā)團隊。業(yè)務代表可以只參加目標確認部分。每日站會15分鐘回答三個問題——昨天做了什么、今天準備做什么、有什么擋路的問題。站會不是匯報給領導聽的是團隊內部信息同步的機制。任何超出15分鐘的話題拉出來單獨開會解決。迭代評審會第2周周五1到2小時團隊演示真實可運行的功能業(yè)務方現(xiàn)場體驗并給出反饋。評審會很忌諱做PPT講進度PPT誰都會講真東西一演示問題自然就暴露了。迭代回顧會評審會后1小時圍繞三個維度復盤做得好的是哪方面做得不好的是哪方面下個迭代打算嘗試改變哪一個動作回顧會的產出不是感慨是一個具體的改進行動項比如“下個迭代每天17點前合并代碼”。需求梳理會每周一次1小時產品負責人跟業(yè)務方一起過需求池拆大需求、補細節(jié)、重新排優(yōu)先級。很多人以為敏捷不需要需求分析其實恰恰相反敏捷的需求分析是持續(xù)發(fā)生的而不是一次性寫完的。3.3 需求池、看板、燃盡圖的日常維護需求池Product Backlog是項目管理里的中樞。我在真實項目里見過很多團隊把需求池當成Excel表格貼了一堆流水賬優(yōu)先級亂七八糟。合格的需求池應該像一張購物清單每一行是一個可以開發(fā)的用戶故事包含描述、優(yōu)先級、預估工作量、驗收標準而且永遠按優(yōu)先級從上到下排列。看板的字段設置很關鍵字段太多維護成本高字段太少信息同步不夠。推薦用的基本字段是待梳理、待開發(fā)、開發(fā)中、待測試、測試中、已完成?？窗迳系拿恳粡埧ㄆ瑫r只允許一個環(huán)節(jié)“開工”也就是所謂在制品限制WIP。設置WIP限制的作用是防止大家同時開一堆任務最后沒有一件事能收尾。燃盡圖是雙周迭代中最直觀的管理工具。橫軸是迭代天數(shù)縱軸是剩余工作量每天匯總一次剩余工作量的總和描點連線。如果燃盡圖在前幾天沒有下降說明迭代目標可能拍大了如果最后一天突然飆升說明范圍蔓延了或者測試問題集中爆發(fā)了。燃盡圖不怕難看怕的是沒人看。3.4 度量指標的取舍數(shù)字化轉型項目里衡量敏捷有沒有跑起來我用四個指標速率每個迭代能完成的點數(shù)、周期時間一張卡片從開始到完成需要幾天、缺陷逃逸率發(fā)布后才被發(fā)現(xiàn)的缺陷占比、需求變更頻率迭代內需求被修改的次數(shù)。這四個指標里容易被玩壞的是速率。有的團隊為了讓速率好看故意把大工作量拆成一堆小卡片最后數(shù)量是唬住了但交付的能力并沒有提升。我一般不看速率絕對值只看速率趨勢。速率如果連續(xù)兩個迭代下降不是團隊在偷懶就是在還上一個迭代欠下的技術債。周期時間是更值得盯的指標。比如一個數(shù)據(jù)訂單同步任務從開發(fā)到上線有時候周期是三天有時候是十五天。把每一張卡片的周期時間統(tǒng)計出來就能定位到瓶頸——到底是在聯(lián)調環(huán)節(jié)堵了還是在測試環(huán)節(jié)排隊了。這是傳統(tǒng)項目管理里很難看見的東西。4. 真實項目里避不開的六個挑戰(zhàn)與應對4.1 業(yè)務方不參與需求永遠處于“待確認”癥狀需求池里的卡片永遠堆在“待梳理”業(yè)務方回復消息要隔一兩天評審會約了三次約不齊人。到了迭代快結束時才冒出來說“這個功能不是我們想要的”。原因業(yè)務方本身有自己的崗位工作數(shù)字化項目在他們眼里是“幫忙做的額外任務”優(yōu)先級天然排不上去。應對建議第一步是讓項目成為業(yè)務方的業(yè)績而不是負擔。比如在評審會上請業(yè)務方的領導來驗收業(yè)務方提出的改進需求變成業(yè)務方展示自己的舞臺。第二步是管理參與承諾明確雙周評審會是業(yè)務決策的固定時間如果業(yè)務代表兩次缺席優(yōu)先級決策權就默認上提到分管領導。大部分業(yè)務方真正缺席不是忙而是覺得這個項目自己說了也不算。4.2 數(shù)據(jù)類任務難拆分數(shù)據(jù)管道一跑就是兩周癥狀開發(fā)團隊在做數(shù)據(jù)集成任務發(fā)現(xiàn)一個數(shù)據(jù)管道從源系統(tǒng)抽取到清洗到裝載整個流程要連續(xù)跑一周多。雙周迭代計劃的卡片還沒開發(fā)完迭代就結束了。原因數(shù)據(jù)工程任務天然依賴整體流程很難像頁面功能那樣切成互相獨立的用戶故事。應對建議不要強行把數(shù)據(jù)任務拆成假故事。對于依賴鏈很長的任務用“里程碑故事”的方式管理把任務分成三段接通源頭、清洗轉換、對外提供接口每一段都設定獨立的驗證標準。不能因為任務長就不拆分而是按技術節(jié)點拆不是按業(yè)務功能拆。同時把公共的管道建設放進技術預研迭代而不是塞進業(yè)務迭代里。4.3 組織考核還看季度KPI敏捷與人力資源制度的沖突癥狀敏捷講的是跨職能協(xié)作、快速響應變化但組織考核還是每個人背了季度KPI。開發(fā)人員和業(yè)務人員的KPI不統(tǒng)一導致兩個團隊在協(xié)作時互相保護自己的“責任田”。原因敏捷的反饋循環(huán)是雙周的但人力資源的評估周期是季度的。當兩者沖突時員工會很自然地按考核導向行事。應對建議短期內在敏捷框架里加一個“績效牽引動作”迭代目標與小組季度目標做對齊評審會上把迭代成果對應到季度KPI證據(jù)上。長遠來看需要在項目層面重新設計協(xié)作KPI比如將“雙周交付承諾達成率”“跨部門協(xié)作反饋分”納入季度考核而不是個人英雄主義的考核。4.4 遠程辦公下站會淪為匯報會癥狀團隊成員分布在不同的城市站會開著視頻輪流念自己昨天做了什么。每個人都在給屏幕那頭的領導匯報沒有人真正在聽別人說什么。站會從信息同步工具變成了表演會場。原因遠程場景下面臨信息不對稱團隊不自覺地把站會當作“我在干活”的證據(jù)。動作沒有對準協(xié)作價值自然就滑向匯報。應對建議站會強制使用看板說話。每張卡片指到哪張就說那張卡片的狀態(tài)不說不相關的話題?？ㄗ〉膯栴}當場指定一個人負責跟進剩下的人繼續(xù)看板流轉。同時把發(fā)言時間壓縮到15分鐘以內超過時間就停。如果連續(xù)幾次站會都沒有任何協(xié)作話題說明團隊實際溝通通道有問題要看板找堵塞點而不是在站會里找話題。4.5 合規(guī)審批卡在迭代中間癥狀開發(fā)兩周做完的功能上線前需要安全審查、合規(guī)審批、業(yè)務確認這些環(huán)節(jié)不在迭代流程里往往在評審會上才發(fā)現(xiàn)“功能做完了但上不了線”。原因數(shù)字化轉型項目通常涉及大量敏感數(shù)據(jù)合規(guī)要求高。敏捷迭代速度快了但合規(guī)審批流程沒有跟上迭代節(jié)奏。應對建議把合規(guī)檢查點前移到迭代內部。在計劃會上就要對未來兩周可能涉及的新數(shù)據(jù)字段、外部接口、權限變更做出標記提前跟安全和合規(guī)團隊打招呼。同時把合規(guī)審批作為迭代完成的必要條件寫進DoD不要在評完代碼之后才想起合規(guī)審查。4.6 各團隊節(jié)奏不同前端兩周、算法兩周、數(shù)據(jù)一個月癥狀前端團隊按雙周迭代跑得歡算法團隊要訓練模型一個迭代根本跑不完數(shù)據(jù)團隊的數(shù)據(jù)源接入還要等外部系統(tǒng)配合?？鐖F隊聯(lián)動時節(jié)奏不同導致互相等對方。原因數(shù)字化項目通常不只有一個團隊不同團隊的任務性質天然不同。算法訓練、數(shù)據(jù)治理這類任務需要長周期而頁面迭代適合短周期。應對建議不要強求所有團隊同一個迭代周期。在項目層面引入“對齊點”每兩周做一次跨團隊集成評審各團隊在同一個時間窗口同步進展。內部各自的迭代周期可以不同前端保持雙周算法可以月度對齊數(shù)據(jù)組用看板做連續(xù)流動但必須在對齊點之前給出當前階段可驗證的中間產物。5. 什么時候該調整敏捷策略一套現(xiàn)場診斷方法5.1 三個預警信號第一個預警信號是需求池的規(guī)模持續(xù)膨脹切新卡片的速度遠遠快于消耗卡片的速度。這說明團隊只是在形式上做敏捷并沒有真正做優(yōu)先級取舍。我見過某項目的需求池堆了一千多張卡片開會光順著需求池走一遍就花了兩小時這是庫存災難。第二個預警信號是燃盡圖長期脫離計劃線。這說明團隊對工作量的估算能力嚴重不足或者存在大量被忽略的隱性工作。偶爾偏離是正常的連續(xù)三個迭代都偏離就要停下來找原因而不是靠加班硬撐。第三個預警信號是團隊開始自發(fā)回避儀式。今天有人請假明天有人遲到后天上線發(fā)布延后隊伍對儀式失去了信任。儀式本身不是目的但如果團隊連儀式都不愿意開了意味著敏捷已經(jīng)失去了信息同步的作用大家在形式上敷衍或者在私底下繞開流程。5.2 不同項目類型怎么調整周期和儀式技術預研型項目任務可能在幾周內看不到明顯產出適合用月度迭代加每周技術同步會。不宜用太多儀式擠壓預研時間重點是讓團隊有連續(xù)整塊的時間做技術嘗試。業(yè)務快速試錯型項目比如某個新渠道的數(shù)字化營銷場景業(yè)務方需要頻繁驗證市場反饋適合縮短迭代周期到一周甚至按看板做連續(xù)交付重點是快速給業(yè)務方可體驗的東西。監(jiān)管合規(guī)型項目比如數(shù)據(jù)安全項目、客戶隱私保護改造這類項目合規(guī)節(jié)點比敏捷儀式更重要。敏捷框架可以作為執(zhí)行跟蹤工具但發(fā)布節(jié)奏要服從合規(guī)審查節(jié)奏迭代內留足合規(guī)審批時間。5.3 從“按流程走”到“按價值流走”的進階敏捷管理做到后期最有效的進階不是加更多儀式而是從“怎么把迭代跑順”轉向“怎么讓價值更快流動”。我習慣讓團隊做一件事梳理端到端的交付時間。比如一個數(shù)據(jù)報表需求從業(yè)務方提出那天開始到報表上線真正被業(yè)務方看到中間花了多久很多人會驚訝地發(fā)現(xiàn)真正的開發(fā)時間只有三天但在需求池里排隊等了七天測試又排了四天審批再耗掉兩天。敏捷的迭代跑得很順但整個價值流卻慢得要命。這時候要把注意力從“迭代內產出”轉移到“隊列和瓶頸”上。看板上的卡片堆積在哪個環(huán)節(jié)就說明瓶頸在哪里。用手里的工具把瓶頸拉平比多開幾個儀式有意義得多。結語敏捷不是萬能藥但值得認真落地做了這么多年的數(shù)字化轉型項目我的感受是敏捷管理真正的價值不在于它叫敏捷而在于它逼著項目里的每一個人把模糊的問題早一點暴露在陽光下。業(yè)務方早點看到真實產品開發(fā)團隊早點聽到真實反饋管理者早點看到哪里堵了這些比任何流程標準都重要。它也真的不是萬能藥。碰上極度依賴外部化石系統(tǒng)的項目、碰到業(yè)務方壓根不想配合的場景、碰到組織考核與敏捷節(jié)奏全面沖突的環(huán)境敏捷只能幫你把問題看得更清楚不能替你去解決那些組織層面的頑疾。但反過來講恰恰是這些問題暴露得越早項目才越有救。最后分享一個小技巧如果你的團隊剛開始做敏捷別急著把框架里的所有東西都推倒重來。先維持你現(xiàn)有的項目管理框架只加兩件事——固定的雙周評審會和需求池的優(yōu)先級排序。把這兩件事做穩(wěn)了再逐步引入站會、回顧會、燃盡圖。敏捷是長跑不是百米沖刺節(jié)奏對了比什么都重要。