磨人把客戶的目標當成自己的目標。合作初期先問出專案要解決的問題，再把目標拆成驗收時看得到的項目。報告要用的資料，在上線前就決定怎麼留。
本文以配合教育部專案的戶外教育資源平臺為例，整理設計、開發、上線到活動結束各階段，目標怎麼變成驗收項目。這類平台與後台的建置與維運，見長期維運與平台建置。
合作初期先問出專案要解決的問題
合作初期的會議上，專案團隊先說明平台為什麼要有「用地圖找場域」：全台的場域資源分散在不同單位，希望整合到同一個平台。另外也希望重新做問卷調查。這兩段說明讓平台的核心功能與調查對象，都對應到專案團隊想解決的問題。
專案團隊要重新調查目標對象的需求，開發團隊把問卷設計列為可以協助的項目：依不同身分先擬出對應的問卷草稿，當次先擬文字，具體題目隔週再討論。戶外教育資源平臺的 Platform PO Lai 在合作評語中，以「透過細緻的討論與分析」「掌握到核心問題」描述這段合作。
需求不足對軟體專案的影響，文獻也有討論。Hofmann 與 Lehner，2001把需求工程視為軟體專案的成功因素，文章開頭主張需求不足是專案失敗的最大原因之一。
目標拆成可量測項目，再對照到驗收
Locke 與 Latham，2002總結 35 年的目標設定研究：具體且困難的目標，績效一貫高於只要求「盡力而為」；目標具體，要達成什麼就比較不模糊；人要有回饋才知道離目標多遠，目標加上回饋的效果優於只有目標。研究對象以個人與工作團隊為主。磨人的做法是把目標寫到能判斷達成與否，每個目標都對應到驗收時看得到的項目，並標明資料從哪裡來。
目標寫成一句話之後，下一步是拆成驗收時看得到的項目：看什麼、資料從哪裡來、用什麼方式檢查。下表用這個平台的幾項目標，示範四個欄位的寫法。
| 目標 | 可量測項目 | 資料來源 | 驗收時怎麼看 |
|---|---|---|---|
| 場域資源整合到同一個平台，使用者用地圖找場域 | 使用者測試的核心任務：找到符合主題的場域，查看地圖位置與交通路線，取得聯絡方式 | 使用者測試 | 使用者測試結果報告，逐項對照任務結果 |
| 符合專案團隊提供的資安規範 | 6 項規範的實作位置，涵蓋帳號、密碼、登入防護與重設流程 | 規範條文與前後端的對照表 | 逐條對照，每一項標明前端、後端或兩邊負責 |
| 通過無障礙檢測 | 所有圖片都有替代文字，動態資料逐項盤點 | 後台圖片描述欄位、動態資料盤點 | 無障礙檢測結果，網站取得無障礙標章 AA 等級 |
| 期末報告有可信的數據 | 前台瀏覽紀錄、檔案下載次數、平台內活動、場域、路線的互動 | 瀏覽紀錄、下載紀錄介面、後台流量分析分頁，搭配 GA4 | 後台看得到各檔案下載次數，流量分析分頁可匯出 |
| 搜尋與分享時看得到活動 | 分享預覽的圖片與描述、單一網域的網站地圖 | 分享預覽、網站地圖 | 貼出網址時預覽有圖片與描述，網站地圖可取用 |
「驗收時怎麼看」這一欄，在簽約前就要能填出來。每項交付能否當場判定的查核方式，見軟體外包廠商的評估表。
驗收任務用情境寫
使用者測試的核心任務，寫成情境加流程，不寫成功能名稱。例如：在某縣市找到符合自然生態主題的場域，查看地圖位置與交通路線；找到場域後取得聯絡方式。任務的流程可依實際的試作畫面調整。
這樣寫的原因，是測試要驗證場域資訊是否符合期望，並能幫助使用者做決策。情境任務可以檢查使用者拿到資訊之後，能不能繼續往下做事。磨人把定案的核心任務交給設計師，設計階段結束前，先後交出驗收簡報與使用者測試結果報告，以任務的結果支撐設計定案。
範圍：合作初期到設計階段結束
外部規範拆成可檢查的項目
機關與廠商之間的履約管理、驗收與付款，法律依據在政府採購法：第四章規範履約管理，第五章規範驗收與付款。需求書的文件與查核條文如何整理成交付項目，見公部門專案的交付與維運證據。平台要符合的內容，則來自專案團隊提供的規範，例如資安規範與無障礙檢測要求，開發團隊再逐條對應到實作。
資安規範有 6 項，涵蓋帳號鎖定、密碼規則、防自動化登入、重設流程與密碼儲存。開發團隊把每一項對應到實作位置，標註由前端、後端或兩邊負責，並為防自動化登入選定現成方案。
無障礙檢測要求站內所有圖片，包括圖示與標誌，都有替代文字。開發團隊提醒所有負責內容的人，後台編輯的圖片一律要填描述，內容要與圖片相符，動態資料另行逐項盤點。檢測同時有軟體自檢與人工複審，軟體自檢會掃描站內每個點得到的網址，所以替代文字要涵蓋前台、後台與動態資料。
無障礙等級是主管單位對平台的驗收要求之一，網站取得無障礙標章 AA 等級。
報告要用的數字，上線前決定怎麼留
期末報告要引用的數字，不能等到報告前才去找。瀏覽、下載、平台內的互動，這幾類資料要在上線前確認有寫進紀錄，沒有寫進去的流量，事後無法重算。
工程師在上線前逐類檢視前台瀏覽紀錄的涵蓋範圍，並列入清單追蹤。瀏覽紀錄是日後檢視流量的基礎資料。
檔案下載次數需要另外設計。品質確認清單列了「後台可展示檔案下載次數」一項，工程端與前端確認做法後，前端在每次有人下載檔案時呼叫一支紀錄介面，後台才能顯示各檔案的下載次數。
GA4 抓不到平台內的細部互動，例如活動、場域、路線。開發團隊因此主動在後台新增「流量分析」分頁，補上這部分數據並可匯出，同時更新流量總表，供專案團隊搭配既有的 GA4 資料使用。專案團隊回覆資料清楚，規劃收進期末報告。
- 列出報告要引用的數據上線前確認
- 確認資料有寫入紀錄瀏覽紀錄、下載紀錄
- GA4 已涵蓋使用 GA4 資料
- 平台內的活動、場域、路線等細部互動後台流量分析分頁可匯出，並更新流量總表
- 個別清單或內容，例如心得、得獎者後台匯出表格心得先提供表格版本；得獎者匯出檔含最後一次抽獎時間
範圍：期末報告用到的流量與名單資料
跨年度對照要事先處理。上線初期，專案團隊提出 2026 全臺戶外教育季也要有與前一年相同的參與者統計頁，前一年的舊資料要保留以便對照。開發團隊回覆，活動期間以可匯出的表格提供數據，活動結束時再做最後一次匯出。活動資料在上線前如何整理與編號，見跨部會活動的資料整合。
積分排行可能同分，獎品遞補需要客觀依據。專案團隊提出後，開發團隊在後台匯出檔加入最後一次抽獎時間欄位。
專案團隊為了撰寫期末報告，請開發團隊優先處理後台的心得匯出。工程師先提供可立即使用的表格匯出，報告先有資料可用；圖片放進表格不易處理，另外處理。優先序由雙方在回報時直接調整。
合約沒寫到、但影響成效的事
驗收項目之外，還有一些事合約不一定寫到，卻直接影響客戶要的結果。磨人把這些事也列進工作項目，看到就提出來並說明理由，決定權留給專案團隊。
開發團隊以搜尋曝光與日後廣告用語一致為由，主動建議把對外活動名稱統一成較好辨識的主名稱。雙方討論後採兩個名稱並陳，最終寫法由專案團隊決定。對外大力宣傳的時間點，開發團隊建議訂在辦法全部確認、工程端調整完成之後，搭配動畫影片與懶人包圖文同步釋出，宣傳內容與實際功能才會一致。
三個社群貼文版本擺在面前時，開發團隊先說明取捨：資訊多的版本可能點擊較多，簡潔版可能溝通不清。接著主動提出「一篇主貼文加每月替換內容」的做法，按月更換分享主題，活動每月都有新話題，也不必每次重做版型。
搜尋與分享預覽是民眾找到平台的主要入口。上線期間，磨人把網站搜尋曝光當成自己的目標，主動檢查分享預覽的圖片與描述，並在確認單一網域後產生網站地圖。
範圍管理這一端，Komal 等，2020以文獻回顧與專家訪談找出範圍蔓延的因子，再以問卷與 PLS-SEM 分析，發現這些因子與軟體專案成功度呈負相關。目標已拆成可量測項目時，中途提出的要求可以先對照目標，再由專案團隊決定是否納入。
活動結束後，成效回到下一年度的規劃
活動結束後，磨人先把簡略分析提供給專案團隊；專案團隊的內部討論需要更細的資料，磨人接著補上。討論後，專案團隊把回饋整理成條列傳回，涵蓋機制調整、合作與場域擴充、下年度目標設定等面向，成為下一年度規劃的輸入。
不適合的情況
- 只做一次的形象頁或活動頁，沒有後續報告：項目少，頁面清單就能涵蓋驗收，拆成效指標的工夫比頁面本身更大。
- 驗收表與項目全由上級機關規定：重點在逐條對應條文，成效指標只能在規定之外補充。
- 規範不允許蒐集使用資料：成效要改用問卷或人工回報取得，本文的紀錄與匯出做法不適用。
- 目標在專案中途經常更換，也沒有人能決定優先序：先處理決策流程，再談拆項目。
開始前要準備什麼
開始前需要備好四項：
- 客戶想解決的問題，用一兩句話寫下，不寫功能名稱。
- 適用的外部規範與檢測要求。
- 報告的對象、時間點與要引用的數據。
- 範圍變動時，負責決定是否納入的人。
備齊之後，可以討論專案目標與驗收項目。
