設定優先順序 Set Your Priorities

我們之前剛出了一個大的 service pack，解掉一大堆沒有人會發現的小 bug（也因而導致了幾個沒有人會發現的新的小 bug）。現在該是結束 FogBugz 4.0，開始為 FogBugz 5.0 加些新功能的時候了。

在開始動手前，我們想加的新功能多到可以讓 1700 個程式設計師做個幾十年都沒問題。不幸的是，我們總共才三個程式設計師，而且我們希望在下個秋天就能出貨。所以我們必須排定優先順序。

在我開始說該用什麼方法為新功能排定順序前，我得先告訴你兩個不該採用的方法。

方法一。若一項新功能的開發只為了已答應某個客戶的話，嗶！你的腦子裡應該亮起紅色警戒燈。如果功能總是針對特定客戶的話，不是銷售員亂槍打鳥，就是你正冒著讓產品往顧問軟體(consultingware)走的危險。顧問軟體本身沒什麼問題；你可以很安逸地往那個方向走，只是它沒辦法像套裝軟體(shrinkwrap software)賺那麼多錢罷了。

套裝軟體這種開發模式的特性是要嘛就全要，要嘛就全不要。你把軟體寫完，用塑膠膜包起來之後，客戶要嘛就買，要嘛就不買。他們不會說你要加了某個功能他們才會買，也不會打電話和你討論他們需要哪些功能。就像你不會打電話給微軟說：「喂！我愛死你們泰文版 Excel 裡那個可以用來拼數字的 BAHTTEXT 功能(譯註：baht 是泰國的貨幣單位：泰銖)，不過我只能用英文版的。如果你們能幫英文版加這個功能的話，我就買你們家的產品。」如果你真的打給微軟的話，你大概會得到以下回覆：

「這裡是微軟，很高興有機會為您服務。如果您有四位數促銷碼的話，請按 1。產品技術支援請按 2。大宗授權或相關資訊請按 3。撥分機號碼請按 4。要重聽請按星號。」

看到沒？沒有一個選項是「需要討論在購買微軟產品前所需新加的功能請按 5。」

客製化開發的世界是晦暗不明的。通常客戶會告訴你要開發哪些功能，然後你問：「你確定要這麼做嗎？」之後，客戶會說沒錯。之後你回去開一份漂亮的規格書，回來和客戶確認：「這就是你想要的東西嗎？」。客戶再告訴你沒錯後，你就要他們在合約上白紙黑字簽名，不，是以項上人頭擔保規格無誤。最後你會很迅速地、分毫不差地把他們簽字所要的產品開發出來。客戶看到成品後會驚駭不已，然後你就得把這星期僅剩的時間拿來研究你的錯誤與疏漏保險(E&O insurance)是否足夠付你的訴訟費或和解費了。或者，如果你的運氣真的那麼好的話，客戶會臉色蒼白地笑一笑，然後把你的心血收到抽屜裡，再也不用你的產品或回你電話了。

開發軟體時，有時候你會騙自己是在開發套裝軟體，實際上卻是在做客製化開發的顧問軟體。以下是顧問軟體的開發流程：

1. 為了一些微薄的薪水，你幫一家製鞋公司開發軟體
2. 這家製鞋公司現在需要一套擦鞋軟體
3. 所以你就用 VB 3.0 寫了一套擦鞋軟體。這個軟體還用到了一些 JavaScript、Franz Lisp、以及一個在老麥金塔上執行並用 AppleScript 連上網路的的 FileMaker 資料庫。
4. 由於用過的人都說好，你開始夢想開一家自己的軟體公司，就算當不成 Bill Gates 能作 Larry Ellison 也不錯。
5. 因此你向前公司買下鞋亮亮 1.0 並找創投籌些錢開了家「鞋亮亮有限責任公司」，開始賣擦鞋軟體。
6. 不幸的是這套軟體沒有一個 beta 測試人員可以讓它動起來，因為它和 AppleScript 糾纏不清而且 IP 位址又寫死在原始碼裡，所以一個客戶安裝一套就要花上一個月的時間。
7. 再來你在招攬客戶上也碰上了麻煩。由於軟體用到古董麥金塔 IIci 的 System 7，你只能到 ebay 的電腦博物館去搜刮。這些安裝成本使產品貴到不行，投資你的創投也開始緊張起來。
8. 創投開始把壓力施加到銷售人員上。
9. 此時有個銷售人員發現某個潛在客戶並不需要擦鞋軟體，但卻有熨長褲的需求。
10. 因為銷售人員的工作就是銷售東西，這位大哥就把熨長褲軟體用美金十萬賣給這位客戶。
11. 現在只為了這位客戶，你得花上六個月開發「熨長褲模組」。
12. 由於沒有其他客戶會用到這個模組，所以技術上來說，
13. 你花了一年的時候從創投那裡籌資，就只為了幫一家長褲公司開發程式並領一份微薄的薪水；回到步驟一。

