背景#

FogBugz 4.0 版本剛發佈完大型升級包後，團隊準備開始開發 5.0 版本的新功能。挑戰在於：規劃增加的功能多到足夠 1700 個程式員幹上十年，但團隊一共只有 3 個程式員，而且希望新版本在明年秋天上市。因此，必須確定開發的優先順序。

兩種不應採用的方法#

方法一：為特定顧客開發功能#

如果你開發某個功能只是因為你答應過一個顧客，你的大腦中就應該亮起紅色警報。這意味著你可能正在走向「個性化軟體」這條危險的道路。

「個性化軟體」本身並沒有錯，但它的盈利性遠不如面向整個市場銷售的上架軟體：

• 上架軟體增加顧客的邊際成本為零，你就是在把同一件東西一遍又一遍地賣出去
• 你可以把開發成本分攤到大量顧客頭上，進而降低價格、獲得更多顧客

Joel 用一個虛構的「擦鞋軟體公司」故事，生動地說明了從上架軟體滑向客製化軟體的 13 步墮落過程——從為一家製鞋公司寫擦鞋軟體，到最後被迫為另一家公司寫熨褲子軟體。

方法二：因為「反正遲早要做」就現在做#

「重要性」並不是二元的（重要 vs. 不重要），而是有不同程度的。如果你想把所有事情都做完，最後只會一事無成。你必須隨時想清楚什麼是眼下最重要的，然後馬上去做。

Joel 分享了自己的經驗：Fog Creek 創立後第一年，他曾以「反正遲早需要」為借口，去做整理文件夾、拔花園雜草等不緊急的事情，而這些時間本應用來寫代碼或賣代碼。

Joel 的優先順序確定法#

整個流程大約花費 3 個小時，適用於不超過 20 人的團隊：

第一階段：列出功能清單#

1. 會前讓每個人想好自己想要實現的功能
2. 會議開始後，每個人快速展示自己想要的功能，確保大家對每個功能有粗略的共同理解
3. 每個功能寫在一張卡片上
4. 通過這個階段，得到一份約 50 種重大功能的清單

第二階段：快速投票篩選#

• 對每個功能進行「贊成」或「反對」的投票表決
• 不要討論，只要快速投票
• 把只得到一票或兩票的功能拿掉（大約 14 種），剩下約 36 個功能

第三階段：估算成本#

• 為每個功能設定一個成本，用 1 到 10 表示
• 1 = 可以輕而易舉地部署，10 = 超級龐然大物
• 目的不是制定開發日程表，而是區分小型、中型和大型任務

第四階段：模擬市場「點菜」#

• 把所有 36 項功能和它們的「費用」做成一張菜單，每人發一份
• 每人有 $50 可以用任何方式分配
• 可以買半個功能，也可以同樣的功能買兩個
• 然後把每個人在每項功能上花掉的錢加總起來，得到「銷售額」

第五階段：計算性價比排序#

用「銷售額 / 費用」得出每個功能的性價比，按此排序：

這份排序後的清單就是大家對最重要功能的共識。你可以將相關功能關聯在一起，做一些調整，甚至在開發過程中改變優先順序。最讓 Joel 驚訝的是，最終得到的任務優先順序真實地反映了開發團隊的共識。

後續執行#

• 按照清單從上往下進行開發，直到明年三月份停止增加新功能
• 開始整合和測試階段
• 在部署每一個功能之前，寫好規格說明書
• 更頻繁地發佈新版本，根據顧客的實際反饋經常重新調整優先順序

這種方法來自 Mike Conte 在 Excel 5 規劃階段的經驗。當時會議室裡有幾十個人，但也只花了幾個小時就決定了要開發哪些功能。其中大概有 50% 的功能後來沒有時間開發，但事實證明它們都是很蠢的功能，Excel 沒有它們反而更好。