我最近在做一個傳統服務機構的數位化專案，機構的核心工作是照顧人，員工大多四十到六十歲
系統做到第三版的時候，我突然意識到一件事：
我的開發速度，跟他們的吸收速度，差了至少十倍
兩種敏捷
在軟體開發的世界裡，「敏捷」是一個被說到爛的詞，快速迭代、持續交付、兩週一個 sprint，AI 出現之後更誇張 — 需求丟進去，十五分鐘就能產出一個堪用的版本，改 code、部署、回滾，都是分鐘級的事
這是數位敏捷，抽象的、快速的、風險可控的，東西壞了？rollback，方向錯了？pivot，成本是時間，而時間在數位世界裡很便宜
但當我走進這間機構，我碰到的是另一種現實
員工們每天的工作是照顧人 — 真實的人，有情緒的人，有身體狀況的人，他們的專業是建立在經驗跟關係上的，一個資深照服員知道怎麼哄一個不想吃飯的長輩，那是十年累積出來的能力，不是任何系統可以取代的
但你叫這群人用一套新系統來記錄每天的工作？
他們最怕的一件事是：「我會不會按錯？按錯了會不會壞掉？」
這是現場敏捷，經驗累積的、關係先行的、信任驅動的，改變不能用版號來算，要用月來算
火箭跟腳踏車
我犯過一個錯
系統第一版做好的時候，我一口氣把所有功能都放上去了，拍照上傳、語音記錄、AI 自動生成報告、PDCA 管理循環、數據儀表板，從工程的角度看，每個功能都有價值，架構也很乾淨
結果呢？
試用的員工打開系統，看到那個介面，直接關掉了
不是系統不好，是我給了他們一台火箭，但他們需要的是一雙溜冰鞋
軟體開發有一個經典比喻：先做溜冰鞋，不要一開始就造汽車。這個比喻在敏捷開發圈講了十幾年，原本是在說「先交付最小可用版本」
但在 AI 時代，我發現它貼切的地方不一樣了 — 不是在說開發節奏，是在說人對改變的信任節奏
溜冰鞋 → 滑板車 → 腳踏車 → 機車 → 汽車
你不能一次給他們汽車。不是因為汽車不好，是因為他們還沒相信自己會開
先給他們一個最簡單的東西 — 就只是拍照上傳，取代手寫，等他們用習慣了，再加下一個功能，每一步都要小到他們不會害怕，但大到他們感受得到價值
聽起來很慢？
的確很慢，但這是唯一會成功的速度
吸收能力是真正的瓶頸
後來我去查了一些研究，發現這個現象有個學術名詞叫「吸收能力」（absorptive capacity），意思是一個組織消化新技術、新知識的能力
有一句話讓我印象很深：最創新的組織不是動得最快的，而是消化得最好的
很多組織掉進一個陷阱：拼命引進新工具、新系統、新流程，但團隊根本來不及消化，結果就是「知識消化不良」— 工具買了一堆，沒有人在用
AI 時代這個問題更嚴重，因為開發端的速度確實快了十倍，但落地端的吸收速度沒有變，這個落差只會越來越大
你可以一週改三版系統，但現場的人可能一個月才消化得了一個新功能
這不是他們的問題，是你的節奏沒有對準他們的吸收能力
我學到的三件事
1. 開發速度跟導入速度要分開管
系統可以快速迭代，但導入要慢慢來，我現在的做法是：開發端維持兩週一個 sprint，但導入端一個月只推一個新功能，兩條線平行跑，不互相綁架
開發完的功能先放著，等現場消化完上一個功能之後再推下一個，這需要耐心，但效果好很多
2. 現場的人才是真正的產品經理
我在辦公室想出來的功能優先序，跟現場的人實際需要的，幾乎每次都不一樣
現在我的習慣是：每個月去現場待半天，看他們怎麼用系統，不是問他們「好不好用」— 因為他們會客氣地說「還好」，是看他們怎麼操作，看他們在哪裡卡住，看他們用了什麼「笨方法」來繞過系統的設計
那些「笨方法」裡面藏著最真實的需求
3. 信任比功能重要
在傳統機構裡，導入新系統最大的門檻不是技術，是信任
員工要相信：這個系統不會增加我的工作量，這個系統不會讓我看起來很笨，這個系統壞了有人會幫我處理
建立信任的方法很土：讓他們看到同事用了之後覺得好用 所以我永遠從最願意嘗試的那兩三個人開始，讓他們變成種子使用者，等他們在茶水間跟同事說「欸那個還不錯用耶」，比我做任何培訓都有效
真正的敏捷
回到「敏捷」這個詞
軟體業定義的敏捷是：快速迭代、持續交付、擁抱改變，這在純數位的世界裡完全正確
但當數位工具要進入傳統場域 — 長照機構、醫院、學校、工廠 — 的時候，敏捷的定義需要擴展
真正的敏捷不只是開發多快，而是落地多穩
不只是你能多快推出新功能，而是使用者能多快把新功能變成日常習慣
不只是系統能多快迭代，而是組織能多快消化改變
AI 讓開發端的速度快了十倍，但如果落地端跟不上，那十倍的速度只會產生十倍的浪費
所以，如果你也在做類似的事
如果你正在把數位工具導入一個傳統場域，不管是什麼產業，有三個問題值得先想清楚：
-
你的使用者，消化改變的速度是多少？ 不是你覺得應該多快，是他們實際上能多快
-
你的導入節奏，有沒有跟他們的吸收能力對齊？ 如果你一個月推三個新功能，但他們一個月只能消化一個，那多出來的兩個就是浪費
-
你有沒有在現場待過？ 不是開會，不是看報告，是實際去看他們怎麼工作、怎麼用你的系統
最後一句話：
給他們腳踏車，不是火箭，等他們騎穩了，再換機車
我是 Young，專門幫傳統機構做數位轉型，從現場觀察、系統建置到 AI 導入，看問題在哪一層就從哪一層開始做，如果你也在做類似的事，歡迎交流