16--論信息系統項目的范圍管理

摘要

2013 年 8 月，筆者作為項目經理參與XX省電子政務網一期工程的建設工作。作為該單位的重點戰略項目，該項目總投資為3200萬人民幣，項目周期為26個月，共有7個單位參與建設。該項目采用 B/S 結構，系統基于ORACLE數據庫的JAVA/JAVA EE多層體系結構，以LINUX為主的作為操作系統， 應用面向對象設計、面向服務（SOA）、面向接口技術、組件式開發技術，采用MVC、ORM、Web Service、AJAX技術。

該項目按照統一組織領導、統一規劃建設、統一數據標準、統一外網平臺、統一公文辦理及事務處理平臺、統一集中部署的要求，項目建成以后，實現全省公務員跨地區、跨部門和跨層級的信息傳輸、公文傳輸、信息共享和業務協同。

2015年 12月，該項目通過了客戶的驗收，贏得了甲方及各參與的一致好評，成為電子政務行業的成功案例，得到業內的一致認可。本文結合筆者的實際經驗討論了項目的范圍管理，主要從制定范圍計劃、定義范圍、創建 WBS，以及核實范圍、控制范圍這幾個方面進行論述。

正文

2013 年 8 月，筆者作為項目經理參與XX省電子政務網一期工程的建設工作。該項目搭建省、市、縣、鄉各級政府電子政務辦公平臺以及移動辦公平臺，使全省行政機關通過電子政務平臺統一辦公，構建“一體化”政府的戰略而立項，是十二五期間省電子政務中的重點項目。一期項目的建設周期為26個月，從2013年8月開始，到2015年12月驗收結束，項目總投資為人民幣3200萬。該項目為了實現全省公務員跨地區、跨部門和跨層級的信息傳輸、公文傳輸、信息共享和業務協同。

該項目采用 B/S 結構，系統基于ORACLE11g數據庫的RAC共6個節點的集群，JAVA/JAVAEE多層體系結構，采用應用面向對象設計、面向服務（SOA）、面向接口技術、組件式開發技術，采用MVC、ORM、Web Service、AJAX技術。操作系統已Redhat的Linux6.5為主，以及微軟的Windows2008等，中間件采用IBM的WebSphere并做集群，終端以各單位的個人電腦以及智能終端。項目采用矩陣型組織結構，從各職能部門抽調主干成員，組成專門的項目團隊。我被任命為該項目的項目經理，負責項目的管理工作，直接向公司總經理報告。下面我將結合本項目從制定范圍管理計劃、定義范圍、創建工作分解結構、核實范圍、控制范圍這幾個方面對項目的范圍管理進行介紹。

一、制定范圍管理計劃

針對一些 IT 項目開發中，沒有制定范圍管理計劃，就進行范圍定義的問題，或者是邊定義范圍、邊制定計劃的情況，我們嚴格按照 PMBOK 的規范要求，尤其重視制定范圍管理計劃，制定范圍管理計劃看似花費大量時間，但沒有范圍管理計劃，以后的范圍管理工作就無章可依，出現范圍定義不清、范圍蔓延、范圍邊界不清等問題。

因此，在該項目中，我非常重視范圍計劃的制定，在正式做計劃之前，我先查找了公司組織過程資產，找出制定范圍管理計劃的模板，再結合以往項目的經驗，制定出一份初步的計劃，然后召集項目團隊成員討論，對計劃進行修改和完善，在全體參與下，最終完成一份 詳細的、科學的范圍管理計劃，用于指導項目如何定義、分解以及核實和控制范圍。

二、定義范圍

根據范圍管理計劃和項目章程等資料，項目組開始了范圍定義工作。在該工作中，我們尤其注意了干系人分析、專家判斷和產品分析等工具和方法的使用。該項目涉及從省辦公廳，省經信委、省信息中心等14個單位的工作人員，還有項目領導小組，干系人眾多，眾口難調，需求復雜。在項目的早期階段，我帶領團隊，到了客戶現場收集需求，我組織了客戶的電子政務部門、服務質量部門、信息中心以及我的需求團隊，召開需求討論會，共同商討項目范圍。通過前期的訪談，大多數電子政務工作人員對需要什么樣的系統功能，自身都沒有一個清晰的認識，針對這種情況，我們在干系人溝通中，演示了為其他集團開發的電子政務系統，通過實際操作，工作人員對系統功能有了感性認識，以這個系統為基礎，充分挖掘用戶的需求，并基于團隊自身的經驗以及專業水平，對客戶的需求進行引導、細化，將其模糊的概念形象化，粗糙的需求具體化。

基于需求文件，我召集項目的主要干系人進行開會討論，同時邀請了系統的最終用戶代表對系統功能做評價，通過用戶的角度，去發現和改進系統的功能，以此最終形成了完整的項目范圍說明書，主要包含：（1）項目目標：實現全省互聯互通，信息共享，業務協同，同時確定各子項目的成本、進度、技術和質量等要求；（2）產品范圍描述：包括人員和組織機構數據庫，統一認證系統，數據交換系統、公文與實務處理系統、門戶管理系統等；（3）項目邊界：該項目涉及數據交換，不涉及協調各單位數據等；（4）項目的可交互物：如項目管理報告和文檔等；（5）項目的驗收標準：系統運行穩定性，功能滿足業務要求，相關文檔齊全等；（6）項目的約束條件：如合同和項目章程中相關條款等；（7）項目的假設條件等。

