昨天說到，我花了三天把流程搞清楚，結果一次確認就多出一整段前置作業。
但那還不是最花時間的部分。
真正花掉我最多時間的，是流程圖確認完之後才冒出來的一堆問題。而且這些問題有個共同點： 它們都不是技術問題，而是規則問題。
我也是做了幾個自動化流程之後才意識到這兩者不同，之前只會當成是自己在畫流程圖的時候沒有考慮清楚這些細節。
流程圖畫出來的是步驟：誰做什麼、做完給誰，這些很容易就問得出來，因為大家每年都在做。
但自動化需要的是規則：什麼條件成立的時候，系統該做什麼，規則常常沒有人決定過，因為在手動時代，那些規則根本不需要存在，人資當下看情況處理就好了。
我舉幾個實際遇到的例子。
夥伴和主管各自填完之後，合併的結果要什麼時候寄出去？
一開始只有兩個選項在我腦袋裡：
等全公司都填完再統一寄。 進度一致、人資好掌握，但整條線會被最慢的那個人拖住。
誰填完就先寄給誰。 比較快，但主管會收到一堆零碎的東西。
後來我選的是第三個： 以「配對 + 統整」為單位放行。
系統每小時掃一次所有表單，然後看兩件事：
會這樣決定，是因為我花了一點時間跟一些主管進行訪談，在其中獲得了一些發現，我發現前面兩個選項都是站在 流程 的角度在想事情，但主管真正要的不是「一份分數」，反而希望也可以拿到「一組可以互相比較的分數」協助他判斷與確認。
所以放行的單位不該是「某個人填完了」，而是「能提供這位主管進行判斷的資料齊了」。
不寄，怕有人根本忘記；寄了，又怕變成沒人看的騷擾信。
最後的做法是每個階段最多提醒兩次，而且兩次是有差別的：
第一次是提醒，第二次是升級。
我覺得這件事蠻有趣的：「被人資知道」其實是一個壓力來源，而它只能用一次。如果第一封就 CC 人資，後面就沒有東西可以加碼了；同時如果從頭到尾都不 CC，那人資永遠不知道誰還沒動。
還有一個更有意思的決定：越上層的審核，提醒越少，最後乾脆完全不提醒。
流程表上那一關直接寫著「無提醒；主管須自行負責」。
會這樣決定，是因為人資表示越到後面的關卡，那封信的性質其實已經不是「請你處理」，而是「讓你知道」即可。上層當然還是可以改分數，但那一關的設計目的本來就不是為了讓他們改。
既然不是真的期待對方採取行動，提醒就沒有意義， 提醒的前提是你希望對方做某件事，而不是你希望自己盡到告知的責任。
這一條規則很有趣，我一開始根本沒想到這個問題。
是人資提出的，他說不要在下班時間寄信打擾大家。
所以我們才額外訂了一個規則： 所有定時批次寄出的信（提醒信、總表），只能在週一到週五的上班時間內發出。 但填寫者按下送出之後的即時回傳不受限制，隨時可以觸發。
這條規則跟程式怎麼寫一點關係都沒有，但它提醒了我 自動化雖然讓系統有了二十四小時行動的能力，但接收的那一端還是人，在設計時要考量到使用者體驗。
在討論這些細節的同時，我又收到一個新需求：在最後彙整那一關，主管會針對所有人的分數做一份分析。
我第一個反應是既然是分析，一定有某種規律，那應該可以讓它自動產生。
結果我問了一輪，發現沒有人知道那份分析是怎麼做出來的。
包括做的人自己，也說不太清楚。
我相信如果花時間一題一題訪問下去，還是有機會把那套邏輯拆出來。但當下我做了另一個判斷：
所以這一段的優先順序就被我往後放了。
接著討論就進到另一個階段：大家開始想到各式各樣的「那如果……怎麼辦」。
表單要不要讓人重複填寫？
不行的話，有人不小心填錯就送出了怎麼辦？可以的話，那要以哪一份為準？
類似的問題一個接一個冒出來，而且每一個聽起來都很合理。
剛開始我希望能滿足他們所有的例外情況，但漸漸的我發現 我必須先判斷這是真的問題，還是 nice to have。
因為例外如果全部都要涵蓋，整個系統會變得非常龐大，每多處理一種例外，就多一段邏輯、多一次測試、多一個未來可能壞掉的地方，但我當時手上只有不到一個月。
所以那段時間我做最多的事，其實不是寫程式，是篩選，哪些例外真的會發生、而且發生了會出事；哪些只是大家對於「萬一有人這樣做」的想像。
講到這裡可以回答一件事。
從人資把前置資料給我，到系統要對主管開放， 我真正動手寫程式的時間只有五個工作天。
前面那半個月，幾乎都在搞懂流程、跟人資來回確認、進行一些使用者訪談、等資料、還有討論上面那些問題。
所以如果要我形容這個專案，我大概不會說它是一個「寫程式的專案」，反而更像是一個把那些從來沒有人決定過的事，一件一件梳理完成的專案。
程式只是最後把決定好的規則寫下來而已。
iThome鐵人賽
看影片追技術