項目管理 - 開發量估算 (2)

繼上篇寫了開發量估算的重要性，本篇繼續，並會較具體說明估算的方法。

在進行IT項目時，合理的做法是就項目範圍及需求評估開發量及測試量，合理估算項目時間。當遇到項目需求有多種方法落實時，也就不同方案評估。不過，不時也會遇到一些情況，參與項目的成員沒有合理評估開發量的方法，或用了不準確的方法進行評估。

其中一個很常見的誤區，是按項目需要作出改動的系統數量作出評估。例如項目實施方案有兩個，A方案牽涉3個系統改動，B方案牽涉2個系統改動，就直接下結論說B方案較簡單。另一個類似情況，評估不同項目的大小，沒有仔細看項目內容，就看項目各自牽涉的改動系統數量作比較。這種方法是過份簡化了評估的過程，無視各個系統的改動範圍，也無視了系統本身的複雜程度。情況就比如比較任何兩個地點的距離，就用兩地相隔多少個地鐵站來比較，大家也可以想像到當中的誤差了。

不過，上述這個誤區之所以常見，除了是因為這種方法最為簡單，更重要是因為可以將比較數字化，這種做法能讓人自我感覺已做了breakdown，在不想仔細了解系統組成部份又想表示已做了什麼的話，就變成最好的方法了。

筆者也曾經遇過有些人參與項目，要做一個系統，就只看到一整個系統，沒有把系統的各個模塊或功能進行邏輯性分柝，情況就像要做一架車，他/她就只看到一整架車。這樣去做評估的話，法拉利也跟豐田一樣是一架車，各個系統也只是一個名稱而已。當問到要breakdown 時，就drill down 到逐個data field 去看，就像汽車的逐粒逐粒螺絲去看，這樣也同樣看不到有系統性或邏輯性。

實際上，在計算項目中系統開發量的時候，我們可以學習嘗試應用功能點分析 (Function Point Analysis，或FPA)的方法，把項目中所牽涉的系統開發各項功能分解，以協助了解並評估項目範圍的大小。就系統功能而言，我們可以把功能簡單分為數據及操作過程兩類。

先談數據 (FPA 以Data Function 來表示)。在評估數據功能時，最好是使用用戶能夠理解，有邏輯性關連的主數據群，例如客戶資料、交易紀錄、Static Data、市場數據、交易過程中數據等。數據又可以再細分為內部數據及外部接口數據，存儲在同一系統內的為內部數據，由其它系統調用的為外部數據。

其次是操作過程功能 (FPA 以Transaction Function來表示)。這裏我們要能夠看到系統的界線 (application boundary)，並以此界線分隔開系統和用戶以及和其它系統的關連，並細分各項功能的Input 及Output。例如系統讀取其它系統的數據是一個功能，提供數據接口是另一個功能。又例如用戶經介面輸入是一項功能，從另一介面查看數據又是另一項功能等。

當然也還要包括系統的internal process (FPA以Elementary Process 來表示)。Elementary Process 最好是能夠提系統提供的功能有邏輯性地拆解，愈細愈好，當然細的程度也要用戶能夠理解。如較複雜的流程，可以是流程上一個節點所進行的邏輯計算或按rule table進行判斷，又例如系統本身每日會行的batch job等。

應用功能點分析的做法，可以更有效地把項目的開發功能分拆，進而就各個功能評估開發量，例如同是調用外部數據，實時讀取和使用批次檔就很不同。亦可按過往項目的類似經驗進行評估，基於功能已經拆分為細件，就更容易找到能夠類似的開發功能進行比較和評估。

不過有不少項目的參與者，尤其是用戶，總會推說用戶的職責只在於提出需求，不需要理解當中IT是如何進行開發，做測試的時候也是用End-to-End方法云云。這種想法實際上也是有誤區的，亦是一種頗常見推卸責任的方法。正如「需求管理」篇章中提到，同一個需求，可以有不止一個實施方法，提供實施的細節亦是為了讓各項目成員判斷是否滿足需求。而至於測試，如果不清楚系統是怎樣實施以滿足需求，又怎能確保所謂End-to-End 測試有涵蓋所有開發功能呢？

當然，推卸責任也可以是無極限的，End-to-End 測試沒有涵蓋，有人可以一句就推說是SIT的不足，是否如此就視乎情況了。項目經理在確保項目質量時，需要能夠判斷項目中各個環節是否有效落實，分析需求、評估開發量是否到位等，這都可以在項目初期就建立較堅實的基礎。