我開始能從工作流程看見系統需要做什麼

Day 13 寫到，我把現場看到的一連串操作整理成工作階段，再把這些階段接成流程圖。

有了這張圖之後，我開始做下一件事：

如果這整條工作真的要進到系統裡，系統到底需要知道什麼？

這一次，我很明顯感覺到，第一個產品裡慢慢養成的思考方式已經跟著我過來了。

以前很多工程問題，是功能先做下去之後才慢慢出現。

這一次，還沒真正開始實作，我已經可以先沿著人的工作流程，整理出系統需要管理哪些事情。

先把整件工作看成一個案件怎麼往下走

準備提案時，我開始用「案件生命週期」的角度重新看前面的流程圖。

因為那些工作階段串起來，就是一個案件從進來、被處理，到最後完成的整個過程。

對現場的人來說，真正重要的不是：

「系統剛剛執行了哪一個動作？」

而是：

這個案件現在走到哪裡？

所以到了系統裡，原本整理出的工作階段，也開始變成系統需要掌握的案件狀態。

一個案件還在等待資料，和資料已經確認完成、可以進入下一段工作，就是不同的狀況。

系統需要知道這些差別，才有辦法正確呈現目前進度，也才知道哪些事情現在可以繼續。

但不是每做一個動作，案件就要換一個狀態

現場裡的一個工作階段，通常不只有一個動作。

同一段工作裡，可能要查資料、確認內容、整理文件、留下紀錄。

這些事情都做完之後，案件才真正進入下一個階段。

所以我開始分開看兩件事：

案件現在在哪一個工作階段。

以及：

這個階段裡還有哪些事情需要完成。

這個差別對我來說很重要。

如果每一個小動作都變成一個狀態，整套流程會變得很碎。

但如果系統只知道一個很大的階段名稱，又完全不知道這個階段裡還需要完成什麼，也很難真的支援工作。

所以我會先用工作階段掌握案件目前的位置，再往下看，這一段需要完成哪些事情，做到什麼程度才可以往前。

流程一清楚，系統需求也開始跟著出現

當工作流程被整理成這樣之後，原本很抽象的「做一套案件進度管理工具」，開始變成比較具體的問題。

某個階段需要確認資料。

那系統就需要把使用者現在需要看的資訊整理出來。

某個階段需要留下處理結果。

那系統就要能保存這些結果。

有些條件完成之後，案件才能進到下一步。

那系統就要知道什麼情況下可以往前推進。

有些工作還沒完成。

那系統就不能只因為有人按了一個按鈕，就把案件當成已經進入下一個階段。

原本流程圖上只是「一格接一格」。

開始從系統角度看之後，每一格都會繼續長出：

要知道哪些資料？

要留下什麼？

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

案件現在應該被理解成什麼狀態？

我開始比較早看見系統需要做什麼

第一個產品時，我常常是先想到功能，再一路往下做。

做到越來越複雜之後，才發現系統還需要記住流程進度、處理不同條件和例外。

到了這個委託專案，我的起點已經不太一樣。

我可以先從整條人的工作流程，看見系統至少需要掌握：

案件現在在哪裡。

這個階段還有哪些事情沒完成。

哪些資訊需要被留下來。

什麼情況下才可以繼續往下走。

這還不是完整的系統設計。

但原本很模糊的需求，已經開始從工作流程裡長出比較具體的系統責任。

我開始能從「人怎麼工作」，比較快看見「系統需要知道什麼、管理什麼」。

而再往下一步，問題就不只是：

系統知道案件在哪裡了嗎？

還包括：

真正每天處理很多案件的人，打開產品之後，要怎麼知道自己現在該做什麼？