X14 做工作 vs 做學問

在職場工作一陣子後，都會發現湧過來的工作有如長江之浪一波接一波而來，有時甚至是好幾個浪一起打過來。除了要迅速完成各個交付項目之外，還要學習將每個交付項目切分為許多小階段，藉由多工處理各個小階段來讓每個交付項目都同時有完成的進度。

工作時滿腦子想的都是怎麼完成交付項目。我很同意聰明人（王文華）這篇文章裡所說的，“聰明人喜歡給解決方案，因為他們第二個特徵是凡事講求效率。”，快速地定義做到什麼程度叫做完成、同時定義出達到完成的最短途徑。例如前陣子在客戶端有個我負責的程式在換版本時發生問題，我希望在更新作法前與同事討論好各種可能的因應再換版，有人說直接放上去跑馬上就知道哪裡發生問題再繼續改，但是我顧慮客戶看著我們程式一直換來換去會有負面想法而堅持要先討論好。

用“效率”來看檢視程式碼檢查範本這件事，最適當的作法莫過於全部條件先打開後再根據眾人的意見調整，馬上可以開始用且很快就會有修正的回饋；這是強調建立初步雛型讓使用者體驗再改進的作法。不過在與理論型的Ｅ主管討論時，他認為規則範本定義的是標準，應該用最嚴謹的方式定義：也就是每一條規則都要明白後再決定要用或是不用！否則一個標準定義出去還修修改改的，會令人感覺很不舒服。

做學問就會像是Ｅ主管所說的那樣，面對一個交付項目就得找出與它相關的一切關聯並仔細地研究內容，同時註明參考與引用的出處，全部都弄明白後再根據數據來分析歸納出客觀的結論。在工作上一方面因為時間就是金錢，另一方面因為客戶要求的標準就只有那樣，所以很自然地就先找出最短的捷徑交出去，再視實際進行的狀況補上缺漏的部分；在經驗不足或考慮不周時，就常會發生被客戶指正的現象。

能把工作做到像做學問那樣通盤瞭解算是遙不可及的夢想吧？在快速提供解決方案的同時，我們還應該明白單憑個人的想法總是會有缺漏的地方，在溝通與討論中運用團隊的智慧補齊原先設想的不足，儘可能一次就交出設想完備的作法會是減少多次修正與增加客戶信賴的正途。