三、創建 WBS

基于項目范圍說明書，我和我的團隊通過使用工作分解結構的模板開始對項目范圍進行分解，以形成該項目的 WBS。 在分解過程中，我按照以下原則進行分解。

（1）在各層次上保持項目的完整性；該項目涉及的項目管理、需求階段、系統設計開發階段試、系統集成階段、項目驗收階段等，避免遺漏必要的組成部分。

（2）一個工作單元只能從屬于某個上層單元；對于該項目中的數據庫設計，我就只將其歸入系統設計單元中，在其他單元不再重復出現，避免了交叉從屬。

（3）相同層次的工作單元應用相同的性質；對于系統設計單元下的數據庫設計、接口設計、系統設計等設計內工作，它們從屬性 上來講，都屬于設計，因此我將其一并歸入系統設計單元下。

（4）工作單元應能區分不同的責任者和不同的工作內容；對于該項目中每個工作包，我都指定唯一的負責人和其負責的工作內 容，便于項目管理進行計劃和控制的管理。

（5）便于管理和控制；對于該項目的每個工作包，我都對其進行編號， 并與組織結構圖和成本控制點深度融合，便于項目的日后管理。

（6）應包括項目管理工作，包括 分包出去的工作。

通過逐層分解，WBS 的最低層次的工作單元是工作包，同時對WBS進行編碼設計；對于該項目中工作單元，我參照 8/80 小時原則細化成具體的工作包，并指定具體的負責人。同時制作 WBS 詞典，對工作包做具體描述。

四、范圍核實

范圍確認并不是件容易的事情，在與客戶的溝通上，我們希望客戶盡快確認以便盡快開展后續的開發階段工作，而客戶則可能認為自己什么也沒看到，怎么確認呢？針對這種情況，我在提交文檔給客戶的相關干系人后，重點對客戶的 IT 人員進行溝通培訓，詳細介紹系統的設計，然后用他們的聲音去向客戶的業務部門做出介紹，這樣既有益于專業人員之間的技術溝通，也有益于客戶業務部門對系統范圍的認可與信任。同時，在與客戶的業務部門溝通時，我重點強調，雖然范圍確認是正式的，但這并不意味著項目的范圍就是鐵板一塊，不能再修改了，只要走標準的變更流程，且審批通過的，都是可以進行變更的。這樣就消除了客戶的顧慮，便于快速、高效地完成范圍確認。

五、范圍控制

控制范圍就是監督項目的范圍狀態，管理范圍基礎變更的過程。因此在項目中，我定期組織召開項目狀態審查會，審查項目的范圍，通過對照范圍基礎，找出范圍偏差，并做分析，嚴格杜絕一切的范圍蔓延以及鍍金。

例如，在一次狀態審查會上，我發現系統管理模塊多了登錄日志功能，我查了一下系統變更日志，未找到有類似的變更記錄，于是我參照責任分配矩陣，分別找到這兩個模塊開發的負責人詢問原因，A 成員告訴我，他增加登錄日志這個功能，是因為客戶在一次電話中，向他提過希望在系統管理模塊中加一個登錄 日志的功能，針對這種情況，我首先向這名成員強調了范圍基準以及變更流程的重要性；其次，針對這項多出來的功能，我要求相關人員提交正式的變更申請，走正常的變更控制流程。

從事項目管理工作的我深知，項目范圍不是一經定義，就一成不變的，項目干系人出于項目利益以及各種情況考慮，總會有一些需求變更，管理這些變更，需要在項目規劃時，就 制定好變更控制流程以及成立一個專門的需求變更控制委員會（CCB）。因此，我和我的團隊 在項目早期就制定了一套標準的變更流程：①提交變更申請；②評估變更；③報 CCB 審批；④實施變更并調整基準；⑤將變更信息通知相關干系人；⑥對變更的結果進行追蹤與審核。 有了這些流程以及 CCB 的控制，項目的需求變更得以良性發展，變更帶來更多的是項目利益以及效率的提升。

經過我和我的團隊不懈努力，該項目最終于2015 年 9 月試運行成功，并在同年 11月通過了客戶驗收小組的驗收，得到了甲方的好評。項目最終能成功完成，得益于我在項目中有效的范圍管理，采用科學的范圍管理方法、工具和技術，為項目的范圍管理帶來了事半功倍的效果。同時，在該項目的實施過程中，也 出現了一些問題，本人覺得處理得不是很好，主要在于項目中的沖突管理以及項目風險識別方面還存在不足，后續我將加強這兩個方面的學歷與知識積累，不斷提升自身項目管理水平，為中國電子政務行業的信息化發展添磚加瓦。