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

後來接到一個委託專案時，我面對的是一套自己原本完全不熟悉的行政工作。

但當對方開始描述平常怎麼做，我很自然就會繼續往下問：

這一步做完之後呢？

接下來是誰處理？

中間需要哪些資料？

哪些事情可以交給系統，哪些還是需要人處理？

我當時沒有特別覺得自己正在使用什麼方法。

只是已經很自然地這樣理解工作。

整理這個系列時，我才發現，這種思考方式早在第一個預約管理產品裡就反覆出現了。

原來我一直在做一種翻譯。

現場說的是工作

現場的人通常不會用工程語言描述自己的工作。

他們說的可能是：

「這裡要確認一下。」

「處理完之後要通知下一個人。」

「這份資料整理好之後，再繼續往下做。」

對熟悉工作的人來說，這些話已經很清楚。

但如果真的要把工作做進系統，就需要再往下整理。

系統到底要知道什麼？

什麼資訊需要被留下來？

什麼條件成立之後才可以繼續？

接下來要由系統做什麼？

哪些地方不能直接往下走，還需要人判斷？

前面幾篇寫過，我一開始並不是很有意識地做這些事情。

更像是一個功能做下去，遇到一種情況，再多問一句：

「那這種情況呢？」

做得久了，這種往下拆的方式就變成我理解需求時很自然的反應。

翻譯的不是名詞

後來我才逐漸知道，流程、角色、狀態、資料，以及不同系統該負責什麼，軟體工程早就有很多成熟的知識和方法可以處理。

但我說的「翻譯」，並不是把一句工作的語言換成幾個工程名詞。

不是聽到「做到哪一步」，就把它換成 state。

也不是看到一連串工作，就把它叫做 workflow，事情便完成了。

真正需要被翻譯的，是原本藏在日常工作裡的結構。

一件事情怎麼開始、怎麼往下走。

中間需要哪些資料和條件。

哪些地方可以固定處理，哪些地方需要人的判斷。

前一步做完之後，什麼資訊還要繼續帶到後面。

把這些事情整理出來之後，它們才變成可以繼續討論、實作和檢查的問題。

第一個產品留下的，不只是那套產品

我的學習順序不是先把這些工程概念學完，再拿它們去分析工作。

更常發生的是：

先遇到真的工作。

跟 AI 討論怎麼做。

進入實作。

被追問、撞到問題，再補上原本不知道的概念。

這種事情反覆發生之後，我開始比較會把現場說的「工作」，往系統需要理解的方向拆。

所以第一個預約管理產品真正留下來的，不只是我對諮商所流程比較熟，也不是做過哪些功能。

它留下了一種可以帶到其他地方的理解方式。

我開始習慣把人的工作，翻譯成工程可以繼續處理的問題。

而到了下一個完全陌生的工作現場，我才第一次很明顯感覺到：

這種能力，真的跟著我一起過來了。