絕不妥協的抓蟲行動 Hard-assed Bug Fixin’

軟體品質是(或者說缺乏品質)是每個人愛抱怨的事。現在我既然有了自己的公司，終於決定要為此做些事情。過去兩星期為了推出新版的 FogBUGZ，我們暫停 Fog Creek 的所有活動，把目標定為清掉所有已知的問題(大約有 30 個)。

身為一個軟體開發者，修問題應該是件好事，對吧？這不一直是件好事嗎？

錯！

只有當修正問題所得到的價值超過修正所花的成本時，修正問題才是件重要的事。

這些事很難度量，不過並非不可能。讓我來舉一個例子。假設你在經營一個做花生醬三明治及果醬三明治的工廠，工廠每天可以生產十萬份三明治。最近因為增加了新口味(燈籠辣椒醬及大蒜花生醬)，產品需求一飛衝天。工廠產能只有十萬份三明治，可是需求可能接近廿萬。你就是做不出更多的三明治了。另外一個三明治的利潤有 15 美分。所以由於產能不足，你每天可能損失一萬五千美元。

不過建一座新工廠可能太貴，你付不起那個錢，而且你也害怕辣味和大蒜味三明治只是一陣流行，時間一過就沒了。不過你每天還是少賺一萬五千元。

雇用傑森倒是件好事。傑森是個入侵工廠電腦的14歲程式師，自認有辦法把生產線加快到兩倍。方法大概是跟他在 slashdot 聽到的超頻技術有關吧。而且試產時看起來似乎有效。

沒有正式上線只有一個原因。有個小到不能再小的小問題，大約每小時會有一份三明治被碾碎掉。傑森想要修好這個小問題。他認為可以在三天內修好。你要讓他去修嗎？還是讓有問題的軟體直接上線呢？

三天後再上線會讓你少賺四萬五千美元，同時可以替你節省 72 份三明治的原料成本(不管哪種狀況，反正傑森三天後都會把問題修好)。好吧，我不知道在你的星球上一份三明治要多少錢，不過在地球上絕對要比625美元低很多很多。

我扯到哪去了。噢，對了。有時候問題並不值得修正。下面是另一個不值得修正的問題：如果你有個問題式，會讓程式在開啟超級大的檔案時完全當掉，不過只會發生在你唯一一位使用 OS/2 的用戶身上，而且就你所知這個用戶根本沒有大檔案。好吧，別修了。這並不算太糟。同樣的道理，我通常都會放棄那些使用 16 色螢幕或者還在用 Windows 95 而且 7 年沒升級的人。像這樣的人不會在套裝軟體產品上花多少錢的。相信我吧。

不過大部份情況下問題都是值得去修正的。即使是「無害的」問題也會減低你公司和產品的聲譽，長久下來對你的收入就會有重大的影響。產品問題多這種惡名是很難逆轉的。如果你真的要推出產品的 .01 版時，這裡有些點子可以幫你找尋並修正正確的問題：那些從經濟面看值得修正的問題。

第一步：確定你知道問題的狀況

以 FogBUGZ 為例，我們有兩種方法可以達到。首先我們會把免費試用伺服器出現的問題全部抓下來，儘可能的記錄最多的資訊，然後把全部資料用電郵寄給開發團隊。這種作法找到很多很多的問題，效果非常的好。舉例來說，我們發現很多人都不會在「Fix For」畫面輸入應有的日期。我們在這種情況完全沒有給錯誤訊息，就直接當掉了(對 web 應用程式來說，這表示你會看到一個醜醜的 IIS 錯誤而不是預期的畫面)。啊！

當我在 Juno 工作時有套更酷的系統，可以「由外頭」自動收集問題。我們用 TOOLHELP.DLL 裝了一個處理程式，每次 Juno 當掉時就會把處理程式叫起來，把堆疊傾印到一個記錄檔裡然後結束。下次程式連到 Internet 送信時就會上傳記錄檔。我們在做 beta 測試時會收集這些檔案並檢視所有當機狀況，然後輸入到問題追蹤資料庫裡。這種作法確實找到幾百個當機的問題。當你有一百萬個使用者時，會當機的狀況會相當神奇，常常都是因為記憶體嚴重不足或是很爛的電腦(你叫得出 Packard Bell(譯註：某平價電腦品牌)嗎？)你可能有如下的程式：

int foo( object& r )
{
    r.Blah();
    return 1;
}

你會因為 r 的參考為 NULL 而當掉，雖然這應該絕對不可能發生，不應該會有 NULL 參考的這種鳥事，C++ 保證過的。你不一定要相信我，不過當你等得夠久，有幾百萬用戶又努力收集他們的堆疊傾印時，就會發現這種地方也是會當的，讓你無法相信自己的眼睛。(不過你並不會去修正這種問題。萬能的天神啊，請幫這傢伙弄一台新電腦吧，而且這次別把你找到的所有酷工作列共享軟體都裝上去。真是狗屎。)

