替專業領域做系統:代書工作流數位化學到的事
地政士事務所的本質是「代理權利變動程序」加「安全保管撥付價金」。把這句話翻譯成資料結構,是我們對「領域 know-how × 工程」最完整的一次練習。
這是一套給地政士事務所全所使用的雲端案件管理系統:所長、代書、助理、會計、業務,加上外部客戶,七種角色。它要取代的是人腦追蹤數十件案子的流程時限、用試算表對帳的履約保證金流,以及一遍遍重打的文書。
動工前,設計總綱的第一段不是功能清單,而是一句對事務所本質的定義:代理不動產權利變動的程序,並安全保管與撥付價金。系統的三支柱——進度引擎、金流引擎、文書引擎——全部從這句話推導出來。以下是把領域知識翻譯成程式的過程中,最值得記下的幾件事。
流程不能寫死,因為專家說「看案子」
一開始我們想像的是四個固定階段。領域顧問的第一句話就推翻了它:買賣、贈與、繼承、抵押設定、塗銷……九種登記原因,流程各不相同。
所以階段不寫在程式邏輯裡,而是宣告式的範本資料:每種案型對應一組階段鍵,總共十二種。應備文件也一樣——十五類文件、六種繳交狀態,每種案型有自己的清單,並且勾稽到特定階段(賣方的印鑑證明,勾在「用印」那一階段)。
範本化帶來一個新風險:清單可能勾到該案型根本不存在的階段,形成永遠不會觸發的死關卡。我們寫了一條不變式檢查,由測試守住。而「文件不齊能不能完成階段」這件事,預設是軟警示,一個環境變數就能切成硬閘門——擋不擋是政策,政策交給領域專家決定,工程只負責讓它可切換。
錢對不上,信任就崩潰
履約保證專戶是整套系統最敏感的地方。設計原則只有一條:餘額是衍生值,不可直接編輯——它永遠等於所有已結清的入款減出款。撥款走「草稿 → 待核 → 已核准 → 已結清」的狀態機,核准權限只給會計與主管;出款時在交易內鎖住專戶並重算餘額,防止兩筆撥款並發造成超撥。
更有意思的是測試怎麼寫。我們蒐集了二十七條真實發生過的糾紛與詐騙情境——先移轉後付款、承辦人挪用、賣方原貸款未清就撥尾款——把它們寫成斷言:超額撥款必須被擋、助理按核准必須拿到 403、代償必須先於尾款。報告裡也誠實記著目前的缺口:身分驗證目前是紀錄,還不是撥款的硬閘門。
法規與表單的形狀,決定資料的形狀
- 全系統內部只存 ISO 日期,只在介面層轉成民國年——民國年是顯示格式,不是資料格式
- 點交費用分算依「買方自過戶日起」的行業慣例:先算買方並四捨五入,賣方等於年額減買方,保證加總零漂移
- 不動產標的欄位直接對齊政府開放資料的欄位字典;但我們明確區分「對齊開放資料」與「可送件的申報格式」是兩件事
- 登記申請書的套印,檔頭註解寫得很清楚:近似版、非像素複刻,供地政士覆核簽章
最後一點是刻意的界線:系統做到哪裡、專業判斷從哪裡接手,寫在程式碼裡,而不是留在口頭。
做錯過的兩件事
規模測試跑到三百多件案子時,發現分頁的排序缺少唯一的決勝欄位,翻頁會重複或漏掉——四處根因一起修。另一個是資料表早就設計了「當事人可連結到客戶主檔」,但 API 一直沒開放,導致無法推導「這位當事人是否完成身分驗證」;是情境測試逼出了這個缺口。
誠實的現況
這是一個文件完整、驗證腳本齊全(五十九項全功能驗證、二十四條情境斷言、十八條使用者旅程)的成熟原型,約六天完成;政府與銀行的整合目前以模擬介面為主,還沒有真實事務所上線的紀錄。
我們把它寫出來的原因,和其他幾篇一樣:那九種案型的流程、二十七條詐騙情境、點交分算的慣例,全部來自懂這一行的人。工程團隊的價值,是把它們變成範本、狀態機與測試——變成一套不會忘記、不會算錯、可以一直改的東西。
想聊聊你的產品想法,歡迎來信。