本文同步刊載於個人連載網站

做到某個階段時，我是真的覺得這套預約管理工具差不多完成了。

預約新增、修改、取消都可以處理。

心理師班表和諮商室使用狀況可以一起確認。

系統只會提供實際可以預約的時段。

預約成立之後，通知、行事曆更新、前一天提醒、電子收據和每日摘要，也都能接著處理。

以我當時的標準來看，原本想做的事情幾乎都有了。

我甚至已經開始想：

接下來要怎麼上線？怎麼介紹給別人使用？

我當時怎麼判斷「做完了」？

那時候我檢查一個功能，通常會看幾件事情：

流程能不能跑完？

不同條件有沒有走到正確的地方？

資料最後有沒有正確更新？

相關的東西有沒有一起變？

該通知的人有沒有收到通知？

如果這些都成立，我就會覺得：

「好，這個功能完成了。」

一個功能完成。

再一個功能完成。

做到後來，大部分功能都完成了。

我很自然地就把很多個「功能完成」加在一起，理解成：

產品也完成了。

現在回頭看，我當時的完成標準幾乎都在回答同一件事：

系統到底做不做得到。

問題其實早就出現了

我不是完全沒有看到操作問題。

功能幾乎做完之後，我自己實際操作時，已經感覺到櫃檯工作沒有原本想像中那麼順。

有些事情要在 LINE 裡一層一層操作。

需要一次看比較多資料時，又會切到 Google Sheets。

看完之後，再回 LINE 繼續處理。

這些現象我都看得到。

但當時它們沒有讓我得出：

「產品還沒完成。」

我的理解更接近：

這只是現在沒有櫃檯專用前端，所以必須接受的代價。

只要最後工作還是做得完，我就沒有把這些不順手算進「未完成」。

真正缺少的，不是功能，而是完成標準

Day 9 寫到，mentor 看完多步驟操作之後，跟我說：

「這樣太工程師了。」

那次我先看到的是：

系統處理順序，不應該直接變成使用者操作順序。

再往後看一步，我才發現，那句話真正改變的還有另一件事：

我用什麼標準判斷產品已經完成。

因為我原本檢查的幾乎全部都在系統裡。

功能有沒有做出來。

條件有沒有判斷正確。

資料有沒有更新。

通知有沒有送出去。

這些當然都很重要。

少了其中任何一個，系統都可能不能正常運作。

但如果真的要交給別人每天使用，還有另一個問題：

使用它的人，能不能用一個合理的方式把工作完成？

「做得到」和「適合每天這樣做」不是同一件事

假設櫃檯只是想修改一筆預約。

系統最後確實可以成功修改。

但如果每次都要經過很多層操作，才能找到那一筆資料，再一步一步完成修改，那功能雖然存在，工作方式還是可能很累。

或者一件事情做到一半，要先切去試算表找資料，再回到 LINE 繼續。

每一個步驟都能正常執行。

整件事情卻不一定適合每天重複做。

這時候我才第一次很明確地分開：

功能完成。

和：

產品完成。

功能完成代表：

系統已經有能力做這件事。

產品完成還需要再看：

使用者能不能真的用這個方式工作。

原本準備上線的版本，被我收回來了

mentor 指出問題之後，我沒有照原本的計畫直接上線。

原本已經開始往宣傳、推廣方向走的版本，被我收回來繼續改。

而這次要改的，也不是再補一個功能。

我第一次認真開始想：

櫃檯是不是需要一個自己的操作介面？

不是因為 LINE 突然不能用了。

也不是因為前面的預約規則、通知、自動同步都做錯了。

那些東西仍然有價值。

真正需要重新看的，是：

櫃檯每天要怎麼使用這套產品。

當時我還不知道最後會怎麼做。

不知道哪些事情繼續留在 LINE。

也不知道哪些會移到另一種介面。

但原本那個「功能都做完，所以產品差不多完成」的判斷，已經不能再繼續用了。

產品不是功能清單的總和

回頭看前面這幾篇，我一路都在學怎麼把工作做進系統。

理解現場。

把固定條件交給程式。

使用成熟工具。

拆出不同情境。

讓 AI 理解需求。

把功能真的做出來。

這些都很重要。

但做到這裡，我才第一次明確知道：

把工作做進系統，和把產品做完，中間還有一段距離。

產品不會因為功能一個一個完成，就自動形成。

如果這套東西真的要進入別人的日常工作裡，使用方式本身也屬於產品的一部分。

所以現在再看那個原本準備上線的版本，我會把當時最大的差別說成：

我原本只在問「系統做不做得到」，後來才知道，還要問「人會不會用這個方式工作」。

而下一個問題，也很快浮出來。

這次不是產品應該怎麼被使用。

而是：

原本把這些功能做出來的方法，還撐得住嗎？