計畫!計畫!計畫!

最近有好幾次的機會接觸到所謂"看現在(看短)"或"看未來(看長)"這個議題，似乎每次討論的方向與結論都是兩者總是互相排斥。最常見的情況是，只要提到計畫或基礎性的工作(以我從事的軟體開發產業來說，就是一些軟體工程的事項)，就會被扣上"看未來"的帽子。"看未來"這個帽子表面上美其名是表示具有長遠的眼光，但是骨子裡說的卻是這是完全不切實際的想法。公司都已經面臨生死關頭了，還在跟我談計畫、談軟體工程，你真是白目到不行。在許多人(老闆)的心理，這些事情不但無助於解決眼前的困境，甚至對未來有沒有助益都是很大的一個問號。

天啊，現在與未來怎麼會是互相排斥的呢？短期目標不就是為了長期目標的達成嗎？好啦，我知道很多企業根本沒有明確的長期目標。即使單就短期目標來看，計畫與看似無立即價值的基礎性工作，其實同樣扮演了相當重要的角色。當然，對一個一年後的目標，與對一個月後的目標，採用的計畫方式將會有很大的差異。除了計畫方式有所差異，因為執行期長短的不同，所以可以進行哪些基礎性的工作也會有所不同。不過不管目標長短，基本上原理都是一樣的：進行計畫，在計畫過程當中找出最具危險性的事情並擬定因應之道。如果你學過專案管理，就知道我在說什麼，這正是風險管理的精神啊。最有趣的點在於，這些因應之道往往剛好就是那些被視為無立即價值的基礎性工作。很難想像嗎？就像我們常說老祖宗的智慧，而這些流傳以久的基礎性工作就是前輩的智慧，自有它存在的價值。

很多老闆(尤其是那些能力強、積極性高的老闆)在面對短期目標時，喜歡套用先搶一步的做事態度。計畫？那是什麼鬼東西！基礎性工作？你是開玩笑的吧！

想像下列的情境，在某次預計展示 Windows 2050 的 Microsoft 發表會當中，正當 Bill Gates 在口沫橫飛地講解 Windows 2050 有多神奇時，如大家所預期地出現了 BSOD。以 Bill Gates 身經百戰的經驗，當然也知道重開這個大絕，所以就在 Bill Gates 的尷尬談笑當中，Windows 2050 順利重新開機並撐過了此次的展示。但是，問題沒有結束，因為地球聯邦軍已經訂了五億套的 Windows 2050，而交期是一天後！如果違約的話，Microsoft 不但拿不到一毛錢，甚至必須賠償地球聯邦軍一百億元。一百億元對 Microsoft 而言僅是九牛一毛，但是如果 Windows 2050 隔天不能交付，那麼地球聯邦軍就會全部帶上那個討人厭的小紅帽，而這才是 Bill Gates 真正無法容忍的事情。所以 Bill Gates 要求 Microsoft 的全體員工(是的，全部，包含掃廁所的王大媽) 開始"動手"解決問題。Bill Gates 要求馬上聽到要怎麼改，要改哪些源碼，才能夠解決這個問題。好啦，我也知道小紅帽真的很顧人怨問題真的很緊急。儘管電腦不像女人那般難以理解，但是電腦卻是笨到沒辦法告訴我們它為什麼會出現 BSOD。所以呢，我們必須抽絲剝繭去找出可能的原因。怎麼辦？抽絲剝繭需要計畫，讓包含王大媽在內的所有員工一起解決問題也需要計畫。但是 Bill Gates 是行動狂，所以要求大家馬上動手。下場如何...地球聯邦軍終於知道小紅帽其實還挺好用的，更不會出現那個無趣至極的 BSOD。

