海外專案臨時改需求怎麼處理？變更評估與批准流程

海外專案進入執行後，新增要求常被一句「順手加一下」帶過，直到工時、預算或交付日改變，雙方才發現理解不同。穩定的做法是把每項改動對照已確認的範圍，先記錄影響，再由有權決定的人批准後排進工作。以下用明確標示的假設情境，說明如何建立可追蹤的變更流程。

什麼情況應開變更單？

變更單的觸發點，不是客戶說了哪個關鍵字，而是要求是否改動雙方已確認的交付基準。新增或刪除頁面、語言、功能、資料欄位、交付格式、驗收條件、依賴素材或工作順序，都應先留下變更紀錄。即使尚未知道影響多大，也可先登記待評估，不能因為估算未完成就口頭承諾。

先分清澄清、缺陷修正與範圍變更。澄清是把原規格的模糊處說明清楚，且沒有擴大成果；缺陷修正是交付物未符合已寫明的條件；變更則是要求增加成果、改變已同意的條件，或重做原本正確的內容。是否包含免費修正或幾輪修改，應回看原約定與已批准紀錄，不要用團隊習慣代替雙方共識。

一個簡單判斷法是問：若照新要求工作，原估時、成本、日期、品質檢查或其他人的工作會不會不同？只要其中一項可能改變，就開單評估；若只是無影響的文字澄清，也至少在原任務串留下答覆，避免不同人按不同版本執行。

假設專案原定交付八頁中英雙語網站，執行中有人提出再加四頁，並新增海外代理商登記表。這兩項會增加內容、介面、測試和交接工作，應分列需求，而非併成「微調網站」。反過來說，若只是更正一個團隊自己打錯的產品名稱，且原內容已核准，應先依缺陷處理方式修正並記錄，不必把它包裝成新增需求。

收到訊息時，負責窗口先回覆「已登記，評估後確認」，附上需求編號與預計回覆時間；這不是批准，也不代表日期已承諾。提出者若只描述結果，例如「希望更適合當地市場」，窗口應追問要改哪個畫面、文字或流程、誰會驗收。先把要求變成可判斷的內容，才知道是否需要變更單。

如何描述原範圍與新需求？

變更單要讓未參加會議的人也看得出差異。先引用目前有效的範圍版本或交付清單，寫明原先包含什麼、交付形式與驗收條件，再逐項描述新要求。避免只貼「照會議討論」，也不要用「優化」「更國際化」這類無法直接估時的詞當規格。若原始文字有歧義，標出待確認處，不要自行選一種解讀。

每個項目可記錄提出者、需求目的、受影響的成果、必要輸入、驗收方式、希望完成日、依賴對象及尚未決定的假設。目的用來判斷替代方案，驗收方式用來界定完成；兩者不可互相取代。把必要條件與偏好分開，並列出不在本次評估內的項目，避免一句新增要求被擴寫成整套市場研究或後續維運。

例如，原本只有一般聯絡頁，新的說法是「加入代理商表單」。這仍不足以排工：要確認表單收集哪些欄位、是否有必填項、提交後要顯示什麼訊息、資料寄送給誰、由誰提供核准文案，以及哪些畫面需要測試。若資訊尚缺，狀態應標為待補資料，列出提供人與期限；在資料到齊前，不把未確認的假設當成已批准範圍。

可以用一張差異表固定討論焦點：

送出評估前，請需求方確認差異描述，而非直接簽認價格。若文字、素材、語言版本或資料來源尚未提供，將其列作估算前提，並說明前提改變時要重新評估。這樣能避免估價建立在一個需求方從未承諾的猜測上。

工時成本由誰評估？

專案負責人收集需求並拆工作，不應單獨替所有專業環節猜工時。請實際執行設計、內容、工程、在地化及品質檢查的人，依新交付物分別估算；若有外部依賴，負責對接的人說明等待條件與可能重排的影響。商務窗口再依雙方既有的計價方式整理成本與選項，並讓批准者看見每個數字如何形成。

估算以可驗收的工作項目為單位，例如需求澄清、版面、撰寫、製作、整合、測試及交接。每項寫出工作量、執行人或角色、所需輸入、估算依據與主要不確定因素；不要只給一個總數，也不要把日曆等待時間混成工時。若資料缺漏，提供條件式估算，說明哪些資訊一到手就要重算。

以下數字純為假設示範，假設新增代理商登記表的工作都能按目前描述估算：

若再假設計價單位是每小時新台幣二千元，示範金額是十小時乘二千元，合計二萬元；這只是計算例子，不代表任何品牌報價、費率或稅務處理。實際報價應回到適用的合作約定，說明幣別、計價單位、可能另計的工作及有效前提。若工程估算和內容估算依賴不同素材，兩者需各自標明假設。

評估時應同時列出選項：完整新增、縮小需求、延後到下一階段，或先補齊資料再估。每個選項說清交付差異、估時、成本與日期影響，讓批准者按價值和資源取捨，而不是只收到「要加錢或不做」兩個極端答案。估算者確認工作量，預算權責人批准商業承諾，兩個責任不要混在同一個口頭答覆裡。

