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

地下二樓那盞燈還沒修好。

我回到社區時，林總幹事正在和師父更新進度。廠商已收到反映，但還要安排到場時間。師父把最新聯絡結果記下，又確認如果今晚再次出現異常，應該記錄哪些情況，方便交給廠商。

我問總幹事是不是很快就能處理。他說還在協調，日期確定後會再通知。我便沒有繼續追問一個他手上還沒有的時間。

等總幹事離開，我轉頭問師父：「你們新創的計畫是不是也常常改？昨天還說一定要做，今天就整個砍掉，工程師不會很想翻桌嗎？」

先問什麼資訊改變了

師父說，工程師當然會在意投入的工作。他拿 AI 客服草稿工具的案例繼續說明：團隊原本要做一個完整的回覆統計頁，後來客戶訪談發現，最常卡住的其實是草稿找不到對應政策，客服得重新查資料。

假設負責和客戶聯絡的創辦夥伴把這個結果帶回來，就需要一起討論：原本統計頁想解決什麼、現在的資料是否足以調整，以及改做引用來源能帶來什麼差別。

我問：「只因為一個客戶講了一句，就把計畫改掉？」

師父說，所以要看資訊內容。是客戶順口提議，還是已經觀察到多次工作受阻？問題發生在目標使用者身上，還是很特殊的流程？如果只說「客戶要」，工程師很難知道為什麼原本的重要工作突然不重要。

他補充，原先計畫也有自己的假設。當初為什麼認為統計頁需要先做？是採購前必須提供的資料，還是團隊覺得看起來比較完整？新舊依據放在一起，才有辦法討論，不是每次都讓最新出現的意見直接排到第一個。

已經寫了一半，要怎麼算？

我替工程師問：「可是統計頁已經做一半了，停下來不是很浪費？」

師父說，已經投入的時間不會因為繼續寫就回來。現在要決定的是，接下來的人力花在哪裡比較有用；但停下來同樣有成本，也不能把它當成完全免費的選擇。

他把例子拆開：剩餘工作還要多久、目前成果能不能保留、是不是有人已經在等這個功能，以及切換工作需要重新整理多少背景。

如果統計頁只剩一個小問題，而且客戶下週就需要拿報告向主管說明，完成它可能仍然合理。若還有一大段工作，且原本期待的用途已經不成立，就得認真考慮暫停。

我說：「所以做到百分之幾，本身不能決定繼不繼續。」

師父點頭。他會更想知道接下來要付出的代價，以及做完之後誰會用。工程師也應該把切換成本說出來，不能在會議上看起來只改了一個排序，實際卻要團隊重做一週的準備。

我又問：「那主管每次都說有新證據，你怎麼判斷他不是看到別家新功能就手癢？」

師父說，可以要求把證據和期待結果寫下來。例如調整後希望減少哪種重查工作、用什麼方式觀察、什麼時候回看。這樣之後才有辦法檢查當時的判斷，也能發現團隊是否一直換理由、沒有真正確認結果。

改完排序，還要處理原本的承諾

談到這裡，住戶打電話下來問公設的使用時間。師父先查當天安排，回覆後補上紀錄。我等他放下電話，繼續問產品計畫。

「如果創辦夥伴已經跟客戶答應統計頁，工程團隊決定暫停，誰去說？」

師父回答，負責對外聯繫的人要知道改了什麼，也要和團隊一起確認可以提供的替代安排。可能先提供一份人工整理的資料，也可能需要重新談日期；無論採取哪一種，都得讓客戶理解目前能取得什麼。

他提醒，內部把工單拖到下一欄，不會讓外部承諾自動消失。有人已經安排測試、準備資料或排了主管會議，改動會影響這些人的工作。這些影響也應該算進決策。

我問師父：「那暫停的程式就一直放著？」

師父說，要留到別人能理解的狀態。哪些可以使用、哪些只做到一半、當時為什麼停，交代清楚。未來重新拿起來時，再根據新的情況評估，不要因為有人曾經花很多時間，就把它變成永遠不能刪的東西。

我看著交接簿上那筆尚未完成的報修，說工作狀態看起來都需要更新。師父說，更新的內容要讓下一個人知道現在可以做什麼。事情還在等，就寫清楚等誰、等哪個結果，別只把日期換成今天。

產品優先順序可以改，關鍵是說明新資訊、接下來的成本，以及原本承諾如何處理。這些交代清楚，團隊才有辦法接著做，客戶也不會只看見功能突然消失。

師父把照明報修留在待追蹤事項裡。今晚有了進度更新，但廠商到場維修時間還沒確定。