我們做的另一件事是把每個技術支援電話都視作某個問題的跡象。當我們接到電話時，會試著思考能做什麼來避免。舉例來說，舊的 FogBUGZ 安裝程式通常假設 FogBUGZ 是用匿名Internet 使用者帳號執行的。這個假設 95% 的時間都對而其他 5% 的時候會錯，不過這5%的狀況最後會變成打進我們支援專線的一通電話。所以安裝程式改成會詢問帳號。

第二步： 確定你會得到經濟上的回饋

你可能沒辦法精確算出修正每個問題值多少，不過還是有些事能做：把技術支援的「成本」算在事業單位的帳上。九十年代早期微軟做了一次財政上的組織重整，讓各個產品事業單位負責所有技術支援電話的全部成本。所以產品事業單位就開始堅持 PSS(微軟的技術支援部門)定期提供前十大問題列表。當開發團隊集中處理這些問題之後，產品的支援成本也就直線下降了。

這實在有點違反讓技術支援部門自己養自己的新趨勢，因為多數的大公司都已經這樣做了。在 Juno 甚至還要求技術支援部門對上門求救的人收費以達到損益平衡呢。要察覺問題所帶來傷害的方法本來就不多，這樣把問題的經濟負擔由開發者轉移到使用者身上，會讓你失去這有限的能力。(換來的卻是得替你的問題買單的憤怒用戶，他們會告訴朋友，到後來你根本無法估計所花的成本。不過對 Juno 要公平點看，因為產品本身是免費的，所以就別再埋怨了。)

有一個解決的方法，就是當支援電話是因產品本身的問題而引起時，不要向使用者收錢。微軟就是這樣做的，效果相當好，而且我也從來沒有因為打給微軟而付錢。:)應該要反過來向產品單位收 245 美元或目前一份開發者支援(developer incident)的成本。這樣就會把他們販售該產品的利潤全部吃光(可能還多賠好幾倍)，並確實產生正確的經濟誘因。這讓我想起到 DOS 遊戲所以是爛事業的一個原因... 通常需要用奇怪的顯示驅動程式才能讓遊戲看起來漂亮而且跑得快，而一通顯示驅動程式的技術支援電話就會吃掉20套遊戲的利潤，這還得假設 Egghead 和 Ingram(譯註：通路商)以及 MTV 台的廣告還沒有把利潤全部花掉。

第三步：找出哪些問題值得全部修好

在 Fog Creek 這種小公司(在我們心裡可不小)都是由開發團隊自己技術支援電話。成本大約是每天一小時，用我們的顧問費率來算的話大約是一年七萬五千美元。如果能把所有的問題都修好，我們很有把握可以降到每天 15 分鐘。

粗略估算起來省下的純現值約為十五萬元，約為 62 天的工作成本：所以如果能在 62 天內完成，就值得做了。

利用方便的 FogBUGZ 內建估計功能，我們算出 20 個人日(兩人兩週)可以修好所有問題。所以四萬八的「支出」換回十五萬的報酬，這單就減少技術支援來算就已經是很高的投資報酬率。(注意你可以拿程式師薪資和經常開支的成本和我們的顧問費率相比，會得到相同 1:3 的結果，因為它是一樣的)。

我還沒開始計算因產品改善而增加的價值，不過現在來算也可以。使用舊程式的試用伺服器在七月共當了55次，遇到當機的使用者共 17 名。你可以想像這些人裡頭至少有一位會決定不買 FogBUGZ，因為他們試用後認為產品的問題很多(不過我並沒有真正的統計數據)。不管如何，以現值來說我們損失的業務可能在七千到十萬美元之間(如果你夠認真的話，要找出確實的數字並不會太難)。

接下來的問題是，比較穩定的產品可以賣貴一點嗎？這樣子除錯的價值就會大增了。我猜想問題的數目的確會影響價格，不過實在想不到有什麼套裝軟體可以作為例證的。

請不要打我！

當人們讀到這種文章，難免會得出類似的蠢結論：約耳不認為你應該修正問題。事實上我認為大多數修好的問題都有很明確的回報。不過比起修好所有問題，或許去做其他事情能獲得更高的金錢回報。如果你必須二選一，是要修正 OS/2 用戶會遇到的問題，還是加一個能讓奇異(GE)採購兩萬套的新功能，那麼就得跟 OS/2 先生說抱歉了。如果你笨到認為修正 OS/2 的事還是比增加 GE 的功能重要，你的競爭者大概不會這樣想，所以你就出局了。

這一切都表示我其實是個樂觀主義者，而且我相信製作超高品質產品還能得到很多隱藏的價值，只是很難發覺而已。你的員工會更自豪。也比較不會有客戶把你的光碟丟進微波爐烤完後，用斧頭劈碎再寄回來給你。所以我寧願偏向品質面(我們真的修好了 FogBUGZ 裡所有已知的問題，而不光是最嚴重的大蟲)而且以此自豪，並且確信把試用伺服器的問題全部清除，能讓我們有一個堅若磐石的產品。

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