在剛進入業界時，我聽過一個小故事：
美國汽車生產線的最後幾道工序時，車門終於裝上了，總有工匠用著小木槌輕敲門沿，確認車門是否與車體緊密貼合，以確保車內安靜。
可是，眾所皆知的，日本車的隔音度是世界領先的，所以美國車廠的高層就前往日本參觀。
他們發現日本車廠完全沒有小木槌這道工序，可是車門卻緊密如一，美國的高階主管不禁疑惑地問，日本的生產線是在哪道程序去確保車門密合呢？
這時，日本車廠的導覽員略顯不好意思地笑著回答：
「就在設計車子的時候。」

另外一個故事，是我曾經遇見的一位客戶，他似乎飽受折磨地在尋求資訊廠商協助...
我詢問原委才得知：

在專案初期，開發商很快就提供了一個版本...
但這個版本並不全然合用，偶有突發狀況，可能是缺少了欄位，或疏漏了流程，都再進行增補。客戶提出問題，就立刻修改，再提再改，導致測試變成十分漫長的過程，最終還是完成上線了。
上線後，使用者發現問題，再提出，再修改，雖然功能日漸滿足需要了，可是效能也變得越來越慢...
承辦人會換，廠商也會換，使用者也可能失去耐心。
最後，大家就將就著使用。

這時，這位客戶找上我們，希望能提出新的改版方案。
我們足足花了前一家廠商「三倍以上」的時間進行重新規劃，甚至去客戶端駐點，體驗流程，了解客戶的工作與生活，不斷地提案、展示雛形、核對、演示...
可是我們的時程是相同的，代表我們開發和測試的時程徹底地被壓縮。
規劃的時間變長，承辦人當然會擔憂來不及上線。
最終我們只花了一個月撰寫程式，而且成功、平穩地運作到現在。

我們投資三倍的時間做規劃，卻為日後減少了十倍的時間修正。

美國車廠的小木槌，象徵許多專案開發的模式。碰到計劃以外的問題時，便高效率地採取一連串的補救措施，來達成冀望的結果。但這些補救真的安全、穩定嗎？
有太多的專案，最終都用小木槌解決問題，表面上看來，可能上線時的成果，似乎沒有什麼分別，甚至提早給予測試版本，或是訪談時間少一點，反而是客戶一開始希望的。

可是，有遠見的系統分析師知道，真正的成功是藏在不遠後的將來，所以他們會去揣摩那個還未到來的時刻，去模擬環境改變時的狀況，給予預留的調整空間。
客戶在委託的時候，其實就是希望你能想得更透徹，而非只是聽命行事，所以我們策畫的每個流程、佈署的每個環節、設計的每個介面，其實都源於一個起點：
「如果上線後，會如何？ 如果幾年後，會如何？」

因為，好的系統分析師了解：「永續服務，與客戶建立多年愉快的合作關係。」
是源自於能撐過時間考驗的設計，不是倚靠事後的調整和補救。