隨筆2：開發工作單位的分解過程

    在軟體開發中，往往因為功能（任務）分解得不夠細緻而造成過程失控，可能因為功能的反覆修改或遇到原來沒有預見的技術痛點而造成進度延遲，更有可能要推倒重來。在開發過程中，往往是公司交給一個項目組某個項目，只要求幾個月完成；項目組分配到某個開發人員手裡，只明確到某個人需要完成哪些模組，比如使用者管理模組、郵件發送模組等。對公司為說，項目成了最小的分解單位，對開發人員來說，模組是最小分解單位。一個模組如果需要1000行代碼，7個工作日，一個人在沒有任何工具的支援下，一般不太可能知道具體的細節流程，無法知道會遇到什麼樣的技術或流程風險。

    軟體開發中，十個人有九個人認為開發工作單位是不可量化的，只能質化，所以會出現以測試驅動開發這樣的開發模式，量化，成了很難逾越的鴻溝。其實，我們平時所說能量化的東西，一般是指可以數出數目的個數，比如水果，除了可以數個兒外，還可以稱重量，像軟體開發這種即數不出又稱不出的，理所當然就不能量化了。

    諮詢行業曾經是我夢想進入的行業，可惜這個行為像軟體業一樣，在國外很吃香（門檻很高），在國內成了民工，包括三大諮詢公司之一的麥肯錫在中國也上演滑鐵盧。諮詢行業和軟體行業一樣，他們的諮詢顧問和開發人員的工作也是不容易量化的，不過，麥肯錫的顧問工作任務卻是細化到每一個步驟，諮詢的內容細化到每一個過程，這種無盡細化的工作方式，應該也適合軟體開發，這種任務細化的分析方法叫MECE。

    MECE是麥肯錫的第一個女諮詢顧問巴巴拉·明托（Barbara Minto）在金字塔原理（The Minto Pyramid Principle）中提出的一個很重要的原則，全稱是Mutually Exclusive Collectively Exhaustive，中文意思是“相互獨立，完全窮盡”。MECE分析法主要是把一個工作項目分解為若干個更細的工作任務的方法。在項目分解的時候，必須保證項目的完整性與獨立性，分解後的子項目總和是=1，如果出現>1則說明分解有重疊部份，如果<1，則說明有遺漏。

    在軟體開發過程中，我們也可以把模組和功能一一分解出來，根據MECE分析法，在分析問題的時候，從解決方案的最高層次開始，設定解決方案的維度，然後列出每個維度中所有的項目。當確定每個項目都可以做為一個獨立的項目來解決的時候，就可以尋求項目的解決辦法，如果某個項目還無法做為一個獨立的模組來解決，那麼必須繼續分解。至於說到什麼樣的程式才算是一個獨立的項目呢，比如，使用者管理這個項目，因為包含有添加、修改、刪除、查詢等功能，而且這些功能又可以做為一個獨立的小項目，所以“使用者管理”不能做為一個獨立的項目，分析的粒度如果到此為止，那麼，負責“使用者管理”這個項目的開發人可能就不知道他需要實現多少個功能，刪除需要嗎？查詢需要嗎？如果不能確定，就會造成進度失控。既然“使用者管理”還不能做為一個獨立的項目，那麼我們繼續分解，比如分解出“添加使用者”這個項目，“添加使用者”還不能做為一個獨立的項目，因為，添加時會用到查重、使用者名稱的格式限制，所以，可以再次分解，這樣分析出“查重”和“使用者格式限制”這兩個獨立項目，以查重為例，它只涉及到“以使用者名稱為關鍵詞來查詢某個使用者是否存在”，這樣，就可以確定查詢的對象實體、查詢的關鍵詞和需要的結果。

    如果我們把一個整體的項目分解成若干個這樣的完全獨立的小項目，在開發人員拿到開發工作單位的時候，就是一個一個的小項目，每個小項目清晰的描述了在什麼條件下需要什麼樣的結果，而且這些小項目的耗時一般不會超過1個工作日，開發人員可以自由的安排每天完成哪幾個小項目，質檢人員也清楚需要檢查哪些小項目，大家都非常清楚各自需要做什麼，和做過什麼，哪裡出現了問題。這樣，開發人員就不需要糾纏於複雜的邏輯業務，不需要承擔因模組複雜而帶來的風險，他們可以安心的考慮使用什麼樣的技術實現這些小項目的功能。

 

   PS：寫完了，總覺得還不夠完善，思路和流程不夠多明朗，有點霧裡看花的味道，蛙蛤蛤！明天再改改