Day 4 我寫過，搞懂流程是專案裡最簡單的部分。

那句話要補一個前提，我講的是「把流程畫成圖」那一段，那確實不難，聽完一輪訪談就大概能畫得出來。

難的是另一半，怎麼知道我畫的那張圖符合實際情況？

我不是會計，不是倉儲，也不是採購，別人的工作我沒做過一天，所以我只能用問的。

但是......

他們告訴我的，跟實際發生的，中間有五種落差

這幾個月下來，我遇到的落差大概可以分成五種。

他講的是理想版本。 問一個人「你平常怎麼做」，他會描述一個順利的流程，一二三四五。那是他希望自己在做的事，也是他能一口氣講完的版本。

他忘了自己訂的規則。 這個我在 Day 12 寫過，會計跟我說過一條規則，我照著做，幾個月後他看到結果覺得奇怪，但那條規則是他自己提的。這代表兩件事，一是人不會記得自己三個月前的決定，二是在下規則時，不一定能準確判斷實際情況。

他沒提到的是例外，而例外是大部分的工作。 正常的單子他兩秒鐘就處理完了，所以在他的印象裡那不算工作。他每天真正花時間的，是那些不正常的。但你問他流程，他講的是正常的那條。

他說的需求不是他要的東西。 Day 13 寫過，業務說他想知道客戶欠多少錢。做出來之後才發現，他真正要判斷的是這一個訂單能不能出貨。

他做了一些他不知道自己在做的判斷。 Day 18 寫過，填單的人不會說「我按完要再按一次 End 才能留住負號」，他只是看到負號不見了，手指自己換了一種打法。

這五種落差的成因都不一樣，而且沒有一種是我在訪談當下發現得了的。

所以我做了兩件事，一是換問法，二是不再只靠問。

換一種問法

我除了問「你平常怎麼做」之外，我現在會多問這幾個問題。

上一次出錯是什麼時候。 這個題目可以讓對方講出一個很具體的故事，而那個故事裡會出現五個他剛剛描述流程時沒提到的步驟。

如果這一步沒做會怎樣。 這一題問的是用途，不是動作。有時候答案是「不會怎樣」，那這一步可能會是個多餘的步驟，不過有時候答案會是「那下一關會找不到資料」，那我就知道這一步主要的目的是什麼，有時候他們原先的步驟對自動化來說不一定是最有效率的，當我能知道他的目的時，我就有空間能重新設計流程。

有沒有哪一次你覺得這個流程很難用。 這一題會釣出情緒，而情緒的位置通常就是流程斷掉的位置。沒有人會對一個順的流程有情緒。

這個數字你是從哪裡抄過來的。 問任何一個欄位的來源，常常會挖出一個我完全不知道存在的檔案。

但問到底還是不夠

就算問法改了，我拿到的東西本質上還是一份口述。

它會漏、會美化、會把三個步驟講成一個。

而我真正需要的是一份規格，規格要精確到每一個分支、每一個例外、每一個「如果沒有的話」。

這兩個東西之間的距離，不是多問幾次就能補上的。

所以我後來的做法是，先做一個不完整的版本給他看。

這就是我標題想講的事。我做 demo 從來不是為了展示我做了什麼，也不是為了讓大家覺得我很厲害。

我做 demo 是為了讓他說出那句「不對，這裡應該要......」。

一個人看著空白的會議室講自己的流程，他講的是記憶。一個人看著一個做錯的畫面，他講的是實際情況。

那些他想不起來的規則、沒提到的例外、不知道自己在做的判斷，全部會在看到錯的那一刻跳出來。

因為人對「錯」的敏感度，遠遠高過對「對」的描述能力。

早一點錯，就能早一點取得資訊

想通這件事之後，我對 demo 的態度整個變了。

以前我會想把它做得完整一點再拿出去，怕被說做得不好。

現在我會盡量早點提供，而且故意留著我不確定的地方，因為那些不確定的地方就是我要想釐清的問題，與其用文字問他一次，不如直接做一個版本讓他看到。

一個做錯的 demo，比一場做對的訪談有用。

Day 2 我畫過一張流程圖，裡面有一個迴圈，從 demo 繞回訪談，當時我希望這個迴圈可以越少次越好。

現在我的想法不一樣了。那個迴圈不是因為我第一次沒問好，是因為上面那件事，有些答案只有在他看到錯的東西之後才會出現。 那不是補救，它是取得重要資訊的一種管道。

不懂，反而幫了我

最後講一個我一開始覺得是缺點的東西。

我沒有會計背景，所以我會問一些很基本的問題，這張單為什麼要兩個人簽？這個欄位為什麼不能是空的？這個值是怎麼算出來的？為什麼一定要先做這一步？

做了十年的人不會問這些，因為對他來說那是常識，就跟呼吸一樣，大腦不會去仔細思考要怎麼呼吸。

而我每次問這種問題，大概有三成的機率會得到一個很有意思的回答，

「對耶，為什麼？」

那個「對耶」後面，常常就是一段沒有人再檢查過的流程。

所以我的不懂反而是一個能重新思考流程的契機。