先問流程，再問功能

第一次和企業聊系統的時候，最常拿到的是一份功能清單。上面寫著「要有登入」「要有報表」「要有通知」。清單本身沒有問題，問題是它通常是從別人的系統抄來的，而不是從自己的流程長出來的。

所以我們現在習慣先把功能清單放在旁邊，改問另一組問題。

先問的三件事

這件事現在是誰在做？

不是「哪個部門」，是哪一個人。找到那個人，通常也就找到了所有的例外狀況。

他現在用什麼做？

答案很常是 Excel、LINE、紙本，或是三個一起。這不是落後，而是資訊。它代表現有工具至少在某個地方是好用的，不然不會活這麼久。

做錯的時候會怎樣？

有些環節做錯只是重做一次，有些做錯會直接影響出貨或收錢。這個問題的答案，會決定哪裡需要防呆、哪裡可以放寬。

功能清單的問題

功能清單描述的是系統，流程描述的是人。兩者之間往往差了一段沒有人記錄下來的東西：

• 那個「先傳照片到群組給主管看一下」的步驟
• 那個「星期五下午單子會特別多」的節奏
• 那個「新人前兩週都會做錯同一件事」的現象

這些東西不會出現在需求文件裡，但它們決定了系統上線之後會不會被繞過。

一個實際的例子

有一種很常見的需求是「我要一個報表系統」。

如果直接照做，結果通常是一個有很多圖表的頁面，然後三個月後沒有人打開。

但如果先問「你做這份報表是為了回答什麼問題」，答案可能是「我只是想知道這週有沒有哪一天特別忙」。

那麼需要的可能不是報表系統，而是一個每週寄一次、只有五行字的信。

這兩件事的開發成本差了不只十倍，而後者比較有機會真的被看。

流程問清楚之後，功能反而好決定

把流程攤開之後，功能清單通常會發生兩件事：

1. 有一半的功能會被刪掉，因為它們解決的是不存在的問題。
2. 會冒出兩三個原本沒寫的功能，而且它們才是真正的重點。

這個過程不需要很久。多數情況下，把一天的實際工作走過一次，大概兩個小時就夠了。

比起花兩個月做一個沒人用的系統，這兩個小時很便宜。