就是這樣，所以我強力建議要堅守在套裝軟體這邊。原因是套裝軟體每增加一個客戶並沒有額外的成本，所以本質上可以用同樣一套產品賣給不同的客戶以賺取更多的利益。再者，由於可以將開發成本轉嫁到更多的客戶身上，價格也可以進一步調降。降價會讓大家突然發現你的產品更價美物廉，而吸引到更多客戶。從此你就過著幸福快樂的日子。

因此，如果你發現加入某項新功能只因為已答應了某個客戶的話，表示你正在漂向顧問軟體及客製化開發的小島上。這也是一個不錯可以作生意的世界，只是它的獲利爆發性不如現成商業軟體罷了。

別搞錯了，我不是說你不該傾聽客戶的需求。我其實也認為微軟該為我們這些還沒加入全球經濟圈去學習泰文，而且還在用其他貨幣簽支票的人寫個類似 BAHTTEXT 的功能。不過事實上，如果你想說服自己分配有限資源的最好方式，是讓幾個最大的客戶去投票決定該加入哪些功能的話，你也可以這麼做。但你很快就會發現有錢的大客戶要的功能和普羅大眾是有出入的，所以加入處理泰銖的功能並無法真正幫助你將 Excel 賣進亞利桑那州 Scottsdale 的保健 spa 去(譯註：Scottsdale 是美國著名的觀光勝地)。其實如果你真的這麼幹的話，結果只是讓你的開發人員去幫銷售人員賺進大筆的佣金罷了。

你要想當 Bill Gates 的話，用這一招是辦不到的。

現在我要開始講第二個不該用來決定要加哪些功能的方法：不要只因為不得不做而做。不得不做這個標準不夠高。請聽我以下解釋：

Fog Creek 第一年營運時，我在歸檔時發現藍色資料夾用光了。

我現在的歸檔系統是這樣的：藍色資料夾放客戶資料、淡綠色資料夾放員工資料、紅色資料夾放收據，其他資料則放黃色資料夾。現在我要用藍色資料夾但是卻沒有了。

所以我是這麼想的：「搞什麼！反正我總是得用到藍色資料夾，不如現在去 Staples(譯註：Staples 是賣辦公室用具的公司)買幾個回來。」

當然，這又浪費了我一些時間。

當我事後回想起來，我發現長久以來我一直在做一些無聊的狗屎(這是個技術用語)，原因是反正都得做不如現在去做。

我用這個藉口去幫庭院除草、修補牆上的洞、整理 MSDN 光碟(依顏色、語言及編號)等等，族繁不及備載，而當時我真正應該做的事是去寫程式或賣程式，這是創業者唯二真正需要做的事。

換句話說，我發現自己假裝所有必須做的事都一樣重要。既然這些事早晚都得做，做的順序也就不重要了！就是這樣！

但說實在的，我只是在拖拖拉拉罷了。

那我該怎麼做？嗯，一開始可以先從根除資料夾得有特定顏色的迷思做起，反正這沒什麼差別, 你又不用幫自己的檔案加上顏色碼才能用。

喔，那那些 MSDN 光碟片呢？全部丟到同一個大盒子裡就好了。讚！

更重要的一點是，與其說「重要性」是黑白分明的，不如說它是一種類比的東西。不同事物有不同的重要性，如果想大小通吃的話，最後只會落得一事無成。

因此，無論何時你想完成一些事情，必須得了解當下最重要是該先做哪件事。不這麼做的話，事情就無法在最短的時間內完成。

我逐漸戒掉自己拖延的傾向。戒除的方法是把較不重要的事放著不做。有個保險公司的好脾氣女士纏了我兩個月，要拿一些用來更新我們保單的資料，可是一直到她第十五次索取，並且嚴厲警告我們的保險在三天內失效，我才真的把資料拿給她。而我認為這是件好事。我已經成熟到認為，保持桌面整潔實際上很可能是你無效力的表徵。

