WORK STORY / 02
在複雜流程與浮動標準中釐清交付邊界
情境
BTSE 的開發流程同時牽涉 PD、PJ、Designer、Backend、QA、Frontend，以及不同環境、Code Review、QA 驗收與 Release 等多個節點。流程本身並非沒有規範，真正困難的是大量例外、前提與責任邊界仍依賴人的經驗與記憶。不同角色對同一張 Ticket 的需求、實作範圍與完成條件，也可能存在不同理解；部分判斷標準甚至直到接近交付時才浮現。對負責實作的工程師而言，真正困難的不只是把功能完成，而是確認現在大家認定的「完成」，究竟是不是同一件事。
我的判斷與做法
我開始改變自己的工作方式。開發前先盤點需求涉及哪些角色與系統，主動確認預期行為、前後端責任與可能受到影響的範圍；遇到無法單靠 Ticket 判斷的部分，就透過既有程式行為、相關文件與不同角色交叉確認。針對共用模組的修改，我也會進一步整理可能受到影響的品牌、頁面與功能，提供 QA 作為測試範圍。我的目的不是增加更多流程，而是盡可能在資訊還能被確認的時候，把不同角色腦中的答案攤到同一個平面上。
形成的結果
這沒有改變整個 BTSE 的開發制度，但改變了我處理複雜協作問題的方法。我不再只把「功能寫完」視為完成，而會同步確認需求認知、修改影響、責任邊界與驗收範圍。這也讓我更早辨識一些真正的交付風險，包括 QA 驗證的版本與 Code Review 後準備上線的版本可能已經不同，以及完成標準可能直到開發後期才重新被定義。
留下的思考
這段經驗讓我開始對「依賴人記憶運作的工程流程」保持高度警覺。當一套系統複雜到工程師必須記住大量隱性規則，又可能在接近交付時才得知另一套判斷標準，問題就不再只是個人有沒有問對問題。工程師不應該靠猜中誰腦中的答案，才能證明自己把事情做對。我後來更在意的，是如何讓需求、技術影響與驗收依據留下足夠清楚的事實，避免資訊落差最後只變成對執行者的責任歸因。