小型資訊系統開發與維護專案執行管理建議方案

　　針對資訊軟體系統開發部門的工作進度時，若無法確實掌握專案需求範圍應完成之工作項目時，常會出現系統功能無法滿足客戶期待或無法如期交付成果之情形。在實務上若又遇到屬於較為零星且小型的系統開發專案時，在管理上常會因為管理者與執行者對於工作的疏忽反而更容易發生專案進度失控之情形，進而可能產生違約或客戶抱怨情形發生。

　　在軟體開發生命週期管理流程中，不論軟體系統之規模大小，開發過程均可以劃分為需求訪談、需求規劃、系統分析、系統設計、系統實作、系統測試、上線運作與營運維護等幾個階段。

　　在管理理論與實務中，針對每個執行階段中又可能因為專案之複雜程度發展出許多不同的方法論與管理手法，然而當遇到規模較小（約6個人月內）的專案時，若在管理上運用這些較為複雜的方法時，對於執行人員與管控人員都會是相當沉重的負擔，但反之，若對於專案採用較為鬆散的管理方式時，亦有專案進度失控之風險。

　　故筆者依據個人管理經驗提供這類屬於小型且零星之專案管控方式，應可在不致對於專案執行相關人員之額外文件製作負擔，亦能有效掌握專案執行進度確保能如期完成專案要求之各項工作。

　　由於資訊系統開發完成後續驗收時，原則上均會採用區分各功能別逐項進行驗收測試，加上每個功能也必須經過軟體開發生命週期需求訪談、需求規劃、系統分析、系統設計、系統實作、系統測試、上線運作與營運維護等幾個階段。

　　因此在此工作執行之運作架構下，筆者將小型專案管控的工作方式運用一個二維管控表格的方式進行功能開發工作管理，在縱軸方面列出小型專案各項交付驗收時應辦之各項功能項目，在橫軸方面則依據軟體開發生命週期各重要階段，中間各欄位則供管理人員進行控管運用。

　　例如配合各項工作負責人與預定完成日為專案初期透過專案會議後進行擬定，至於實際完成日則由各負責人於實際完成時填入該項工作完成日期，該表格參考欄位設計如下：

表1. 專案執行管控參考格式

　　該管控表在實務運作上時，管控內容應由執行與管理人員共同擬定，針對不需要執行的框格可以免填相關資料，其次，本管控表的目的是對於專案執行進度能有快速整體性的掌握。

　　另外針對各項功能的階段成果亦可透過工作編碼的方式進行文件目錄管理，例如功能1編號01系統分析工作代碼為B，則可建立01B的專案目錄供存放功能1系統分析的工作成果，以利後續資料文件儲存交接與索引使用。

　　提供本管控表格實際運作參考案例如下，各欄位內容可依實際管理所需進行調整，原則以不要增加太多管理與回報負擔即可。

圖1. 專案執行實際管控案例參考

　　待系統上線運作後，若單位內對於客戶需求管理沒有特定之管制方式時，對系統維護單位在實務上之管理建議，則以運用導入需求管理工具進行需求控管，可採用市面上既有免費系統（如Mantis、BugZilla、trac、RT(Request Tracker)等）安裝後進行管理。

　　對於系統維護需求收集包括通報日期、通報人員、通報內容描述與相關附件等，待安排處理人員後指定負責人員，並於需求處理完成後回報完成日期、處理情形與客戶確認日期等，以確保各項維護需求通報均可獲得妥善的解決，避免遺漏。

　　在日常工作管理上也可以掌握待辦事項之處理情形。例如透過Mantis進行系統維護需求管理示範例。

圖2. 系統維護需求管理應用參考

　　以上日常工作管理建議，主要以個人管理實務經驗分享供各位讀者參考，實際運作上管理人員仍需投入執行工作成果驗證的確認動作，以避免發生紙上談兵之窘境。

　　在工作成果驗證上包括可以在系統功能完成測試前檢視各工作成果目錄是否已有完成之相關文件與程式碼等，另外則是安排不同的負責人員進行功能測試工作，在開發人員回報系統功能開發完成時，即交付測試人員依據系統設計時之功能流程進行實測，以驗證各項功能符合驗收標準。

　　以本文建議之方案進行小型系統開發專案之控管在筆者實務驗證後確實可行，也減少原本在管理上容易被疏忽之小型專案可因此受到控制，更重要的是不至於增加參與人員過多工作負擔。期待透過本文之野人獻曝可供讀者發想出更好的管理方案以更加有效的方式進行小型系統開發專案進度控管，以期讓各工作執行能夠如期如質達成目標。