這是多麼使人羞愧的想法啊！(How's thatfor a mortifying thought!)

所以呢。不要去做那些業務不小心答應某個客戶而衍生的功能，也不要因為「反正到最後總得完成」而先去做那些不重要或好玩的功能。

總而言之，回到 FogBugz 5.0 功能選擇的主題。下面是我們定出初步優先順序的方法。

首先我拿出一疊 5x8 的卡片，在每張卡片寫上一個功能，然後召集整個團隊。就我的經驗來說，這個方法最多可以用於約二十人的團隊，另外不同觀點愈多愈好：程式師、設計師、面對客戶溝通的人、業務、管理者、文件撰寫人員和測試人員，甚至連客戶也可以。

我要求每個人把自己想的功能列表帶來開會。會議的第一階段是非常快速地瀏覽每個人的功能，確保大家對每個功能本身有非常非常粗略的共同理解，另外也確定每個功能都有一張對應的卡片。

這個階段的想法並不是要去爭論各個功能的好壞，或是去進行功能的設計，甚至也不是要討論功能，只是要對功能本身有個含糊粗略的想法。FogBugz 5.0 的部份功能如下：

• 個人化的首頁
• 無痛軟體時程
• 追蹤可報帳時數
• 複製一個問題(fork a bug)
• (46個其他功能...)

非常含糊的東西。記住我們此刻並不要知道各個功能如何實作或牽涉什麼，因為唯一的目標是要得到粗略的優先順序，以作為開始開發的基礎。這個過程會讓我們得到一份約有 50 個大功能的列表。

第二階段要對大家對每個功能逐一投票。只是很快速的「贊成」或「不贊成」，不要討論，什麼都不要做，只要對每個功能很快地表示贊不贊成。這個過程顯示約有 14 個功能沒什麼人支持。我把只得到一或兩票的功能拿掉，剩下 36 個可能的功能。

接下來我們為各個功能設定一個 1 到 10 的成本，1 表示快速趕出來的功能，而 10 則是個龐大的怪物功能。在這個階段必須要記住，目標並不是排定這些功能的時程，只不過是要把大中小的功能分開。我只是針對各個功能逐一詢問開發者，要他們說出「小」、「中」或是「大」。即使不知道某個功能要做多久，還是能輕易看出複製一個問題是個「小」功能，而大而含糊的「個人化首頁」是個大功能。我們基於這種對成本的共同估計和我自己的判斷估算出各個功能的價格。

再一次強調，這方法的確很散亂而不精確，不過這無關緊要。你現在並不是要排時程，只不過是在理出優先順序。唯一需要大致正確的事情就是粗略知道，在大約相同的時間能完二個中等功能或一個大功能還是十個小功能。不需要很精確。

下一步是把這 30 個建議的功能和它們的「成本」列成一份菜單。把菜單發給團隊裡的每個人，並且給每個人50元來點菜。他們可以隨意選擇，不過只能花 50 元。如果想的話，可以只買半個功能，也可以買雙倍功能。真的很喜歡「追蹤可報帳時數」功能的人可以在這個項目花 10 元或 15 元；沒有很喜歡的人可以只花 1 元，看看是否有別人投入足夠的資金。

接下來把每個人花在各個功能上的錢加總起來：

最後我把所所花的錢除以成本：

然後照這個數字排序找出最受歡迎的功能：

完成了！一份列出所以可能想做功能的列表，而且是依照大家對最重要功能的最佳想法大致排列好。

現在你就可以開始仔細推敲了。舉例來說，你可以把本來應該放在一起的功能集合起來，比如進行軟體排程會讓可報帳時數更容易完成，所以或許我們應該兩個都做或是兩個都不做。另外有時候順著這個排好優先順序的列表看下來，就會發現有些東西顯然弄錯了。有的話就修正吧！沒什麼東西是絕對不能動的。你在進行開發時甚至還可以改變優先順序。

不過最令我驚訝的是，我們產出的最後列表對 FogBugz 5.0 來說確實是個非常好的優先次序，而且也的確反映了我們對各功能相對優先順序的集體共識。

我們拿著這份優先順序列表，大致上依序逐項進行到三月為止。我們計畫屆時不再增加新功能，然後開始整合與測試階段。我們將會在各個(不是顯而易見的)功能正要實作之前，替該功能撰寫規格。

(嘮叨的 BDUF / Agile 選美競賽記分員現在大概完全迷糊了。「那表示 BDUF 拿到一票？還是投給 Agile 呢？他究竟要什麼呢？他不能就這麼一次選好一邊站嗎？！」)

整個規劃過程用了三個小時。

如果你運氣夠好，有本事能比我們更頻繁地發行軟體新版(參考Picking a Ship Date)，還是得依序遂項進行列表的功能，不過你可以更頻繁地停下來做發行動作。頻繁地發行的好處，是可以依據客戶實際的回饋經常地重新安排功能列表的優先順序，不過並不是每個產品都有這種福氣。

Mike Conte在規劃Excel 5時教導我這個系統，當時雖然在會議室裡有二三十個人，也只用了兩三個個小時就完成了。而酷的是，我們沒時間做的功能中約有一半都是真正愚蠢的功能，Excel也因為沒有這些功能而變得更好。

這方法並不完美，不過我會告訴你，這比到 Staple 買藍色資料夾要好多了。

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