敏捷轉型為什麼推不動？先判斷人們處於哪個變革階段
敏捷轉型為什麼推不動？先判斷人們處於哪個變革階段
作者：范育銘
刊登時間：August 17, 2026
敏捷轉型為什麼推不動？先判斷人們處於哪個變革階段
文章內文
從兩次轉型經驗，談業務問題、關鍵角色與 Rick Maurer 的變革循環
高層已經宣布轉型，團隊也接受了培訓，新的流程甚至已經上線，為什麼大家還是不願意改變？
問題可能不在方法，而在於推動者與組織成員根本不在同一個變革階段：高層已經準備全面推行，第一線成員卻還沒有看見改變的必要；轉型小組忙著設計流程，部門主管仍在懷疑這件事能否解決自己的問題。
這時候，繼續宣傳 Scrum、增加培訓或要求大家遵守流程，通常只會帶來更多抗拒。
我曾參與數位化轉型、流程改進與敏捷轉型。回頭看這些經驗，我逐漸形成一個判斷：
敏捷轉型不是導入一套框架，而是圍繞真實的業務問題，集結組織內可用的力量，並根據人們所處的不同變革階段採取行動。
因此，在討論如何推動變革之前，我們需要先回答兩個問題。
第一個問題：這次轉型要解決什麼業務問題？
我第一次深刻體會這件事，是在一家銷售型企業導入 Scrum 的時候。
這家公司的主要業務是辦公家具與影印機的銷售和租賃。產品使用與租賃週期很長，如果業務人員與客戶往來的頻率太低，很容易在下一次採購時失去客戶。公司因此決定發展辦公用品採購服務，希望透過更高頻的交易維持客戶關係。
當時，新的業務模式還沒有成形，客戶究竟需要什麼也不清楚。我們沒有先要求其他部門「配合 Scrum」，而是由開發團隊先建立兩週一次的交付節奏，持續與業務端核對需求，再根據回饋調整產品。
這種工作方式幫助團隊提早發現需求問題、降低重工，也逐漸建立了回應變化的能力。新業務啟動後不到半年，在沒有額外行銷投入的情況下，以該項業務的單月營收為統計口徑，月營收從 0 成長至人民幣 300 萬元。
這個結果不能只歸功於 Scrum。Scrum 真正提供的，是短週期驗證、快速回饋和持續修正的工作方式，讓團隊更快找到可行的業務模式。
更重要的是，我們對外很少強調「現在要導入 Scrum」，而是持續談如何加快回饋、降低風險和解決客戶問題。當成果逐漸出現，業務端不只願意配合，還會主動提出更好的做法。
因此，如果導入 Scrum 時遇到阻力，先不要急著問「為什麼客戶不配合」，而要問：
我們正在解決對方真正關心的問題，還是把 Scrum 當成一顆用來矯正別人行為的子彈？
第二個問題：有哪些人和資源可以共同推動改變？
另一段經驗發生在我加入某家公司的數位化部門之後。
當時公司正面臨經營壓力與裁員，但許多關鍵服務仍依賴數位化產品，三、四百人的部門必須在不確定的環境中穩住交付。
一開始，我們嘗試讓工作模式向 SAFe 靠攏，卻很快遇到不同角色的懷疑：有人不理解框架，有人擔心職責改變，也有人認為新活動只會增加負擔。推動約一個月後，我們意識到，單靠轉型團隊設計流程，很難讓跨部門工作真正發生。
於是，我們成立敏捷轉型委員會，邀請專案、產品與技術主管，以及各部門代表加入。主管的任務不是親自設計每一個流程，而是提供授權、資源與跨部門決策；轉型工作小組則負責流程設計、溝通協調和推動落地。
我們做了三項調整：
這套機制不能被視為公司度過經營低谷的唯一原因，但它協助數位化部門穩住關鍵服務的交付。推動後，整體交付週期從 53 天縮短至 30 天。關鍵角色開始共同理解任務與目的，跨部門團隊也逐漸依靠同一套節奏對齊依賴關係、處理問題和做出決定。
這次經驗讓我更確定：
變革不是要求別人變成我們預先想好的樣子，而是讓相關的人共同決定「我們希望成為什麼樣子」。
確認業務問題、找到共同推動改變的人之後，下一個問題才是：現在應該採取什麼行動？
用變革循環判斷：現在真正需要的是什麼？
變革顧問 Rick Maurer 提出的「變革循環」（Cycle of Change），將變革分為六個階段：In the Dark、See the Challenge、Get Started、Rollout、Results，以及 Time to Move On。Maurer 的模型改編自 Cleveland Gestalt Institute 的 Cycle of Experience，重點是幫助推動者判斷不同利害關係人的狀態，理解抗拒從何而來，再選擇適當的行動。
這個模型不是一張讓整個組織依序打勾的專案清單。高層、部門主管、轉型小組和第一線成員，可能同時處於不同階段。真正有用的診斷問題不是「我們公司現在在哪一階段」，而是：
哪一群人處於哪個階段？我要求他們採取的行動，是否已經超前？
第一階段：尚未看見（In the Dark）
可觀察的現象
人們對現況大致滿意，或者正忙著處理其他更急迫的問題。他們沒有看見改變的必要，也不理解這次轉型與自己有什麼關係。
推動者常犯的錯
直接公布解決方案、安排培訓或要求執行新流程。推動者以為自己已經說明得很清楚，成員接收到的卻只是「又有一個高層專案要增加我的工作」。
此時應採取的行動
先讓問題變得可見。可以分享市場變化、客戶回饋、交付數據與維持現況的代價，也要傾聽不同群體如何理解這些訊號。重點不是立刻說服大家接受某個方案，而是共同看見值得處理的問題。
進入下一階段的訊號
關鍵利害關係人能用自己的話說明：為什麼現況不能一直持續。此時，他們不必已經同意你的解決方案。
第二階段：看見挑戰（See the Challenge）
可觀察的現象
人們已經承認問題或機會存在，但對改變的方向、成本和個人影響仍有疑慮。他們可能認同「需要改」，卻不一定認同「要照你的方法改」。
推動者常犯的錯
把質疑當成抗拒，急著要求承諾，或者只開一場單向的動員會便假設大家已經形成共識。
此時應採取的行動
讓相關成員參與解讀問題、討論期待與顧慮，並共同描述希望達成的結果。推動者還需要判斷：哪些關鍵角色必須看見挑戰，才能形成足以啟動變革的臨界群體。
進入下一階段的訊號
關鍵群體不只承認問題，也願意投入時間、提供資源或參與探索解決方案。
第三階段：開始行動（Get Started）
可觀察的現象
組織開始出現改變的能量。行動小組、轉型委員會或試點團隊陸續成立，大家開始討論目標、方法和推進順序。
推動者常犯的錯
由少數專家關起門來設計一套完美方案，或者還沒建立必要知識與共同語言，就急著擴大導入。
此時應採取的行動
建立跨角色的推動聯盟，釐清預期成果、決策邊界、角色責任和需要補足的知識。先用試點驗證關鍵假設，讓計畫可以隨學習結果調整。
進入下一階段的訊號
相關成員理解為什麼改、準備改什麼，也清楚自己的角色；試點範圍、回饋機制和下一步決策方式都已經明確。
第四階段：全面推行（Rollout）
可觀察的現象
新的流程、系統、工作方式或職責開始進入日常工作。新舊做法同時存在，不同團隊的理解與執行能力也不一致。
推動者常犯的錯
把「方案已經上線」誤認為「變革已經成功」，或者過度依賴外部顧問，沒有把知識轉化成組織內部的能力。
此時應採取的行動
提供現場教練、實際練習與即時回饋，持續移除執行障礙。除了檢查活動是否發生，更要觀察新行為能否改善原本的業務問題，並允許不同領域根據回饋調整做法。
進入下一階段的訊號
團隊不再需要推動者逐項盯進度，也能穩定運用新的工作方式；與業務問題相關的成果指標開始出現改善。
第五階段：形成成果（Results）
可觀察的現象
新的工作節奏逐漸穩定，流程、角色和協作方式開始產生預期成果。但如果少了特定人物的督促，團隊仍可能回到舊做法。
推動者常犯的錯
看到初步成果便宣布專案結束，撤掉支持資源，卻沒有讓新的行為成為組織運作的一部分。
此時應採取的行動
將有效做法嵌入制度、系統、衡量方式和管理節奏，讓團隊真正承接所有權。同時檢查獎勵、績效和主管行為是否支持新的工作方式，而不是暗中把大家拉回原點。
進入下一階段的訊號
即使面臨時程壓力、人員異動或推動者退出，新的工作方式仍能持續；團隊還會主動使用並改善相關機制。
第六階段：進入下一輪（Time to Move On）
可觀察的現象
這次改變已經成為日常，原本的問題不再是主要焦點；新的限制、風險或機會開始浮現。
推動者常犯的錯
因為曾經成功，便持續保護原有方案，或者專案一結束就解散團隊，沒有留下可複用的學習。
此時應採取的行動
回顧預期與實際成果，整理有效做法、失敗嘗試和意外影響，將它們轉化成組織可使用的原則、資料與工具。當環境再次改變，就重新判斷新的利害關係人處於哪個階段。
完成這一輪的訊號
組織已經保存學習，也願意放下不再適用的做法，準備針對下一個問題重新開始診斷。
不要替整個組織貼上同一個階段標籤
假設高層已經要求全面推行，轉型小組也完成了試點，但部門主管才剛看見挑戰，第一線成員甚至仍未理解為什麼要改。此時如果只增加培訓，並不能解決問題。
利害關係人可能所處階段此刻真正需要的行動高階主管全面推行校準期待，持續提供授權並移除障礙部門主管看見挑戰討論影響、顧慮與希望達成的結果轉型小組開始行動驗證試點，明確定義決策與回饋機制第一線成員尚未看見讓業務問題及其與日常工作的關係變得可見
變革推動者的工作，不是把同一套溝通、培訓和流程發給所有人，而是幫助每一個關鍵群體走到下一個階段。
用 15 分鐘診斷你的變革
如果你正在推動一場轉型，可以先暫停討論方法，完成以下練習：
敏捷轉型遇到阻力時，我們很容易認為是別人不理解、不支持或不願意改變。但有時真正的問題，是我們只看見自己已經走到哪裡，卻沒有看見對方還站在哪裡。
不要急著推下一個流程、框架或活動。先回到業務問題，找到能共同推動改變的人，再判斷每一群人目前所處的階段。
當行動與人的狀態對齊，變革才真正有機會發生。
作者簡介
范育銘 (個人介紹：https://yumingfan.me/）曾多次參與組織敏捷轉型，關注數位化轉型、團隊與組織級敏捷實踐。他曾以敏捷教練角色服務不同規模的公司，並與朋友共同創辦 Weagile 社群。目前主要透過引導、培訓與工作坊，協助團隊建立共識、制定目標並推進變革。
