跳到主要內容

AD 103 · 模組 2

排序

用同一維度比較多個 Use Case,討論 portfolio 中的取捨,完成 Prioritization Workshop。

開始第一節
已完成 0 / 3
同步我的進度加入梯次後,進度可跨裝置保存,講師也能看到

資訊

加入後,你已完成的模組編號會連同「學員代碼」傳送給講師,講師可以看到你的進度。請使用講師提供的代碼,不要輸入姓名、公司機密或其他個資。進度資料與該梯次的其他資料一起保存。

學習目標

  • 以同一維度、evidence quality 與 confidence 比較案例。
  • 記錄 disagreement、assumption、unknown 與 resource constraint。
  • 為每個 Use Case 形成 next step、owner、review date。

比較 Use Case

30 分鐘

比較 Use Case(Compare Use Cases)

學習目標:以同一維度、evidence quality 與 confidence 比較案例。

比較多個 Use Case 時,必須用同一組維度(Value、Feasibility、Readiness、Risk)逐一比較,而不是每個案子用不同的標準各說各話。同時要標明每個維度的證據品質與信心程度:這個判斷是有數據支持,還是純粹猜測?信心程度不同,比較結果的可靠度也不同。

比較時的兩層資訊
欄位說明
維度判斷Value/Feasibility/Readiness/Risk 各自的評估
證據信心這個判斷是 observed/data-backed 還是 estimated/guess?
工作情境

比較表:Use Case A:Value 高(有數據支持)、Feasibility 中(估計,未驗證)、Risk 低。Use Case B:Value 中(估計)、Feasibility 高(有數據支持)、Risk 中。因為 A 的 Value 判斷比 B 更有信心,即使兩者其他維度接近,A 可能更值得優先驗證。

  • 高信心(data-backed):有系統紀錄、正式統計或多次觀察支持的判斷。
  • 中信心(partially verified):有部分資料或少量樣本支持,但尚未大範圍驗證。
  • 低信心(estimated/guess):主要來自受訪者印象或單一個人的推測,沒有具體資料佐證。
  • 比較時若兩個案子的維度分數接近,應該優先信任信心程度較高的判斷,而不是直接取平均。
工作情境(對照案例:三案比較)

擴大到三個候選案比較:Use Case A(Value 高/高信心、Feasibility 中/低信心、Risk 低/高信心)、Use Case B(Value 中/高信心、Feasibility 高/高信心、Risk 中/中信心)、Use Case C(Value 高/低信心、Feasibility 高/低信心、Risk 低/低信心)。雖然 C 表面上「三項都不錯」,但全部都是低信心的估計,可能需要先花一次簡短訪談補足證據,而不是直接排進優先名單。

資訊

Human、AI、Human:人做最終的優先順序判斷與治理決定,AI 可協助整理比較資料,但不能替組織做最終決定。

注意

資料安全提醒:本課程所有練習一律使用課程提供的模擬情境檔案,不含任何真實機構或個人資料。
自我檢測

比較兩個 Use Case 時,下列哪一個做法最正確?

比較兩個 Use Case 時,下列哪一個做法最正確?

重點: 比較 Use Case 要用同一組維度,並且誠實標明每個判斷的證據信心。

組合討論

30 分鐘

組合討論(Portfolio Discussion)

學習目標:記錄 disagreement、assumption、unknown 與 resource constraint。

Portfolio Review 討論中,參與者常常對同一個 Use Case 有不同看法。好的討論紀錄不會強行消除分歧,而是誠實記錄:哪裡有 disagreement(意見分歧)、討論中浮現了什麼未經證實的 assumption(假設)、還有哪些 unknown(未知事項)沒有答案、以及目前的 resource constraint(資源限制)如何影響決定。

四類要誠實記錄的內容
欄位說明
Disagreement哪裡意見不一致?
Assumption討論中浮現了什麼未驗證的假設?
Unknown還有什麼問題沒有答案?
Resource constraint目前的資源限制是什麼?
工作情境

