原則六:開放與協作
程式碼、設計決策與研究成果公開共享,促進跨機關複用與社群參與。
背景
台灣政府每年花大量預算建置數位服務。但這些服務大多由不同 SI 廠商各自開發,程式碼封閉、設計不共享、文件不公開。結果是:
- 同樣的日期選擇器,被不同廠商做了幾十次
- 廠商交接時幾乎等於重來,因為前一手的東西看不到也碰不到
- 好的做法被鎖在某個專案裡,其他團隊無從參考
原則
公開讓事情變好。 當程式碼公開,更多人能發現問題。當設計決策透明,其他團隊能借鏡學習。當失敗的經驗被記錄,後來的人能避免同樣的錯。
這不只是一種授權方式的選擇——它是一種工作文化。
實踐方式
程式碼預設公開
設計系統的元件、token、建置工具——這些都在 GitHub 上,任何人都能看、能用、能提 Issue、能發 Pull Request。
不是因為「開源很潮」,而是因為:
- 其他機關可以直接用,不用重新採購
- 社群能幫忙發現 bug 和改善機會
- 公開的程式碼會讓寫程式的人更注意品質
決策脈絡的文件化
改了一個元件的 API——為什麼?選了這個技術方案而非另一個——考量是什麼?這些決策脈絡比程式碼本身更值得記錄。
因為程式碼會說「現在是什麼樣子」,但不會說「為什麼變成這樣」。三個月後的你(或接手的人)需要的是後者。
研究成果共享
- 使用者研究發現了什麼(去識別化後)
- 哪個設計方案在測試中被否決了、為什麼
- 什麼東西比預期的難做、踩了什麼坑
這些經驗對其他團隊的價值,往往超過最終的成品。
複用優先的資源策略
當你做了一個好用的東西,先想想:其他服務也可能用得到嗎?如果是,就抽出來,讓它變成共享資源——而不是埋在某個專案的 /utils 資料夾裡。
檢核標準
- 原始碼在 GitHub 上公開
- 重大設計決策有書面紀錄(RFC、ADR 或至少 Issue 討論串)
- 研究發現和學習經驗有被整理分享
- 其他團隊能直接安裝和使用設計系統的套件