從設計標到工程標：公部門專案如何延續系統知識

磨人配合教育部專案，從設計標承接到工程標，戶外教育資源平臺的設計階段與工程階段由同一個團隊負責。程式與文件會隨著標案留下來，對系統的理解則要靠經手的人持有。標案換階段時，這份理解最容易中斷。

對系統的理解由經手的人持有

這個觀點來自 Naur，1985。論文主張寫程式的本質是程式設計者形成對該問題的理論，也就是深入的理解。文件無法完整記下這份理解，擁有理論的團隊解散時，程式文字仍可執行，卻無法再明智地回應修改需求。新人光讀程式碼與文件，無法取得這份理論，需要與已擁有理論的人密切合作。

人員流動對專案的衝擊，可以用數字衡量。Avelino 等，2016 提出自動估算 TF 的方法，TF 指有多少位開發者離開後，專案就無法繼續，用來衡量知識集中的程度。研究者對 133 個 GitHub 熱門專案執行估算，65% 的專案 TF 不超過 2。樣本是開源的熱門專案。

設計階段留給工程階段的判斷依據

法規把這件事放在機關委外的考量裡。資通安全管理法施行細則第七條規定，機關委外建置、維運資通系統時，選任與監督受託者應考量人員配置、複委託、客製系統的安全測試、事件通報與契約終止時的資料處理等事項。數位發展部資通安全署的官方常見問題另建議，在招標文件先寫明驗證與接受查核的要求，以避免履約爭議。

磨人把設計階段做好的平台規劃與流程設計檔，當成工程階段仍要回查的文件維護。專案團隊為回覆上級對新功能的提問，需要先前做好的平台規劃與流程設計檔。磨人準備檔案並檢視是否需要更新，當天更新完成，專案團隊再把檔案連結貼回討論串留存。新階段的提問因此能對回既有的設計與流程決定。

既有系統的資料與使用者怎麼承接

磨人在新舊系統交接前，先確認既有系統的資料能怎麼帶出來。會議紀錄記下的做法是：現行後台可以匯出資料，暫時不必另外洽詢原系統的維運方。日後若真的需要聯繫，由專案團隊居中擔任窗口。

既有資料與使用者的轉移，需要原系統維運方的配合。與對方開會的時間，專案團隊評估排在招標之後較適合，磨人接受並把這部分排程往後放。資料端同時備好退一步的做法：請對方匯出現有資料庫，最差情況是從後台匯出表格。

資料帶出來之後，還有搬運的工作。三百多個場域從既有系統搬進新後台時，磨人依縣市把資料分成北、中、南、東與外島四組，每組數十到一百多個，各組自行認領。搬運步驟寫成三步：到既有系統查場域，貼進新後台新增，再補詳細資訊與圖片。缺資料的地方自行查找補齊，搬運過程中對後台流程的意見記到品質清單。後台的輸入格式有調整時，在共用的溝通管道公告並附範例截圖。

已發布的入口與文件連結，也要跟著承接。網站公告分類合併時，磨人先要求讓原本首頁指向舊分類的連結導入新分類。工程師沿用既有分類編號，先改網址，再確認操作正常，舊分類的連結導向新分類後運作正常。新舊系統切換前，磨人另外提醒，既有文件的網址要先設定好，等新系統更新後再換成新系統的網址。

切換當天，工程師向專案團隊說明新舊系統的差異。兩邊都能從後台編輯內容，並把網頁內容存在資料庫。新系統完全重新開發，沒有沿用既有系統的程式，運作機制不同。

決定與表單集中在同一處留存

磨人把決定存放的地方固定下來。主機與資安的討論紀錄，磨人統一放在一份共用表格與一個檔案資料夾管理，專案團隊直接在表格上更新。每個決定因此都有可回查的出處。

活動與課程資料同樣只有一個資料來源。專案團隊把資料維護在共用總表，每月更新後在例會回報磨人。例會暫停時，改在討論串補報，磨人依總表匯入。單一資料來源，避免兩邊各改各的。

介面提供的選項也用文字定案。分類選項由介面端定義，工程端要靠事先告知才會得知異動，因此磨人在選項需要定案時主動詢問，請對方以文字整理清單，日後有異動先告知。選項一旦修改，所有相關資料會再檢查一次。