是的，當情況推到極致時，就是在面對所謂的緊急狀況時，這類老闆就會要求大家即刻動手，任何動腦、動口的事情都只是浪費時間，任何與問題無直接相關的事情都是罪惡至極。相信我，即使是這麼緊急的短期目標，同樣需要計畫，同樣有可能需要一些看似無直接助益的基礎性工作。甚至，對越緊急的目標而言，計畫就越重要，基礎性工作的幫助也就越明顯。當然，前提是你確實知道如何做計畫、也知道哪些基礎性工作是最有效益的。後者需要仔細審視現存的最佳實務 (Best Practices)，找出適用於自己處境的項目，並小心地加以導入。如果不這樣做，不但可能無法達成目標，甚至可能引發(更大的)災難。有人會說，我們已經具備很好的基礎，根本就不需再增加這些多餘的項目。嗯，對於這類人，我勸你先搞清楚風險管理再說這句話。這跟基礎性工作本身沒有關係，而是根本沒有專案管理的概念。好啦，我知道有更多的人對專案管理嗤之以鼻，那我只好選擇跟那些人揮揮手，並在心理等著看好戲祝福他們。或者有人會說，我怕導入錯誤的最佳實務，如此一來豈不是讓問題更加嚴重，所以以不變應萬變才是最保險的作法。對此，我沒辦法反駁你，因為確實有可能因為導入錯誤的最佳實務而達到反效果，但是我腦中同時也浮現了"因噎廢食"這個令人深思的寓言故言。

如果你還是不相信，希望我親身的經驗可以讓你有不同的想法：

寫程式的人通常很怕一件事，那就是維護別人的程式，用如履薄冰這句成語還不足以形容那種令人膽顫心驚的程度。所以，如果情況合適的話，有時候重新來過會好於一再的修修補補。但是，真有這樣的機會，情況就會一帆風順嗎？那倒也未必。雖然重新來過在技術上可能是較佳的解決方法，但是對公司而言，重新來過只獲得同樣功能的系統，那可就不是那麼讓人愉快的抉擇了。

我在第一份工作時，公司原有網站系統採用 Perl + Oracle 的組合。為了簡省資料庫成本與日後維護便利性的考量，我提議全面改用 PHP+MySQL。公司接受了，問題是只有三個月左右的作業時間。對當時的團隊成員而言，PHP 是陌生的程式語言，如何做才能夠順利完成著實困擾著我們。再加上公司當然不會讓整個團隊做三個月的”白工”，所以自然還要加上一些新功能，更增加了我們所需進行的工作量。對此，我們當時採用了下列的作法

1. 先取得公司的認同。因為 Oracle 的支出成本一向不低，所以可以當做一個很有力的說服點。
2. 限制原有功能的修改。將公司想要修改的部份侷限在新增的功能上，而原有功能則不予以變動，如此可以大幅減少不必要的干擾。而且在等待新功能規劃完成的同時，我們可以全力進行技術的熟悉與舊功能的改寫。
3. 制定寫作規範。為了讓日後的分工執行更加順暢，我們先制定了所謂的寫作標準。這樣的作法可以讓日後相互的支援變成可行的事情。
4. 先完成共用元件。除了制定寫作規範，我們還先完成可以共用的功能元件，以減少不同人員間重複開發的時間浪費。
5. 戰鬥室 (War Room)。雖然當時我們部門的辦公環境還算不上是真正的戰鬥室，但是因為屬於一個獨立的空間，所以平常作業時我們會將門關上，以隔絕外界的干擾。此外，當時大家都面對牆壁而坐，所以一轉身就可以跟所有人進行討論，大幅增加溝通的時效性。
6. 完成獎勵。其實當時給的獎勵並不高，而且不是金錢上的獎勵，但是你知道的，有時候禮輕情意重 (話說回來，如果一直都很輕，那可就不好了)。

在團隊成員的一起努力之下，整個計畫最終順利完成。不但達成這個專案的目標，也確實做到了降低成本與增加日後維護效率的策略性目標。希望我個人的經驗可以提供你一些不同的想法，並對你的工作有所幫助。

Hacking 領導者 (1)

雖然”快”是現在商業環境的特性與要求，但是快的本質並不在於先跑，而是先到達終點。很多時候，先靜下來想好策略後再動作，反而能產生更快又更好的結果。但是千萬也別讓計畫的思考給困住了，以免錯失良機。

Hacking 領導者 (2)

不管是長期或短期的目標，都必須制定計畫。當然，越長期的目標，通常也必須花費更多的時間進行計畫。而計畫過程當中很重要的一個步驟就是找出將發生(或可能發生)的問題，並採取因應之道。相信我，這些解決之道通常就是那些被稱為只"看長"的基礎性工作。這些工作既然存在著，就表示它確實能夠解決問題，前提是你要能夠正確地加以運用。