昨天寫，我不能因為 AI 給了一個完整的解釋，就把它當成確認過的事。
今天換一個方向來討論。
如果那個答案最後被我寫進系統，別人開始照著它做，那我是憑什麼決定它的？
我沒有管理職權。但做流程自動化時，有很多決定，會直接影響別人怎麼工作。
哪些資料沒齊就不能往下走、出錯時哪些通知要停、什麼時候可以把結果交出去。這些看起來都像系統設計，可是用的人碰到它們時，感受到的就是規則。
前面寫過，會計來找我的需求是「幫我把報表做出來，把審核跑完」。
這句話很清楚，但還不足以讓系統直接開始跑。
少一份來源檔怎麼辦？找不到某個人的信箱怎麼辦？其中一個寄信步驟失敗，其他通知還要不要寄？
程式走到那裡，總要有一個處理方式。我得把它補出來。
麻煩就在這裡。有些只是決定資料怎麼讀，有些卻會決定誰要等、誰要多做一次、誰收不到原本該收到的東西。
如果我把它們全部當成實作細節，就很容易在做功能的時候，一起把別人的工作方式決定了。
人資考核有一個我做過的選擇，什麼時候把評分結果寄給主管。
等全公司都填完再寄，進度一致，但已經完成的人要一起等。誰填完就寄，速度比較快，主管卻會陸續收到零碎的資料，人資也要追不同進度的人。
後來我選擇以主管和所屬夥伴的配對為單位。主管完成所有下屬的評分，先收到自己的給分總表；等這位主管和他的下屬都完成，再收到包含自評的更新版。
Day 5 寫過，這樣做是因為主管需要一組可以互相比較的分數。
但今天回頭看，我想追問的是另一件事。這個理由能說明我為什麼提出這個做法，還不能替每個人回答，他願不願意接受這樣的等待。
同一組裡有人還沒填完，其他人的完整結果就要等。這是設計本身會帶來的後果，不能只因為我找到了一個合理的理由，就把這一面省略。
我選擇讓系統在哪個條件下放行，也就決定了誰要等誰。
所以拿去討論的時候，得把兩面都講出來。這樣能讓主管一次比較完整資料，也會讓同一組的人互相牽動進度。需要確認的是這整個選擇，不能只看得到它方便的那一面。
但如果把前面那些決定全部說成是我自己訂的，也不準確。
專案文件裡有一張表，記著每條規則、為什麼這樣定，以及誰拍板。把它翻出來看，才發現有些看起來很大的決定，來源其實很清楚。
信用儀表板裡，風險先看超額，再看嚴重逾期、需要追蹤，這個順序是會計訂的。
我的工作是把它做出來，確認判定和顯示符合這個順序。不能因為另一種排法比較好寫，就自己換掉。
已用額度也是。我曾經照需求方提供的項目去算，後來對帳才發現跟 ERP 的公式不同，最後選擇對齊 ERP，另外顯示不納入的那一項，再回頭解釋差異。
有些決定因為長得像技術細節，很容易在實作時就被決定了。
這裡面其實有幾種不同的事。已有的規則要弄清楚，互相矛盾的規則要把差異攤開，沒有說明的地方才需要提出做法。
如果沒有先分清楚，我可能會把需求方已經決定的事當成自己可以改，也可能把自己的推測誤寫成原本就有的規定。
昨天那份 AI 筆記就是一個提醒。一句話被寫下來之後，很容易失去它原本的身分。放進系統裡也一樣，使用者不一定知道這條規則是誰提出的、為什麼會在這裡。
我不是完全沒有找人確認。
前面寫過，我會把流程圖拿給需求方看，也會做 demo、串真實資料，請他們協助驗證。
但 Day 9 我也寫過，工程師會看程式，很多流程上的判斷，卻很難找到人一起檢查。
這兩件事可以同時發生。有人看過畫面、確認過數字，不代表他已經看見藏在某個錯誤處理裡的選擇。
如果 demo 演示的是資料完整、信箱都找得到、每一步都成功的情況，那些「缺了怎麼辦」的規則就不會出現。
我不能因為正常流程被看過，就覺得異常時的處理也一起被同意了。
這是我現在想補得更清楚的地方。拿去討論時，要讓對方看得到我到底做了哪個選擇，以及另一個選擇會有什麼差別。
像寄信那個例子，要確認的就不只是一個按鈕能不能寄。還有催款信失敗時，總表繼續寄會不會影響判讀，沒寄出的部分又由誰接手。
宅配判定也是。要讓對方看到兩種判法會把哪些單放到不同清單、後續處理有什麼差別，才有辦法確認要不要改。
這些才是會影響他工作、需要他一起判斷的事。
如果每個地方都等別人先給我一條完整規則，專案很難往前走。很多需求就是看到東西之後，才會發現原來還有這件事要決定。
所以我還是會先提出做法。
只是提出時，我希望能分清楚，哪些沿用現有規則，哪些有資料可以支持，哪些是我暫時選的方式。
最後那一種，尤其需要把代價講出來。
要等資料齊了才跑，就得說誰會跟著等。要讓其他工作先繼續，就得說哪些例外還沒做完。要留一個步驟給人確認，就得說清楚那個人究竟要確認什麼。
這樣需求方才有機會說，這個等待不能接受、這一段我可以接，或這件事需要再找誰決定。
我也不能把「沒有收到反對」當成已經確認。也許對方還沒碰到那個情況，也許我根本沒有把選擇說清楚。
確認之後，也要把理由留下來。那張表記著誰拍板，我還想讓它說得清楚，當時是在什麼條件下選的，以及哪些影響已經確認過。
像宅配判定，留下「維持既有分流口徑」這個理由，以後追款流程改了，就知道值得重新比較兩種做法。只寫「沿用原規則」，下一個人可能又得從頭猜。
寫下來不能代替確認，但能讓之後要改的人，知道該從哪裡重新問起。
寫到這裡，我沒有辦法用「因為我做過幾個專案」來回答。
做過的經驗可以幫我提出比較完整的方案，但不會自動讓我知道別人能接受多少等待、多少人工處理，或承擔什麼後果。
我能做的，是把判斷的依據和影響一起拿出來，讓真正要照著做的人有機會確認。碰到超出他能決定的範圍，再把問題往上提。
我有把規則寫進去的能力，不等於我有資格替所有人決定它。
下一次要補上一個流程條件時，我想多問自己一句，這是原本就有的規則，還是我剛剛替大家做了一個選擇？
iThome鐵人賽
看影片追技術