沒有現成資料來源的項目，規則要先講清楚。老師註冊時要選學校，沒有現成的學校清單 API 可用，只能人工整理成平台可用的格式。磨人先把特殊情況的規則寫出來：涵蓋國中到高中的學校兩邊都放，五專另開頁籤，外籍學校依實際學段放入，找不到分類的先忽略。專案團隊依公開名單複製進表格，分成大學、高中、國中、國小，整理完交回，磨人接手處理。

跨年度例行的事項靠留存的正本延續

資安相關的表單、主管單位安排的掃描與測試報告、稽核佐證，每年都會重複。磨人把這些資料集中在專案總表、資安溝通頁面與專屬的佐證資料夾。專案團隊把新收到的報告當天登錄到表格，磨人需要查過去的申請與紀錄時，向專案團隊要去年留存的版本。年度例行的資安工作有集中的正本，就不必每年重頭找。年度資安工作留下哪些證據，另見公部門專案的交付與維運證據。

年度辦法換新時，同樣沿用既有後台。年度辦法經主管單位核定後，專案團隊把辦法貼給磨人供規劃參考，磨人再請專案團隊共享各單位的課程活動列表。專案團隊提供雲端資料夾，並說明後台已先上架 20 個課程，新年度的課程資料沿用既有後台，以日期切分年度。

新成員接手時從哪裡取得理解

磨人接手既有系統時，先確認現況，再談改動。資安維護報告需要可追溯的數據，磨人把準備工作分成從頭建置與接手既有系統 2 種視角列出。從頭建置要先處理自動備份設定、紀錄機制的完整性，以及能否寫程式快速取得報告數據。接手既有系統要先確認伺服器內安裝的軟體與部署方式、備份範圍與存放路徑、紀錄設定與存放路徑，以及是否已有取數程式。完整的接手流程見接手既有系統的全碼健檢流程。

機關端的新成員接手平台，涉及知識移轉。Ko 等，2005 以 96 個 ERP 導入專案的顧問與客戶配對資料，說明客戶期待顧問把導入知識移轉給員工，以便日後不靠顧問自己維護系統。知識移轉受知識、動機與溝通三類因素影響。研究情境是企業系統導入。

Naur 認為僅靠文件重建這份理解，最多只能是高成本的做法。磨人讓設計標到工程標由同一個團隊承接，新成員可以直接向經手的人詢問，再回到前面各節留存的紀錄核對。

整理程度也影響新成員能否上手。Cunningham，1992 的經驗報告用債務比喻：先交付尚未整理好的程式像舉債，短期加速，不償還時，每一分鐘花在不夠好的程式上都是利息。報告也提到，過度未整理會使程式難以掌握，導致程式設計者過度專業分工。技術債與上線後維運的關係，見上線後為什麼要持續維運。

新成員接手時，可從下列四處取得理解：

• 設計階段的平台規劃與流程設計檔
• 共用表格與檔案資料夾裡的決定紀錄
• 去年留存的申請、報告與佐證
• 切換當天工程師對新舊系統差異的說明

不適合的情況

本文談的是系統會持續修改、標案會換階段的情境。下列情境的知識延續需求較低：

• 活動型網站，活動結束後即下架，之後沒有修改需求
• 系統規模小、功能單純，上線後的修改由原本的維護者持續處理
• 機關內部已有持續維運的團隊，換階段時仍全程參與

這類情境的交接重點在資料匯出與帳號移交。

開始前要準備什麼

標案從設計標進入工程標，或既有系統要交給新的團隊維運時，磨人的長期維運與平台建置會先與專案團隊對照下列項目的現況。

• 既有系統的資料匯出方式，以及退一步的做法
• 需要另外申請的動作，與實際協助的窗口
• 決定與討論紀錄存放的共用表格和資料夾
• 前一輪的申請、掃描與測試報告、稽核佐證的留存版本
• 平台規劃與流程設計檔是否需要更新
• 沒有現成資料來源的項目，整理規則由誰訂、誰整理、誰接手

磨人把客戶的目標當成自己的目標，換階段時由同一個團隊繼續負責。專案即將換階段或要交給新團隊時，可以先把上述項目的現況整理好，再到與磨人討論交接與長期維運說明專案的階段。