【行動影響力論壇@台灣敏捷大賞 系列活動 】AI 時代的敏捷專案管理：從需求探索到協作開發-派森科技 創辦人 劉兆恭 JUGG
【行動影響力論壇@台灣敏捷大賞 系列活動 】AI 時代的敏捷專案管理：從需求探索到協作開發-派森科技 創辦人 劉兆恭 JUGG
作者：ACT
刊登時間：September 16, 2026
AI 時代的敏捷專案管理：程式寫快了，團隊為什麼還是忙不過來？
規格才剛交給 AI，功能就做出來了。但你還在確認需求、看文件、回覆同事，另一個專案又跳出通知，等你做決定。
開發變快了，你卻還是忙了一整天。
台灣敏捷協會這場《AI 時代的敏捷專案管理：從需求探索到協作開發》直播，由 Simon、Hermes 與派森科技創辦人 JUGG（劉兆恭） 對談，聊的是 AI 進入工作現場之後，需求怎麼釐清、文件怎麼同步，以及團隊還有哪些事情需要人來處理。
JUGG 現在花最多心力的，是開工前確認規格，以及完成後親自驗收。中間的開發與測試，AI 已經做得很快。
如果你是產品經理、專案經理、系統分析師、工程師，或正在帶領團隊使用 AI，可以花約一小時聽聽這場對談，對照自己每天的工作，看看時間究竟花在哪裡。
需求探索，先把「為什麼要做」談清楚
開發變快之後，有想法就做出一個功能，愈來愈容易。但團隊依然得回答：這個功能要解決誰的什麼問題？值得現在投入嗎？
JUGG 談到，過去要把一個想法寫成規格，往往需要產品經理、設計與工程夥伴來回討論。現在，他會先和 AI 腦力激盪，整理想法與可能的方案，再拿比較成形的版本找人討論。
探索需求時，他會搭配痛點分析、機會解決方案樹（OST）等方法，反覆追問做這件事的理由。AI 可以幫忙整理想法、提出問題、列出可能的做法，產品要往哪裡走，仍然需要人判斷。
和 AI 討論產品時，也得先確認一件事：它看得到產品目前的狀態嗎？
JUGG 提出，產品經理也可以讓 AI 讀取專案程式碼儲存庫（repository，簡稱 repo）裡的程式與文件，了解系統有哪些限制、哪些功能已經完成、哪些事情還沒處理。過去得先請工程師查的問題，現在也可以先請 AI 幫忙找。
知道產品已經做到哪裡，再來談規格，大家比較不會各說各話。
文件要跟得上實作，團隊才有共同的依據
很多團隊都遇過這個狀況：需求文件寫好了，工程師開始做，途中發現限制，於是調整了做法。修改原因可能留在任務留言裡，原本的文件卻沒有更新。
下一個接手的人，只能重新問一輪。AI 如果讀到舊文件，也可能不知道後來改了什麼。
JUGG 會把產品要做什麼、規格怎麼訂，以及後來改了什麼，都記錄在 repo 裡，討論和實作時也請 AI 更新文件，讓文件盡量符合程式實際的運作方式。
Simon 則分享了另一種安排。他處理的業務涉及倉庫、電商出貨與外部廠商，文件數量很多，因此將文件與程式碼分成兩個 repo，再放進同一個工作區，讓 AI 同時讀取。
不論放在一個還是兩個 repo，團隊都得知道：需求或實作改了以後，要去哪裡查最新的資訊？
至於 Jira 這類任務管理工具，JUGG 仍然保留。他會和 AI 討論當天做了什麼，再讓 AI 更新任務狀態，自己則在每週、每月回顧。當一個人同時參與多個專案，或主管需要掌握整體進度時，還是需要有個地方，能一次看見各個專案的進度。
把更新工作交給 AI，前提是團隊先談好：哪些資訊放在哪裡，改了以後要同步到哪裡。
同一份規格，有人嫌字太多，有人嫌不夠詳細
Simon 分享了自己寫規格時遇到的難題。
他先把規格與驗收標準寫好，原本覺得交代得很完整。非工程背景的同事看了，覺得字太多、看不下去；等到工程師要實作，卻又覺得內容還不夠詳細。
產品經理與系統分析師常常得同時應付這兩種要求。
JUGG 建議用 AI 快速做出可以操作的原型（prototype），讓客戶、營運單位或老闆看著畫面、試著操作，再一起討論。
有些人很難把需求講清楚，但看到畫面、試著操作之後，就比較容易指出少了什麼、哪裡不符合工作習慣。有了原型，大家就能對著同一個畫面討論。
不過，Simon 也提到，實務上可能做了一版又一版，還是沒有符合需求。原型能讓需求比較容易說明白，接下來還是得一起討論，確認彼此想的是同一件事。
進入開發時，則需要把談好的結果整理成驗收條件（Acceptance Criteria，簡稱 AC），交代什麼情境下，系統應該出現什麼結果。
要請人做決定時，可以用原型搭配幾個重點，說清楚這次需要對方決定什麼；交給開發與驗收的人時，則要把規則寫清楚。同一個需求，要看是寫給誰，再決定怎麼說。
開工前看規格，做完後親自驗收
JUGG 有兩個步驟會自己把關。
第一個在開發前。即使規格由 AI 協助產生，他仍然會逐條看過驗收條件，確認系統會不會照自己的預期運作。
第二個在開發後。AI 回報功能完成、測試通過，他還是會手動抽驗，把自己認為需要確認的操作流程跑過一次。
他不必一直盯著 AI 寫程式，但需求對不對、成果能不能用，還是要自己看過。
用了 AI，專業知識仍然派得上用場。當 AI 提出問題、要求你選擇方案時，你還是得理解業務、系統邏輯與前後脈絡，才知道該怎麼決定。
如果你帶的團隊已經能很快做出功能，可以再看看：大家有沒有足夠的時間確認需求，也有能力檢查做出來的東西？這兩個地方，都可能影響整體交付速度。
每個人都有 AI，團隊還是要協調誰做什麼
直播中，Hermes 提出一個問題：既然 AI 能執行工作，能不能連任務分派與同步都交給它，人與人就不用溝通了？
如果不同人的 AI 接到同一個任務，大家各自做完，才發現重複開發，該怎麼辦？
JUGG 提醒，這和過去兩位同事認領同一張任務的問題很接近。規劃工作時先談好分工，平常也讓彼此知道手上正在做什麼，仍然能幫上忙。系統也可以透過任務狀態，幫助避免重複認領。
但人還得討論要選哪個方案、是否符合業務需求，以及誰來負責。這些事情也要談到彼此理解。
幾位與談者後來也聊到，主管問起某個功能或資料欄位時，有人會先查 AI，再回覆主管。這牽涉到團隊的工作習慣：哪些問題可以自行查詢，哪些需要找負責人確認？如果引用了 AI 的答案，誰來確認它適用於眼前的情境？
用了 AI 的建議，確認內容、做決定和對外說明的人，仍然要為結果負責。
AI 同時做很多事，人的注意力卻跟不上
Simon 還談到另一個工作上的困擾：用 AI 之後，要讀、要想的東西變多了，認知負荷也跟著增加。
AI 能產生更多文件、更快完成工作，人卻要頻繁閱讀規格、確認變更、回覆問題。產出增加了，等著人理解和判斷的東西也一起增加。
JUGG 也遇到類似的困擾。當一個專案交給 AI 執行，他就會切到另一個專案；但切來切去，自己也會吃不消。他分享，以目前個人的狀態，大約同時處理兩件事就接近上限，再多便很難兼顧。
同時處理兩件事，是 JUGG 自己的經驗；每個團隊也得留意，AI 同時做得了多少事，和人能看懂、判斷多少事，未必一樣。
如果 AI 一接手，自己就再開一件新工作，最後可能每一件都做完了，卻全在等人確認。主管除了看開發完成多少，也可以看看有多少需求等著釐清、多少決定還沒做，以及多少成果等著驗收。
把省下的時間，拿來更早驗證
直播最後，JUGG 把話題帶回敏捷：AI 省下執行時間之後，團隊就能早一點驗證想法，從結果中學習，判斷值不值得繼續做。
如果需求方向有誤，開發再快，也只是讓錯誤更快變成產品。
回放裡可以聽到幾位與談者對照自己的做法：一個人從需求做到交付，和大型企業裡跨部門、跨系統合作，遇到的限制並不一樣。他們談了工具，也談了文件怎麼管理、原型怎麼拿來溝通，以及 AI 做完之後，自己怎麼驗收。
看回放時，不妨想想自己最近的一個專案：現在卡住的，是需求還沒談清楚、資訊沒有同步，還是太多工作同時等著你做決定？
觀看完整直播回放，對照你的團隊卡在哪一步
回放重點導覽
以下時間依本次字幕整理，方便找到想聽的段落：
