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

本篇是故事二「RFID 天線還沒選型，RD 先要求它配合手上那條饋線」的 Time-bound 篇：何時要完成？何時必須停止研究、重構或自研？

本篇定位：替硬體選型建立時間盒、比較節點與淘汰條件，限制無止境的零件比較與客製化，並收束故事二的手擀破輪子模式。

當時發生了什麼

故事二有兩種失敗方式，而且互為藉口。

一種是第一天就定案：拿出庫存零件，宣布規格，其餘都是配合。優點是快，缺點是快到還來不及知道要解什麼問題。

另一種是永遠不定案。有人指出第一種做法的問題後，很自然走向反面：那就多評估幾款吧。候選清單愈開愈長，會議變成「還有一款可以看看」。這種狀態危險在它看起來非常嚴謹：沒有人能指責一個正在做更多驗證的團隊，就像沒有人能指責一個還想再整理一下的工程師。

兩種狀態我都待過。讓我不安的是，兩邊都沒有人說得出這件事什麼時候會結束。

真正的問題在哪裡

選型缺的不是意見，是節點。

需求盤點、候選收斂、實測、決策，會議上是連著講的，沒人替它們畫界線。沒有界線就沒有「這一段做完了」這回事：需求可以一直補，候選可以一直加，實測可以一直做，而前三件沒完，第四件就永遠不必發生。

更深一層是，沒有人被指定要在某個時間點做決定。當提出庫存料件的人同時是最資深的工程師，「不用它」在流程上沒有歸屬：誰有權說不、什麼證據足以說不，都沒定義。於是它不是被選中的，是預設值——預設值不需要任何人負責。

上一個故事的停止線，處理的是「再整理一下就好」這種可以無限延長的工作；硬體這邊更硬，因為每一次重來都要重新採購、重新排時程、重新進現場——樣品再借一輪，天線再拆再鎖，現場時段再喬一次。試錯成本不像改程式那樣推一版就能重來。零件會停產、場域會改、預算有限，硬體決定永遠是不完整資訊下的取捨；承認這點，才定義得出「夠好了」。

可以怎麼做

先把選型切成四個階段，每段到期要交出什麼，事先講定。至於每段給多久，別憑感覺抓：從專案的交付節點往回推，扣掉樣品借測與到貨的等待、扣掉現場能配合施工與測試的可預約時段，剩下的才是能拿來比較的區間。回推後如果是負的，該砍的是候選數量與比較維度，不是把比較期往後延——延掉的那段最後都會從驗證扣回來。

一、需求盤點。 交付物是場域條件表，加一份和現有料件分開放的供應條件清單。到期就是到期：不足的欄位標為未知並註明風險，別用「還沒問到」拖住整條路。

二、候選收斂。 依「場域、天線、傳輸路徑、機構」的順序篩出少數幾類，並明訂進入實測的組合最多幾組。上限是逼人用最強的限制先篩，不把判斷延後給測試。

三、實測。 每次測試都對應一個會影響方向的假設。這段最需要的是淘汰條件：法規頻段與功率不符、最差情境下讀不到、安裝空間放不下、交期超過專案節點，命中任一項直接出局，不必再最佳化。

四、決策。 產出是一份紀錄：選了什麼、依據哪幾次驗證、淘汰哪些、已知風險與替代方案，並指定做決策的人。門檻也在這裡發揮作用：最差情境下能穩定達成場域需求、裝得下、修得了，就算過；第二好但能如期交付，通常勝過第一好但趕不上。

最後補一條現有零件的退場規則：庫存料件和其他候選走同一套驗證，通過就用，沒通過就不用，決定權在做決策的角色手上，不在持有者手上。這條寫在前面比事後爭論容易，那時它還不是誰的立場。客製化同理：標準品全數落選、缺口具體可描述才啟動，一樣要有時限與退場方式。

今天學到的事

故事二到這裡收尾。它的模式值得記下名字：讓手邊的解法反過來定義問題。配方很固定：一個還沒盤點完的需求、一個現成又熟悉的零件、一句「反正都有了，配合一下」，整套規格就圍著它生長。

這種模式最難察覺的，是它每一步都很像節儉、很像務實。但節儉的前提是知道自己在買什麼，而我們連要解決什麼問題都還沒寫下來。它有個很早的訊號：白板上第一個被寫下的是零件型號，而不是場域條件。看到那一幕就該問一次：這是候選，還是前提？問得夠早，後面的事大半不會發生。

總結這個故事：輪子還不知道要裝在哪台車上，我們已經因為倉庫剩下一顆螺帽，決定整根輪軸都照它的尺寸製作。

有意思的是，這兩個故事的主角都是「東西」：一份程式碼、一條饋線。下一個故事裡，反過來定義問題的那個更難處理，因為它不在倉庫，也不在版本控制裡，而在人的腦袋裡：當一位工程師說「你這個介面我看不懂」，這句話會怎麼變成一份產品規格？