我們用 SMART——Specific（具體）、Measurable（可衡量）、Achievable（可達成）、Relevant（具關聯）、Time-bound（有時限）——把每個故事拆成五天，作為每次動手造輪子前的五個檢查問題。

本篇是故事一「客戶要加個按鈕切換 LED 呼吸燈，一個月後 RD 還在談 CMSIS 與 Clean Code」的 Time-bound 篇：何時要完成？何時必須停止研究、重構或自研？

本篇定位：故事一的收尾，建立時間盒、展示節點與停止條件，並整理第一種手擀破輪子的模式。

當時發生了什麼

這個故事最詭異的地方，是它從來沒有一個「發現進度落後」的時刻。

每週都有進度在動：盤點結構、收斂分層、命名規則定案、資料夾重排、框架介面凍結。每一則回報都寫得出來，也都是真的。直到某次會議上有人隨口問「按鈕現在按下去會怎樣」，房間安靜了一下——大家才同時意識到，在要交付的那份韌體上，那顆按鈕從來沒有被按下去過。開發板上按過幾次，那是臨時試打，不是交付。

如果第一週就有人問這句話，故事大概撐不到第四週。但沒有人問，因為每個人都有進度可以報。「這週完成命名規範審查」和「這週按鈕仍然無法切換」講的是同一件事，前者卻不會讓任何人警覺——用架構語彙寫的週報，讓「還沒開始交付」看起來很像「正在扎實推進」。

真正的問題在哪裡

前面四天談的使用情境、驗收表、最短路徑與改善清單都是好東西，卻共用同一個弱點：它們都可以被無限期推遲。缺的是時間刻度，而沒有日期的計畫只是比較有條理的意圖。

「再整理一下就好了」能無限延長，除了它本來就不可證偽，還有一個更現實的原因：停止線沒有事先畫好，事後就畫不下去了。第三週喊停等於承認前兩週白畫，愈晚喊停要承認的愈多；而喊停沒有人有義務發起，於是它就不會發生。

可以怎麼做

時間刻度不會自己長出來，得做出三種東西。

第一個是節點。 這種需求的時間表短到有點好笑，但一定要有刻度。以工作天為單位排三格：第一格把去彈跳窗、長按、重開機這些行為細節問到答案，第二格交出第一個可操作版本，第三格照驗收表逐列走完。每格幾天由團隊自己填，重點是在動手之前填好。中間那格最關鍵：第一版不必完整，但必須是能交到別人手上按的東西，哪怕只有一條垂直切片。它出現得愈早，錯誤假設被戳破得愈早。

第二個是時間盒。 技術探勘要做，但要框住：呼吸的漸變怎麼做值得花時間試，但要先講好花多少，長度直接借用同一把尺——不超過一條垂直切片的工期。重點是預先約定「時間到了要做什麼」：拿當下最好的結論往下走，或帶著具體問題回來求援。沒有這半句，時間盒只是許願。

第三個是停止條件，寫在動手之前。 任何重構若對應不到驗收表上的某一列，就不在這次做；某項改善若預估超過一條切片的工期，先進待辦；第一版展示那一格到了還按不動，不再擴大範圍，改為回報阻礙。兩個門檻刻意用同一把尺，好記也好引用。事先寫下來，喊停的人就不需要勇氣——不是他在質疑誰，是當初一起訂的條件到了。

回報也要誠實。既有程式如果真的難改，那是要端上檯面的結論：卡在哪一段、有哪些替代方案、需要什麼決策才能往下走。沒納入的改善連同理由進架構決策紀錄或待辦，才不會變成「永遠不做」。

今天學到的事

故事一走完，第一種手擀破輪子的模式也清楚了：把小功能當成大型重構的入場券。

它的形狀每次都很像：一個小到大家覺得「反正很快」的需求進來，因為小所以看起來有餘裕，因為要碰既有程式所以看見了一直想修的東西，因為工程上說得通所以不必誰批准。

五天下來我最意外的是：整個過程沒有人偷懶、沒有人技術不好，也沒有人不在乎客戶。這正是它難防的原因——失控如果來自懶惰，督促就有用；但它由一連串各自正確的判斷組成，每一步都說得出理由，沒有一步會觸發警報。能擋住它的只有事先訂好、與當下判斷無關的刻度。

這個故事的教訓也不落在「不要重構」四個字上。搭便車的重構之所以做不好，是因為它從來沒有被當成一個要驗收的東西：沒有人替它定義完成、排時程，也沒有人檢查它做到了什麼。它享受了「順便」的方便，也就失去了被認真對待的資格。

回頭看，這件事大概是這樣：我本來只需要在門邊裝一個電燈開關，最後卻決定先重新規劃整棟房子的配電系統。配電系統該不該重新規劃？也許該。但那是另一份工程、另一筆預算、另一段停電時間，不該由一顆開關順便夾帶——而屋主到現在，還站在門邊摸黑找開關。

按鈕的故事到此結束。下一個故事換到硬體選型現場：一套辨識系統的讀取距離、頻段、標籤方向與安裝環境都還沒盤點，就有人拿著手邊一條現成的饋線，要求後面的零件都配合它。這次不是把小事做大，是順序整個反過來。