Oral Assessment System

OAS（Oral Assessment System）是一套面向多角色協作的大學口試行政系統。我把原本分散在 email、試算表與人工協調中的口試作業，整理成同一套可管理、可追蹤的工作流程，涵蓋排程、考官配置、學生預約、評分流程與結果發布。

大學口試行政真正麻煩的地方，不只是找時間，而是它處理的不是單純的一對多預約。市面上常見的排程或預約工具，大多比較接近一位主持者開放時段，再讓多人選擇或預約；但口試行政實際上更接近一對多對多的協調問題：課程管理者需要建立時間與場地，考官要在限制下選擇可承接時段，之後這些時段再成為學生可互動、可預約的選項。這代表系統同時要處理多個角色、多組時段、多位考官與多個場地之間的關係，而不是單一預約者對多位參與者的排程。

因此，實際上的口試行政往往還是回到試算表與人工協調。這種做法雖然彈性高，但也容易出現時段衝突、資料誤改、權限邊界不清，以及考前集中爆炸的行政風險。除此之外，協調者還要額外處理學生分組資料、評分規準對應，以及最後把結果整理回既有教學平台。OAS 要解的，不是單點 booking，而是把原本分散在不同工具與人工處理中的口試行政流程，整理成同一套可管理、可追蹤的多角色工作流。

我在 OAS 中同時承接兩條關鍵工作線。

第一條是產品整理線。我負責需求訪談、需求整理、功能優先順序、Backlog 管理、Sprint 節奏維持，以及客戶溝通與團隊對齊，並把 Epic、User Story、Acceptance Criteria 與 Kanban 結構整理成可執行的交付主線。

第二條是核心 user flow 交付線。我主導系統最核心的多角色排程流程 UI/UX，處理 admin、examiner 與 student 之間的主要互動，以及相關前端整合邏輯。這是 OAS 最核心、也最複雜的產品流程之一。

這個專案是在 12 人團隊與真實 client 合作情境下推進的，需求並不是固定不變。角色模型、CSV 功能層級、排程方式與 API 介面都曾在開發中調整，因此我在產品端的工作，不只是記錄需求，而是持續把 workshop 後的變動整理成團隊能估時、能追蹤、能實作的產品主線。這包含 Epic、User Story、Acceptance Criteria、Backlog、Kanban 與 Sprint 節奏，也包含把 client change 重新拆解成可執行的工作項目，讓團隊不是各自處理零散任務，而是沿著同一條交付方向往前推。在團隊動能不足、整合壓力升高的情況下，我也實際承接了更多推進責任，主動把需求整理、交付節奏與核心流程整合往前拉，讓主流程仍能持續往可交付狀態前進。

在工程端，我主導 OAS 最核心的多角色排程主流程。admin 建立與管理時段，examiner 在規則限制下選擇可承接時段，之後再由 admin 發布給 student 預約。這裡處理的不只是畫面，而是互動順序、可見性規則、驗證邏輯與角色邊界。我實際承接的範圍包含 timeslot management、examiner selection、publish / withdraw，以及 release 後的保護邏輯，例如容量驗證、slot locking 與已預約資料限制。到了後期，我也補上 batch creation、single creation、examiner assignment、publish 與 withdraw 相關的整合工作，讓這條 workflow 能真正接上後端、測試與最終展示。

• [Demo] 觀看 OAS 交接展示完整影片