先後順序，才是最大的風險

開賣前夕，我們搞錯了順序

開賣前最後一週，有兩件事同時壓著我們。

第一是使用者流程。整個系統使用流程是我自己畫的，但在來回溝通、修改了兩三次後，不只是 UI/UX 的呈現，連功能邏輯都需要重新梳理，最後還是靠設計師介入才收尾，整個延期超過一週。

事後回頭看，問題並不是設計師不配合，而是恰恰相反：設計師太忠實地照著我們的草稿執行，反而產出了一些在實際使用上不順手的流程與介面。

幾次來回之後才意識到，和專業者溝通有兩個層次，而且順序不能搞反：

• 第一層：讓對方理解我們的期待、設計思維與整體概念
• 第二層：才是展示我們的草稿或可能的方向

先給草稿、再補概念，設計師會按圖索驥；先給概念、再看草稿，設計師才能用自己的判斷去修正和補足，並且還要明確說出，這是我們目前的想法，需要你的專業優化到適當的程度。即便是我們相對熟悉的系統設計，這個順序同樣適用。

第二是金流串接。這個問題複雜許多：要讓消費者成功付款，不只有刷卡，還有電子發票，以及跟金流商之間的串接驗證、內部的財務對帳都要完整。期中許多環節都需要金流商先提供文件，我們照著測試，有問題再等對方回應，開發的期程，有將近一半不在我們的掌控內。

等到真正開始實作金流時才發現，光是等待對方回應、解釋文件，時間又多出三四天。即便事前抓了一到兩週的 buffer，最後還是幾乎到了預計開幕日前兩天，才確認整套系統可以正常運作。

這兩段延誤，根本原因都不是預估出了錯，而是溝通和優先順序安排的問題。

兩種不同的「順序錯誤」

同樣是拖了時間，這兩件事的問題性質並不相同。

User flow 的延誤，根本原因是溝通順序：我們把草稿放在了概念前面，讓設計師按圖索驥，導致前兩次產出都需要大幅調整。這是一個在合作開始時就能修正的事。

金流的延誤，根本原因是執行排序：我們把最不可控的項目留在了最後。它的每一個驗證步驟都依賴外部廠商，一旦出問題，能做的只有等，而我們要到真正開始實作時才發現這件事。

兩者都可以被更早解決，只是卡住的地方不同。

用第一性原理重排準備清單

如果重來一次，我認為開賣前的準備清單應該先問兩個問題：

1. 哪些項目是不可控的？ 依賴外部廠商、需要等待驗證、自己無法加速的。
2. 哪些項目是開賣的硬性前提？ 少了它，其他所有準備都是白費。

同時滿足這兩條的項目，應該最優先啟動、最早確認。

金流是一個典型：既不可控（完全依賴外部），又是硬性前提（沒有金流，根本無法開賣）。這樣的項目，應該在準備期一開始就進入確認流程，而不是和其他項目「同步被測試」。

相對地，可控的項目可以晚一點、也可以精雕細琢，反正節奏在自己手上，隨時能調整。兩者的排序，應該先由「不可控且關鍵」的決定，其餘的填進空隙裡。

而溝通順序的問題，同樣是一種「先確認什麼」的排序邏輯：先確認對方對目標的理解，再進入具體方案，比反過來要省更多力氣。