傳統管理常用工時、出勤狀況與任務完成數量評估工作表現。管理者透過上下班打卡記錄、進度回報與每日工作清單，確認每個人的時間投入，並據此估算團隊是否具備完成計畫所需的人力。
AI 進入開發流程後，完成相同工作的時間可能出現很大差異。熟悉需求、系統與工具的工程師，可以在短時間內完成程式草稿、測試案例或文件整理。另一位工程師可能花較多時間理解架構限制、檢查資料風險與驗證生成內容，表面上的產出數量較少，這些工作能替團隊避開後續返工與事故。
工時只能說明人員投入多少時間，無法反映需求是否正確、程式能否維護，以及成果是否真的被使用。AI 也會讓程式碼行數（Lines of Code, LoC）、完成任務數與提交（Commit）次數快速增加，使這些數字更難對應產品價值。
管理者繼續依賴工時判斷績效，團隊的注意力就會集中在容易計算的活動，例如增加提交次數、快速關閉任務或產生更多文件。
需求驗證、架構思考、風險檢查與知識分享難以呈現在工時報表中，卻會直接影響交付品質與系統穩定性。
傳統任務管理會先拆分工作、指派負責人，再依照原定計畫追蹤完成比例。當工作內容相對穩定時，管理者可以透過任務清單掌握進度，並根據落後項目安排加班、增派人力或調整期限。
探索與實作被 AI 加速後，團隊會提早取得新的資訊。開發者生成第一版功能後，可能立即發現需求缺少例外規則。產生測試案例後，可能看見資料結構無法支援原先假設。使用者看到原型後，也可能重新理解問題。任務內容與處理方式會跟著這些回饋調整。
任務切分過細，原定計畫很快就會失去參考價值。管理者若要求團隊按照既定項目逐一完成，成員就需要花費大量時間更新狀態、解釋差異與重新估算。團隊也可能優先完成已經失去價值的任務，讓進度報表維持正常，關鍵風險卻沒有進入正式管理流程。
任務仍需要保持透明。管理者可以關注工作目前停在哪個環節、正在等待哪些資訊，以及下一步需要驗證哪些假設。團隊取得新證據後，也應重新拆分與排序工作，並為重要調整留下原因、影響範圍與後續驗證方式。
團隊應將任務視為達成目標的階段性安排，當需求與限制改變時，團隊可以調整執行路徑，同時維持清楚的目標、工作邊界與驗證條件，讓任務安排能回應最新資訊。
AI 能縮短程式撰寫、資料整理與文件生成所需的時間，團隊的提交數量、完成點數與功能產出也可能快速增加。這些數字容易讓管理者認為開發效能已經改善，進而增加承諾量或縮短交付期限。
產出速度提高後，審查、測試、需求確認與部署仍需要足夠時間。大量變更同時進入流程，會在程式碼審查（Code Review）、測試環境與上線批准前形成排隊。團隊完成的工作變多，使用者收到成果的時間卻未必同步縮短。
速度指標也會受到工作拆分方式影響。同一項功能可以拆成三個任務，也可以拆成十個任務。AI 協助生成大量程式碼後，提交次數與程式碼行數也會增加。單獨比較這些數字，很難判斷團隊的交付能力是否真的改善。
判讀開發速率（Velocity）時，可以搭配週期時間（Cycle Time）、等待時間、返工比例、部署失敗率與使用者回饋一起觀察。完成任務數提高時，若審查等待時間也被拉長，代表工作只是更快進入排隊區。部署頻率提高時，若失敗與修復次數也增加，團隊就需要檢查測試、安全檢查與發布流程是否能承接變更量。
團隊也可以引入 DORA 指標（DORA Metrics）觀察軟體交付能力，包括變更從提交到正式環境所需的時間、部署頻率、變更失敗情況與服務恢復能力。這些指標可以協助團隊判斷交付流程中的等待、品質與復原能力，避免只用開發速率或完成工作數量解讀 AI 帶來的速度提升。
AI 時代的速度需要放回整條價值流（Value Stream）解讀。從需求提出、理解、實作、驗證到正式使用，各階段的停留時間與回饋品質，才能說明團隊是否建立了有效的交付環境。
個人完成工作的速度被 AI 拉高後，管理者需要觀察團隊最後交付了哪些成果。程式碼、文件、測試案例與分析報告都屬於工作產物，還需要經過整合、驗證與使用者回饋，才能轉化為可使用的產品成果。
管理若集中在每個人完成多少任務，團隊容易將工作拆成方便計數的單位。工程師可以快速關閉大量任務，整體功能卻可能仍停在需求確認、跨系統整合或測試環境。個人數字表現良好，交付日期依然不斷延後。
整體交付結果可以從產品目標、使用者行為與系統品質觀察。這次變更解決了哪些問題、使用者是否採用、故障與返工是否維持在可承受範圍，以及團隊能否安全地繼續修改系統，這些資訊都比單一個人的任務數更接近產品成果。
績效討論也需要納入協作貢獻。團隊可以鼓勵成員跨角色協助解除瓶頸，並透過團隊導向的 OKRs 與流程指標觀察整體交付狀況，避免只用個人產出衡量工作表現。
協助釐清需求、補上測試保護、改善部署流程、分享領域知識與減少跨團隊等待，都會影響整條價值流。這些工作未必直接增加完成任務數，卻能縮短等待與返工時間，讓團隊更穩定地完成交付。
這些成果被納入評估後，團隊才能把時間投入共同交付，減少為了提高個人數字而產生的局部最佳化。
傳統進度管理常用工作完成百分比掌握狀況。軟體工作包含大量探索活動，完成比例只能反映團隊當下的理解。需求、技術限制或使用者回饋改變後，原先的百分比很快就會失去參考價值。
回饋需要多久才能出現，會直接影響管理判斷。例如，需求提出後多久能看到原型、程式修改後多久能得到測試結果、提交變更後多久能收到審查意見，以及上線後多久能看見使用者行為與系統影響。
回饋時間拉長，錯誤方向就會帶著更多工作繼續推進。AI 能快速產出完整功能，也可能讓團隊在缺少回饋的情況下投入大量實作。縮短驗證週期，可以讓需求假設、技術方案與品質問題提早進入檢查。
這項調整也會改變管理者的日常關注點。會議中需要討論哪些工作仍缺少回饋、哪些決策等待過久，以及哪些驗證活動仍依賴人工處理。等待與驗證阻礙被移除後，團隊就能提早看見問題並修正方向。
增加人力常被視為加速交付的直接手段。AI 工具普及後，個人產能可以快速提高，領域知識、架構背景與決策脈絡仍需要在團隊中傳遞。成員若缺少這些資訊，即使能快速產出內容，也容易增加確認、審查與修改工作。
知識集中在哪些人身上、哪些模組只能由固定成員處理、哪些決策經常等待特定角色，這些問題會形成隱性排隊。請假、轉調與離職發生時，交付穩定性也會受到影響。
知識流動可以透過共同設計、結對協作（Pairing）、程式碼審查（Code Review）、架構決策紀錄（Architecture Decision Records, ADR）與活文件（Living Documentation）支援。
與 AI 對話中形成的需求理解、提示詞、方案比較與限制條件，也需要整理到團隊可以存取的位置，避免重要背景只留在個人帳號或聊天紀錄中。
配置工作時，可以安排適度的共同參與，讓關鍵知識至少有兩位以上的成員理解。這類安排會占用部分短期產能，卻能在後續修改、事故處理與人員交接時，提供更多可接手的人選與處理方式。
單一環節速度提高後，工作會更快流向下一個環節。開發完成速度提升，程式碼審查可能開始排隊。審查完成後，測試環境與部署批准也可能成為新的等待點。
局部流程獲得改善，若缺少整體觀察，瓶頸只會轉移到其他位置。
沿著價值流查看工作從需求提出到正式使用所經過的步驟，可以看見停滯發生在哪裡。每個步驟都要觀察處理時間、等待時間、在製品（Work in Progress, WIP）數量與返工情形。工作長時間停留的位置，多半表示此處的權限、能力、環境或資訊存在阻礙。
價值流的順暢程度也會受到工作批次影響。大量功能同時進入審查，會增加審查者的認知負荷。多項變更集中發布，則會提高測試與復原難度。
小批次交付、限制在製品，以及優先完成接近價值終點的工作，都能讓等待點更早被看見。
這項調整需要跨越部門界線。需求確認、開發、測試、資安與維運若各自追求部門利用率，工作就容易停在交接處。管理者需要以共同交付結果協調各角色，讓資源優先投入當前瓶頸，維持整條價值流的運作速度。
價值流中的阻礙，常會先出現在工作停留時間過長的位置。需求提出後，可能等待產品負責人確認。進入產品待辦清單（Product Backlog）後，可能等待拆解與排序。開發完成後，也可能停在審查、測試或部署。這些等待若分散在不同工具與會議中，管理者很難看見它們對整體交付造成的影響。
追蹤每項工作從提出到上線所需的時間，再區分實際處理時間與等待時間，能讓問題更具體。某項需求若歷時二十天，其中只有三天用於分析與開發，其餘時間都耗在確認與排隊，改善方向就要放在縮短等待、加快決策與減少反覆確認。
看板（Kanban）欄位也需要反映真實工作狀態。只使用「待處理、進行中、已完成」三種狀態，容易把等待、阻塞與退回修改都藏在「進行中」。
團隊可以補上「等待需求確認」、「等待審查」、「等待測試環境」與「等待發布」等狀態，讓工作停留的位置較容易辨識。
工作項目的停留時間分布也值得定期查看。少數項目長期卡住，多半表示某類需求依賴特定權限、知識或決策。相同的停留模式反覆出現時，管理者便能將其視為流程問題，安排明確的改善行動。
軟體交付經常需要產品、開發、測試、資安、維運與外部團隊共同參與。工作每次跨越團隊邊界，都會產生資訊整理、責任確認與排程等待。交接次數增加後，需求背景遺失與重新確認的機率也會提高。
從工作歷程中找出負責單位改變的位置，再觀察每次交接前後花費多少時間，可以看出固定排隊點。
例如，開發團隊完成介面後，需要等待另一個團隊提供測試資料。資安檢查只能在固定時段進行。部署還需要另外提出申請。這些安排都會形成固定的排隊點。
交接問題也會出現在責任描述不清的位置。上游團隊認為資料已經提供完整，下游團隊卻發現缺少欄位定義與例外規則，工作就需要退回補充。這類往返不一定會被標記為阻塞，卻會反覆消耗協調時間。
管理者需要協助團隊建立清楚的輸入條件、服務約定與共同工作方式。高頻交接長期影響交付時，可以調整團隊邊界、建立固定的跨團隊協作節奏，或由平台提供共用能力，減少每次都重新申請與確認。
程式產出變快後，程式碼審查、測試與部署容易形成新的排隊區。開發者可以在短時間內提交多個變更，審查者能投入的時間與注意力仍然有限。測試環境、驗證資料與發布窗口，也可能無法承接相同速度的變更量。
各階段的在製品數量與等待時間，能顯示產出是否超過後段承接能力。大量變更停在等待審查，代表團隊產生變更的速度已經超過審查能力。此時繼續增加開發任務，只會讓變更批次擴大，也會延長取得回饋的時間。
測試階段需要查看失敗後重新排隊的次數。測試環境不穩定、測試資料難以建立，或自動化測試執行過慢，都會讓工作反覆進出測試流程。部署若集中在少數人與固定時段，也會使已完成的成果長時間停滯在正式環境之前。
管理者可以支持小批次提交、限制各階段的在製品，並將低價值檢查交由自動化處理。團隊也需要一起改善測試環境、部署管線與審查規範，讓後段能力足以承接前段增加的產出。
價值流映射（Value Stream Mapping）可以呈現需求從提出到產生價值的完整過程。團隊需要標示各步驟的處理時間、等待時間、負責角色、輸入條件與產出結果，並記錄工作在哪些位置被退回或重新處理。
重工常出現在需求理解不足、驗收條件不清，以及技術限制太晚被發現的環節。功能完成後才確認使用情境不符，程式、測試與文件都需要一併修改。映射過程若能標出退回次數與返工原因，管理者就能看見哪些前期回饋需要提早取得。
決策延遲也可以透過映射被辨識。部分工作沒有技術阻礙，卻長時間等待資安、架構或跨部門批准。這些等待可能源自決策權距離工作現場太遠、資訊準備不完整，或責任角色不清楚。
完成映射後，管理者需要優先處理影響最大的阻礙。改善行動可以包含縮短批准流程、提前安排驗證、補上自動化能力，或調整角色權限。
每次改善後需再重新觀察停留時間與返工情形，團隊才能確認價值流是否更加順暢。
AI 可以在短時間內將需求轉成介面、流程、程式碼與測試草稿。需求中的模糊處也會同時被具體化，原本沒有說清楚的條件，常由 AI 依照既有範例補上，形成所謂的 AI 幻覺（Hallucination）。這些補充若沒有被察覺，團隊容易將生成結果視為原始需求。
產品負責人（Product Owner, PO）需要在實作範圍擴大前，先確認需求背後的假設。這些假設包含使用者目前遇到的困難、實際使用情境、預期成果、資料來源、例外規則，以及現有流程改變後會影響哪些角色。
驗證可以先從低成本成果開始。產品負責人可以讓團隊或是透過 AI 產生流程草圖、原型（Prototype）、範例資料或操作情境，再邀請使用者確認。這些成果能將抽象需求轉成可討論的內容，也能提早發現不同角色之間的理解差異。
草稿生成的間隔縮短後，產品負責人也需要提高判斷頻率。需求不宜長時間停在文件中等待完整實作。團隊可以用短週期產生可驗證成果，讓產品負責人根據回饋調整需求範圍與優先順序。
驗收條件（Acceptance Criteria，AC）若在功能完成後才補寫，內容多半只能依照既有實作整理。此時團隊已經投入程式、測試與整合成本，產品負責人即使發現需求理解有落差，也需要面對較大的修改範圍。
產品負責人應該在開發前，利用行為驅動開發（Behavior-Driven Development, BDD）規格，讓具體情境說明功能完成後應呈現哪些行為。內容需要涵蓋正常流程、錯誤情境、角色權限、資料邊界與重要例外。這些條件可以成為團隊與 AI 共用的生成限制。
例如，折扣功能需要說明哪些會員資格符合條件、折扣何時生效、能否與其他優惠並用、退款時如何處理，以及資格資料暫時無法取得時，系統應該如何回應。只寫「會員可使用折扣」，會讓 AI 與開發者自行補齊太多規則。
清楚的驗收條件也能支援測試設計。團隊可以先將條件轉成行為範例和 Gherkin（Given-When-Then）規格，再讓 AI 協助產生測試草稿。
生成結果完成後，仍要回到原始條件確認行為是否一致。需求、實作與驗證使用同一組規則後，理解落差就能在開發早期被發現。
功能草稿能更快出現後，開發團隊能在短時間內提出多個備選方案。使用者回饋若仍以月度訪談、版本上線後問卷或臨時轉述為主，產品判斷速度就會落後實作速度。
產品負責人需要建立固定的回饋入口，讓使用者能在小範圍成果完成時提供意見。原型、A/B 測試、內部試用與分批發布，都能協助團隊提早取得操作資料與真實反應。回饋內容也需要保留使用情境，避免只留下「不好用」或「需要修改」等簡短結論。
取得回饋後，產品負責人需要將內容整理成可判斷的產品資訊。例如，使用者在哪個步驟停下來、原先假設是否成立、哪些功能沒有被使用，以及問題來自介面、流程、規則或資料。這些資訊再回到產品待辦清單，影響後續排序與驗收條件。
產品負責人在這個過程中負責校準，讓使用者問題、產品目標、驗收條件與 AI 產出維持一致。團隊生成速度提高後，校準週期也需要縮短，避免大量成果建立在尚未確認的需求假設上。
| 管理面向 | 傳統管理模式 | AI 時代管理模式 |
|---|---|---|
| 核心關注點 | 工時投入、出勤、任務完成數量 | 價值流動速度、回饋週期、系統穩定度 |
| 瓶頸位置 | 程式碼撰寫與手動測試 | 程式碼審核、需求驗證、部署排隊 |
| 產品負責人角色 | 撰寫詳細文件、追蹤完工比例 | 早期驗證需求假設、定義明確驗收標準 |
| 績效考核 | 個人任務關閉數、程式碼行數、提交次數 | 團隊整體交付成果、知識分享、系統維護性 |
傳統管理模式 vs AI 時代管理模式
iThome鐵人賽
看影片追技術