邊開火邊移動 Fire And Motion

我總會有時候什麼事都做不了。

我當然還是會去上班，不過卻是到處閒逛，每10秒就收一次信，逛逛網站，甚至做些付信用卡帳單之類不用動腦的事。什麼都做就是沒法子進入狀況回來寫程式。

這種不事生產的毛病通常一發作就是一兩天。不過在我職場生涯中也曾有過幾個星期沒有產出的情況。就像別人所說的一樣，我沒有進入狀況。我定不下心來。我不知道自己在幹啥。

每個人的情緒都會波動；有些人波動較少，而其他人會比較明顯甚至完全失常。不過無生產力的時期似乎和憂鬱情緒有關。

這讓我想到，有些研究者聲稱人基本上是無法控制自己吃什麼，因此節食絕對不可能持久，最後一定會回到自然的體重。或許對身為軟體開發人員的我來說，同樣無法控制自己的生產力，只能接受自己有時快有時慢，並且祈禱平均起來的生產力還能讓自己不會失業。

真讓我受不了的是，從我做開發工作以來，平均每天只有兩三個小時能有效率地寫出程式。當我暑假在微軟實習時，另一個實習生告訴我他每天只有12點到5點在做事。做五個小時(還要扣掉午餐時間)的事，而他的小組卻很崇拜他，因為他的成果還是比一般人多很多。我也發現一樣的情形。當我發現大家都非常努力工作，而每天只有兩三個小時效率的我卻還是組裡產出最多的人，不禁令人有點內疚。這或許就是 Peopleware 和極限程式作業(XP，eXtreme Programming)堅持不加班而且每週只應工作40小時的原因吧，他們很確定這樣並不會降低團隊的效率。

不過一天「只有」兩三小時有工作並不是問題，真正困擾我的是那些什麼都沒做的日子。

這件事我想了又想。我嘗試回想我職場生涯中最有效率的時候。極可能是在微軟把我放到一間漂亮豪華的新辦公室，裡頭有著如畫般的大片窗景(美麗的石頭庭園，裡面滿是盛開的櫻桃樹)。那時候每件事都很順利。在幾個月內我馬不停蹄地寫出 Excel Basic 的詳細規格，非常厚的一份文件，鉅細糜遺地敘述一個龐大的物件模型和程式開發環境。過程中完全沒有停頓。有一次不得不去波士頓參加 MacWorld，我還是帶著手提電腦坐在哈佛商學院的漂亮陽台上，繼續寫著視窗類別的文件。

當你進入狀況後，要繼續維持並不算太難。我的一天通常都是這樣子的：(1) 上班 (2) 看信看網頁等等 (3) 決定應該吃過午飯後再做事 (4) 吃完午飯回來 (5) 看信看網頁等等 (6) 終於決心該開始幹活 (7) 看信看網頁等等 (8) 再度下定決心真的該開始做事 (9) 把該死的編輯器叫出來然後 (10) 不斷地寫程式直到突然發現已經下午7點半了。

第8步和第9步之間似乎有點問題，因為我不是每次都能順利跨越鴻溝。

對我來說，要開始本身就是唯一的難題。靜者恒靜。我腦袋裡有些東西重得不得了，很難很難加速，不過一旦全速運轉就不必費心維持。就像要騎車來一趟橫跨美國的自助腳踏車旅行一樣。當你騎上車要開始時，根本無法想像要花多少力氣，不過一旦開始騎就發現實在是輕而易舉。

或許這就是生產力的重點：開始做吧。或許配對程式作業所以有效，是因為把兩個人排在一起作業，自然會強迫彼此開始。

當我還在以色列當傘兵時，有位路過的將軍給我們講了一小段關於策略的課。他告訴我們，在步兵作戰時只有一種策略：邊開火邊移動。你要一邊開火一邊朝敵人挺進。開火讓敵人抬不起頭，不能向你開火。(這就是士兵喊「掩護我」的意思。也就是說「對敵人開火逼他低頭，這樣我衝過街時敵人就不能向我開火」這招的確有用。)移動讓你攻佔地盤並且更逼近敵人，這時候射擊更容易打中目標。如果你不移動，敵人就能控制局勢，這可不怎麼好。另外如果你不開火，敵人就會對你開火把你釘在原地。

這件事我一直記得。我也注意到由空中纏鬥到大規模的海軍演習，幾乎所有軍事策略都是由邊開火邊移動的概念延出來的。我又花了15年才瞭解這也是在生活中成功的方法。每天你都得前進一點點。你的程式不好有錯還是沒人要，這全都沒關係。只要你一直進行，持續的寫程式並修正錯誤，時間就會站在你這邊。當競爭者對你開火的時候要注意。他們可能只是想逼你忙著應付，讓你不能繼續前進。

想想看微軟所推出資料存取策略的歷史吧。ODBC，RDO，DAO，ADO，OLEDB，還有最新的 ADO.NET - 全部都是新生的！難道這些技術都是非要不可的嗎？還是一個年年都在重新發明資料存取的無能設計團隊的傑作呢？(這很可能是真正的答案。) 不過最終的結果卻剛好成為火力掩護。它讓競爭者別無選擇，只能用盡所有時間進行移植和昇級，沒有時間去寫新功能。仔細看看軟體業界。成功的公司對大公司的依賴最少，不需要花所有工夫追隨並重新實作，然後去修那些只出現在 Windows XP 上的問題。而跌跌撞撞的公司都花太多時間去揣測微軟未來的方向。大家都擔心 .NET 的出現，認為有絕對必要所以決定針對 .NET 重寫整個架構。事實上微軟是在對你開火，而且只是讓他們前進並阻礙你們的掩護火力，因為這就是遊戲規則，朋友。你想支援 Hailstorm 嗎？SOAP 呢？RDF 怎麼樣？你支援這些東西是因為客戶需要？還是因為有人對你開火而覺得應該有所反應呢？大公司的業務團隊很瞭解火力掩護這一套。他們會去跟客戶說「沒錯，你不一定要買我們的東西。要買就要買最好的。不過記得你買的產品一定要支援(XML /SOAP / CDE / J2EE)，否則你就會被綁住了。」然後當小公司試圖接觸這個客戶時，這個聽話的技術總監就會像鸚鵡一樣說「你們支援 J2EE 嗎？」儘管 J2EE 不會真正帶來收入，他們還是得耗盡所有的時間加上 J2EE，結果完全沒機會讓產品產生區別。這是個勾選項目，會去做只是因為需要有個項目打勾表示你也有，不過沒有人會用也沒有人需要。而這就是掩護火力。

對我們這種小公司來說，邊開火邊移動有兩個意義。你必須爭取時間，另外每天都得要前進。你遲早會贏的。我昨天整天只是把 FogBUGZ 的配色改善了一點點。這並不要緊。東西會愈來愈好。我們的軟體每天每天都會變得更好，而且客戶會愈來愈多，這就夠了。在我們變成 Oracle 這種規模的公司前都不用管什麼偉大的策略。我們只要每天早上來公司，想辦法要自己打開編輯器就好了。

這些網頁的內容為表達個人意見。
All contents Copyright © 1999-2006 by Joel Spolsky. All Rights Reserved.