本系列取材自真實經歷，人物、場景、對話與時間順序經過合成與小說化處理。文中假設案例與示意數字用於說明觀念。

住戶原本約好讓搬家公司明天來，這晚又打電話到管理室，說時間想提早，還問能不能先把幾件家具放在大廳。

師父先把新的時間和暫放需求記下，請住戶等總幹事確認，再提醒大廳是否能放、放多久，需要另外安排。掛上電話後，他把變更轉交，沒有直接把原來的紀錄整行蓋掉。

我問他：「只是提早一點、多放幾件，你幹嘛記這麼仔細？」

師父說：「原本安排的人和空間，都可能要跟著變。」

先說清楚這次多了什麼

我把問題換成軟體：「假設客戶已經買了 AI 客服工具，做到一半說順便加一個匯出按鈕。這種小改動也要重新談？」

師父說，要先知道按鈕按下去要發生什麼。我回答，應該就是把資料下載成 CSV。師父接著問，匯出誰的資料、包含哪些欄位、一般使用者能不能看到全部，以及資料很多時要怎麼處理。

我說：「你一問，這個按鈕突然變很大。」

師父回答，事情本來就有這些條件，只是剛才沒有說出來。對使用者而言是多一個按鈕，對交付團隊而言可能牽涉資料查詢、權限、格式和效能。

他把原約定和新增要求並排說明。原本是客服查看自己處理的草稿；現在主管希望匯出整個部門的紀錄，用來做每月報告。這需要先確認部門範圍、主管角色和報表內容，不能直接把目前畫面上的資料全部倒出去。

把可選的安排交給對方決定

我問師父：「可是你每次都說要評估，客戶會不會覺得工程師在拖？」

師父說，評估完要提供能決定的選項。假設這次期限固定，可以先提供一份經確認的人工報表；若要新增正式匯出功能，就調整時程，或者把另一項尚未開始的工作移到後面。

每個選項都要說明能得到什麼、有哪些限制，以及誰要提供資料或確認。這樣客戶可以依真正用途選，而不是只收到一句「這要加錢」。

我追問：「如果確實只要改幾行，你也要走這一套嗎？」

師父回答，小改動可以簡短確認，不必每次都做一份長文件。但至少讓雙方知道改了什麼、是否影響原日期，以及完成後怎麼看。若每個人都私下答應一個「很小的修改」，加總起來仍可能讓整個交付變樣。

他補充，工作已經接下來，現在要讓雙方知道原約定怎麼調整，以及哪些部分仍然照原來的方式進行。這樣下一個接手的人，才不會各自拿著不同的版本做事。

變更接受後，驗收也要跟著更新

我問：「客戶答應改日期，聊天紀錄留著就好了？」

師父說，重要決定應該回到大家實際追蹤工作的地方。可以保留對話作為來源，再把更新後的範圍、負責人、時程和驗收條件整理好。工程師如果只看到舊工單，客戶卻拿新聊天內容來驗收，就又會產生一輪誤會。

以匯出功能為例，應該有一份可確認的欄位說明、適用角色和資料範圍，並知道沒有符合條件的資料時會怎麼呈現。若只約定「加上匯出」，最後檔案能下載，卻少了客戶真正需要的月份篩選，雙方可能都覺得自己沒有錯。

我說：「那做完以後還是要再請客戶看一次。」

師父回答，可以在實作前先確認樣本，降低做到最後才發現方向不對的機會。完成後再依約定方式檢查。這樣新增需求會有自己的起點和結果，團隊也知道哪些事情已經完成。

我又問，如果對方後來說這本來就包含在原需求裡，要怎麼辦？師父說，先回到當初的資料，找出雙方理解不同的位置。若原文確實寫得含糊，就一起把需求釐清，而不是急著用「變更」這個字把責任推回去。

人情可以保留

林總幹事回覆了住戶的搬運安排：提早的時段仍需和既有預約協調，家具不能先堆在大廳，請搬家公司依確認後的時間到場。師父再聯絡住戶，把結果說明，留下尚待確認的時間。

我看他把原安排和新回覆都留著，問是不是怕之後有人說沒講過。師父說，日班需要知道現在怎麼處理，住戶也可能再來確認。有前後記錄，才不會每換一個人就重問一次。

軟體需求的「順便一下」也是如此。新增要求要重新確認影響，接受後同步更新範圍、時程和驗收。 可以通融的地方照樣能談，但承諾出去的內容要有人知道怎麼做。