為什麼在最開始，就全力投入？

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

另外一個故事，是我曾經遇見的一位客戶，他似乎飽受折磨地在尋求資訊廠商協助...
我詢問原委才得知：
在專案初期，開發商很快就提供了一個版本...
但這個版本並不全然合用，偶有突發狀況，可能是缺少了欄位，或疏漏了流程，都再進行增補。客戶提出問題，就立刻修改，再提再改，導致測試變成十分漫長的過程，最終還是完成上線了。
上線後，使用者發現問題，再提出，再修改，雖然功能日漸滿足需要了，可是效能也變得越來越慢...
承辦人會換，廠商也會換，使用者也可能失去耐心。
最後，大家就將就著使用。

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

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

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

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

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

在提案時，我們會依過往經驗建議作法，甚至以過去分析的數據推測日後的結果。
分析競品、找使用者進行可用性測試、A/B測試，追蹤行為回饋... 等等。
並透過栩栩如生的雛型，讓客戶能實際體驗未來的想像。
這一點也不浪費時間，反而有助於未來工時的減少，創造出長久成功的系統。

分析的過程，實際上應該從「為什麼 ( Why )」開始思考，接著才是「怎麼做 ( How )」和「做什麼 ( What )」。如果，只是告訴客戶「做什麼 ( What )」，而不清楚「為什麼 ( Why )」而做，就很難設計成功，只能淪為追隨者。
所以，模仿容易，創新難。越是參考流行作法，而非透過自身和客戶的經驗思考，所開發出來的網站系統，就越不容易吸引客群，只能不斷增修補強。

我們每次接受委託時，都會不斷的問自己：「為什麼？」
為什麼這世界需要這個網站、這個系統、這個APP？
能帶給別人什麼樣的不同？

回到最初的想像，莫忘初心，就能創造不凡。