批准前哪些工作先暫停？

等待批准時，暫停可能因新要求而報廢、返工或產生額外成本的受影響工作；其他不依賴這項決定的工作，可按原核准版本繼續。專案負責人要把受影響項目、暫停原因、暫停起點、依賴關係和恢復條件寫在變更紀錄中，並通知執行人。這樣既不會假裝新內容已經成立，也不會把整個專案無故停擺。

先檢查工作依賴圖：若新版文案會決定頁面版面，文案與相關設計可能要等；若功能方向未定，對應實作及其測試先不要進入不可逆階段。可保留已完成的分析、整理既有素材或執行不受影響的工作，但不能把這些準備偷算成客戶已批准新增範圍。已排程的外部資源或採購也應先確認能否取消、保留或調整，再承諾新的支出。

假設網站既有頁面的測試已經開始，此時才提出增加代理商表單。可繼續測試原八頁的既定內容，但新增表單的資料欄位、提交結果與相關介面先標為待決，不宜先做完再要求追認。若兩者共用同一套表單元件，工程負責人要指出共用部分可能受影響，必要時暫停該部分並保留其他頁面的測試。

暫停範圍應小到足以控制返工，又大到不會讓團隊誤用舊假設。每個停工項目都要有一個恢復條件，例如收到核准欄位、確認文案或指定預算；若批准期限會影響原排程，也需把等待時間寫入計畫。對方尚未回覆時，按既有約定處理原範圍，並清楚說明新增部分尚未開始，而不是默默把新要求塞進原估時。

若提出者要求先做、稍後補批，窗口應先查明是否已有書面授權可進行有上限的探索工作；沒有授權，就不先開展額外製作。每次狀態改變都更新紀錄，避免執行者只從聊天片段推測哪項工作可以恢復。

如何更新日期與負責人？

變更批准後，專案負責人先把新工作插入依賴順序，再核對現有人力與其他承諾，然後發布更新後的里程碑。不要只在原完成日上加一個估計天數：新增工作可能卡在客戶素材、跨時區確認、翻譯或既有驗收之後，也可能和不相依的任務並行。日期要標明是預計還是已確認，並列出會讓它再次改變的前提。若估算仍有區間，分別記下最早可行日及尚待條件，避免單一日期掩蓋不確定性。

每項新增交付都要有負責角色、協作者、提供輸入的人、驗收人，以及各自需要完成的時間點。負責人不是「整個團隊」，驗收也不能只寫「客戶確認」；要指明哪位授權者依哪份條件回覆。若舊工作被取代，需更新任務指派並告知原負責人，避免舊版清單與新排程同時被當成有效指令。

假設新增表單需要欄位確認一個工作日、設計兩個工作日、製作三個工作日、測試一個工作日，且工作依序進行，則共增加七個工作日。這個假設不含等待輸入的日曆時間，也沒有假定各階段可平行。專案負責人應把它放回當前排程，檢查是否撞上既有里程碑，再更新受影響的日期，不能直接把七天加在整個專案所有交付上。

排程更新可同時保留變更前後的里程碑、受影響交付、負責人和日期，並指出延後的是哪一項、原因為何、哪些事情仍按原計畫進行。若批准者選擇縮小需求或延後實作，應重新估時並更新版本，不沿用完整方案的日期。通知所有會受影響的人，請他們確認新任務和依賴是否可行；沉默不等於承接新日期或新責任。

舊版決定怎麼保留追溯？

以一個穩定的變更編號連結原始範圍、需求說明、評估、批准紀錄、排程版本和最後交付，並保留每次更新的日期、作者與決定狀態。不要把原始文件直接覆寫成新版，也不要只在聊天軟體裡留一張截圖；未來需要釐清時，團隊應能從索引找到當時依據，而不必猜哪一個附件才有效。

每版至少保存原範圍與新差異、需求提出者、估算及假設、預算與日期影響、批准或拒絕的人、決定時間、附帶條件和後續責任人。拒絕、撤回、逾期未決的要求也保留狀態與理由，不應刪除，否則日後同一要求重提時會失去背景。涉及敏感資料時，只保存工作判斷必要的摘要，並依團隊既有的存取方式控制文件權限。

假設變更單第一版記錄新增表單與完整估算，批准者後來只核准表單的精簡欄位。第二版就應連結第一版，明確標出核准的是哪些欄位、哪些項目未批准，以及估時和排程如何重算。若幾週後又要求增加語言版本，另開新變更並參照相關舊單，不要把舊單改寫成彷彿當初一次同意，這樣才看得出每次決策如何影響交付。

工作完成後，把已批准版本、驗收結果和未完成項目指回同一變更紀錄，讓交接者知道實際做了什麼、哪些仍待處理。對外同步時附上本次有效版本入口，請執行者停用舊清單；舊紀錄保留供追溯，不再作新指令。下一步可先建立一頁變更單範本，拿一項正在等待決定的要求，填入原範圍、差異、評估人、批准人與受影響排程，再邀相關負責人確認。若要了解 Chan & Chung 的背景與聯絡入口，請從官方網站開始。