二八原理：軟體開發中的二八原理

標籤：自己的   分析   lib   save   工作量   原理   邏輯   bug   印象   

前面聊了“什麼是二八原理”，接下來得說說如何運用了。由於本部落客要談IT技術，顯然要先來說說和程式員有關的那些事。為了不至於太抽象，我們以開發文字編輯器為例（這玩意大伙兒都熟悉，省得費口水解釋），來說說不同職責的開發人員在開發過程中該如何具體運用二八原理。

需求分析

需求分析在整個開發過程中占的工作量不大，但是產生的影響巨大（這又是一個二八原理的例子）。既然需求分析如此重要，照理說應該安排最強的人來搞。但實際情況往往不是如此：很多公司負責需求分析的人並不勝任這項工作。我經曆過幾個不太成功的項目，其問題的根源都和需求分析有關。

需求分析最要緊的是：搞清楚使用者到底想要什嗎？如果這個問題搞錯了、搞偏了，後面的步驟做得再好也是白搭（比如客戶想要一個文字編輯器，結果你搞了個圖形編輯器給他）。這方面其實有很多的道道，限於篇幅就不展開了，大伙兒如果有興趣，以後可以單獨說一下。

在搞清楚“使用者想要什麼”之後，接著要整理出功能列表（也有叫Feature List），並篩選出大約20%的重點功能。這個步驟是我今天主要想介紹的，因為這個步驟和後續的各項開發密切相關。一般來說，功能篩選的依據有如下幾個：

1. 使用者經常用的功能（比如save、copy、cut、paste）
2. 宣傳的賣點（要能夠超出同類軟體，吸引眼球）
3. 和使用者利益密切相關的功能（這種功能不允許出錯，比如存檔功能）

這個篩選的過程要儘早完成，而且最好是產品人員、開發人員、測試人員三方的頭頭一起討論，以保證立場客觀、觀點全面。篩選出重要功能點後，其他人員的工作安排要“以重點功能為綱”，有所側重。

專案管理

如果你是個專案經理，在排專案計劃時，就得盡量優先安排重點功能的開發/測試，而且要安排能力強的人員來完成。按照我以前的做法，重點功能排計劃至少得留出1/3的時間餘量，以防萬一（事實證明，幾乎每個稍大點的項目都會出現萬一）。至於非重點功能，盡量排到後面，安排能力一般的人開發/測試。

然後，在項目進行過程中，肯定要有週期性例會。作為專案經理，你應該主要關注重點功能的進度情況和風險情況。

一旦項目有延期的風險，就從非重點功能開始裁減（俗稱砍功能）。由於是裁減非重點功能，不至於產生致命的影響。

設計介面

設計介面時，你得保證所有的常用功能都放在顯著的位置（比如工具條）；還得保證它們用起來方便（比如提供快速鍵和右鍵菜單支援）。

對於賣點，它不一定是常用功能，它的目的是激起使用者的購買慾望和使用慾望。因此你要把它們設計得比較酷，有噱頭。

對於利益相關的功能，大部分情況下都是側重於商務邏輯實現。如果它既不是常用功能、也不是賣點，那麼介面設計方面倒不一定要額外花大力氣。

其它的非重點功能，只要按照常規方法設計，不用花太大精力。

編寫代碼

我發現很多開發人員有幾個通病：先做有趣或容易的功能，然後再做無聊或者繁瑣的功能；對自己有興趣的功能投入精力多，對自己沒興趣的簡單應付。

以上這些都是開發的大忌。作為一個職業的開發人員，不應該以自己的興趣和喜好來決定開發的輕重緩急。正確做法應該如下：

你首先得用主要精力完成上述所說的重點功能，而且要保證它們的代碼品質儘可能好，儘可能方便維護（重點功能往往是經常有需求變更，經常被修改的）。

對於重點功能中的“常用功能”，要保證時間效能夠好（能快速響應）。對於"使用者利益相關的功能"，要保證bug儘可能少（尤其是安全性、穩定性、健壯性的bug）。

至於其它的非重點功能，只要不出明顯bug，有點小缺陷無傷大雅。

測試

如果你是個測試人員，你同樣要把主要精力用於測試那些重點功能。對於“使用者利益相關的功能”，多進行一些健壯性測試、穩定性、安全性等測試（比如測試儲存大檔案是否會出錯）。對於常用功能，主要進行易用性和效能測試（比如拷貝、粘貼是否易用）。

至於其它功能，只要進行普通的測試，保證它不出現明顯和嚴重bug即可。要知道Windows 2000發布的時候，尚遺留上千個未修複的bug（當然都是低優先順序的），微軟不也照樣發布。

產品示範

有些軟體開發完之後，會搞一些Demo進行宣傳。如果你是負責進行Demo的人，你肯定要把主要的Demo時間用來秀軟體的賣點，這樣給客戶的印象最深刻，效果最好；至於非賣點的功能，都未必要提及。

幾種和開發相關工作就介紹到這裡，最後送給大夥一句話：Do not work hard, work smart!

下一個文章打算聊一下二八原理在管理中的應用。

二八原理：軟體開發中的二八原理