絕不妥協的抓蟲行動

作者:周思博 (Joel Spolsky)
譯:Paul May 梅普華
Tuesday, July 31, 2001
屬於Joel on Software, http://www.joelonsoftware.com


軟體品質是(或者說缺乏品質)是每個人愛抱怨的事。現在我既然有了自己的公司,終於決定要為此做些事情。過去兩星期為了推出新版的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.