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