討論紀錄:關於 Use Case A 的 Readiness,主管認為「準備好了」,承辦人認為「主管低估了流程變更的阻力」(disagreement)。雙方都假設「員工會願意改用新系統」(assumption,未驗證)。目前不清楚 IT 部門能不能在本季支援串接(unknown)。這一季只有一組人力可投入(resource constraint)。

  1. 留意分歧的訊號
    當兩位參與者對同一個維度說出不同判斷時,當場記下雙方的原話,不要急著調和。
  2. 追問背後的假設
    問「你這樣判斷的前提是什麼?」常常能挖出一個雙方都沒說出口的 assumption。
  3. 標出未知事項
    遇到「這個我們還不確定」的回答,直接記成 unknown,而不是硬逼出一個答案。
  4. 記下資源限制
    問「這一季我們實際能投入多少人力/時間?」把限制寫進紀錄,影響後面的排序判斷。
  • 捕捉 disagreement 的句型:「我跟 OO 的看法不一樣,我認為……」
  • 捕捉 assumption 的句型:「我們都假設……但還沒驗證過。」
  • 捕捉 unknown 的句型:「這點我們還不知道,需要再確認。」
  • 捕捉 resource constraint 的句型:「這一季我們只能投入……的人力/時間。」

資訊

Human、AI、Human:人做最終的優先順序判斷與治理決定,AI 可協助整理比較資料,但不能替組織做最終決定。
自我檢測

Portfolio Review 討論中,主管與承辦人對某案子的 Readiness 判斷不同。下列哪一個記錄方式最正確?

Portfolio Review 討論中,主管與承辦人對某案子的 Readiness 判斷不同。下列哪一個記錄方式最正確?

重點: Portfolio 討論的紀錄要誠實呈現分歧、假設、未知與資源限制,而不是製造虛假的共識。

優先排序工作坊

30 分鐘

優先排序工作坊(Prioritization Workshop)

學習目標:為每個 Use Case 形成 next step、owner、review date。

這是整門課的收尾實作:把前六堂課建立的判斷(portfolio thinking、value、feasibility、readiness、risk、比較與討論)整合成正式的 AI Use Case Portfolio。每個 Use Case 最終要有明確的 next step(clarify/prototype/pilot-review/governance-review/defer/stop 六選一)、owner(誰負責推進)與 review date(下次檢視的時間)。

每個 Use Case 的三個收尾欄位
欄位說明
Next stepclarify / prototype / pilot-review / governance-review / defer / stop
Owner誰負責推進下一步?
Review date下次檢視是什麼時候?
工作情境

工作坊產出:Use Case A:next step = prototype;owner = 系統組組長;review date = 六週後。Use Case B:next step = governance-review(涉及財務風險);owner = 財務長;review date = 兩週後(先完成治理審查)。

  • Clarify:問題陳述或 owner 還不夠清楚,下一步先補訪談或釐清,不急著動手做。
  • Prototype:方向明確、風險可控,值得花小規模時間做一個可驗證的原型。
  • Pilot-review:原型驗證有效,準備在有限範圍內正式試行,試行後需安排檢視。
  • Governance-review:涉及個資、財務、法規或安全風險,必須先經治理審查才能繼續。
  • Defer:目前時機或資源不合適,但保留案子,訂下未來重新檢視的時間。
  • Stop:經評估後確認不值得投入,明確結案,避免占用團隊注意力。
工作情境(對照案例:套用六選一決策)

Use Case C(圖書館問答協助):Value 中、Feasibility 高、Readiness 低(圖書館尚未指定 owner)、Risk 低。對照六選一:由於 Readiness 不足,先選 clarify,下一步是請圖書館指定 owner 並確認維運人力,而不是直接跳到 prototype。owner = 教學發展中心;review date = 三週後確認圖書館是否已指定 owner。

資訊

Human、AI、Human:人做最終的優先順序判斷與治理決定,AI 可協助整理比較資料,但不能替組織做最終決定。
自我檢測

工作坊結束時,某 Use Case 只寫了「這個案子不錯,可以繼續」。下列哪一個回饋最恰當?

工作坊結束時,某 Use Case 只寫了「這個案子不錯,可以繼續」。下列哪一個回饋最恰當?

重點: 工作坊的完成標準:每個 Use Case 都有明確的 next step、owner 與 review date,而不是模糊的「繼續做」。

接下來做什麼?