原則五：資料驅動的持續改善

以量化指標與使用者回饋為依據，透過迭代循環持續優化服務品質。

背景

台灣政府 IT 專案常見的生命週期：招標 → 開發 → 驗收 → 上線 → 維護期結束 → 擺著不動直到下次改版。中間可能隔三五年。

這三五年間，使用者的需求在變、瀏覽器在更新、無障礙標準在提升、資安威脅在演化——但服務凍結在驗收那天的狀態。

原則

好的服務不是一次做完的，是長出來的。先做出一個能用的版本，交到真實使用者手上，看他們怎麼用，然後改善。再看，再改。

這不是說品質可以打折——而是承認我們不可能第一次就做對所有事，所以需要一個能持續修正的機制。

實踐方式

小幅、頻繁的發布

每次發布只包含少量變更——容易追蹤影響、出問題時容易回滾
不要等所有功能都完成才上線
持續部署（CI/CD）讓發布成為日常操作，不是需要加班的大事

量化與質化並重

追蹤核心指標：任務完成率、錯誤率、使用者求助率
但數字只告訴你「發生了什麼」——要知道「為什麼」，需要觀察真實使用者
兩者搭配才能做出對的判斷

上線後持續監控

服務上線第一週，密切觀察使用者行為是否符合預期
建立回饋管道——讓使用者能輕鬆回報問題
定期檢視數據（至少每月一次），不是裝了分析工具就結束

基於證據的功能調整

如果某個功能沒人用，拿掉它。介面上少一個選項，就少一分干擾
如果某個流程被證明不好用，改掉它，即使當初花了很多時間做
記錄每次改變的原因——給未來的自己和團隊一個交代

檢核標準

有定義核心指標且持續追蹤
有建立使用者回饋管道
發布頻率是週或月等級，不是年等級
每次迭代有紀錄：改了什麼、為什麼改、效果如何