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

前幾篇一直在整理功能做出來之後，我怎麼確認它有沒有做對。

但如果今天連功能都還沒開始想，我現在第一個會看什麼？

對我來說，答案已經變得很自然：

先看人到底怎麼工作。

這不是因為我已經學會一套完整的需求分析方法，也不是每次開始專案，都會拿出固定表格逐項確認。

只是前面兩個產品一路做下來之後，有些問題已經變成我理解工作時會自然注意的事情。

先看工作怎麼往下走

我現在會先沿著一件工作的前後關係往下追。

這件事情從哪裡開始？

第一步做完之後，接下來做什麼？

還是同一個人繼續處理，還是會交給另一個人？

中間有沒有什麼事情必須先完成，後面才能繼續？

哪裡需要等待資料、文件、回覆，或者等另一個人完成工作？

第一個預約管理產品裡，我常常是一個功能做下去之後，才慢慢發現前後還藏著其他工作。

到了第二個委託專案，我已經會在開始討論功能以前，先沿著現場工作把這些關係看清楚。

再看工作靠哪些東西才能完成

工作不只是由一連串動作組成。

每一步通常還會用到資料、文件、其他人的資訊，以及原本就在使用的工具。

所以我也會注意：

這一步需要什麼資訊？

資料從哪裡來？

前面已經產生的內容，後面是不是還會繼續使用？

是不是有些資料明明已經存在，下一步卻還要靠人重新找、重新輸入？

我也會看不同工具在整件工作裡各自負責什麼，以及資料怎麼在人和工具之間移動。

整理這個系列時，我曾經用「黏著劑」來描述資訊工具的角色。

現在這個說法對我來說更具體了。

不是看到很多工具，就想辦法把它們全部串起來。

而是先看一件工作怎麼在人、資料和工具之間往下走，再找出哪些地方仍然需要靠人反覆搬運、確認或銜接。

那些地方，才可能是系統真正需要介入的位置。

也要看什麼時候不能照平常方式做

現場不會永遠只有一條最正常的流程。

有些事情只要條件成立，就可以照固定方式往下走。

條件不成立時，可能需要停下來、換另一種處理方式，或者交回給人判斷。

第一個產品裡，我常常是做到一半才想到：

「那這種情況呢？」

這個問題問得夠多之後，現在它比較容易在實作以前就自己出現。

所以我不只會問：

「平常怎麼做？」

也會繼續看：

「什麼情況下，不能照平常這樣做？」

這和前一篇提到的 Happy Path 是不同階段的問題。

驗收時，我是在問還有哪些情況沒有被驗到。

產品開始以前，我要先理解的是，現場本來就有哪些情況會改變工作的做法。

如果一開始沒有看見這些差異，後面的系統很容易只知道最順的那一條路。

最後要知道，什麼才算真的做完

另一個我現在很常追問的問題是：

這一步工作最後到底要完成什麼？

現場會看到很多操作。

開檔案、查資料、填欄位、寄信、通知別人、留下紀錄。

但這些都只是過程。

真正重要的是，這一串操作最後要完成哪一件工作。

知道終點之後，我才比較能判斷這一步真正需要哪些資訊、哪些條件還沒完成，以及什麼時候可以進到下一段工作。

也比較不容易看到現場有一個動作，就直接在新系統裡做出一個對應功能。

使用者需要的未必是一個「上傳按鈕」。

更前面的問題是：

他上傳這份東西，是為了把什麼工作完成？

我的起點已經往前移了一點

第一個產品時，很多事情是功能做到一半，我才知道原來需要問。

到了第二個專案，這些問題開始比較容易在實作以前出現。

我還不會把這些整理成一套完整的方法，也不覺得自己已經能把所有現場工作一次看完整。

但我的起點確實往前移了一點。

在開始想系統要做什麼以前，我現在會先看人到底怎麼把工作做完。

看懂工作之後，下一個問題才是：

要讓這些工作真的進到系統裡，我有哪些工程問題不能不問？