淺析校園定格約拍系統項目范圍管理

胡必波+薛春楠

摘要：該文結合項目管理實踐經驗，圍繞“互聯網+時間”電商系統項目的范圍管理進行論述。首先，簡要分析項目范圍對項目的意義和進行項目范圍管理的主要過程。然后，詳細地介紹了我們在項目實踐中遇到工作分解結構過于細化，范圍確認客戶不配合、控制范圍時產生范圍蔓延等問題逐一化解，最終項目成功上線。最后對項目范圍管理中幾點不足作了總結。

關鍵詞：范圍管理；WBS；確認范圍；控制范圍

中圖分類號：TP393 文獻標識碼：A 文章編號：1009-3044（2017）28-0284-01

共享經濟時代，各種社會閑散資源正在得到有效利用。當你有一技之長或任何興趣愛好，你可以將你的技能、興趣明碼標價按照時間來收費，這就是時間電商的概念。伴隨移動互聯網技術的發展，這種基于互聯網+時間電商商業模式的第三類產業服務類O2O交易平臺逐漸興起，市場潛力預計有上千億元的規模。

本系統是由某市信息技術有限公司發起的以“興趣共享”為核心內容，涉及250多個職業分類，匯集5萬多提供個性化服務跨界達人的大型時間電商交易平臺。該系統采用云計算集群架構，可承載千萬級應用，具有實時份、高并發、高安全、平滑升級、永不掉線等特性。線上通過PC、微信、App等多個終端實現全網接觸，商家需要進行實名認證，交易雙方資金由平臺托管保障，線下掃碼確認完成交易。系統提供商家各類職業技能發布服務，同時，還有評價系統、投訴系統，類似淘寶的賣賣評論系統。

項目管理的“三項約束”范圍、時間和成本中，，項目范圍影響是很重要的，直接影響到項目時間和項目成本。為了控制項目按既定的時間、成本、質量完成項目目標，必須嚴格執行項目范圍管理，它包括確保項目做且只做成功完成項目所需的全部工作的各過程，定義和控制哪些工作應該包括在項目內，哪些不應該包括在項目內。項目范圍管理過程包括規劃范圍管理、收集需求、定義范圍、創建工作分解結構、確認范圍和控制范圍。

面對互聯網+時間電商交易平臺系統這樣建設周期長、干系人眾多、業務范圍涉及面廣，業務模式不統一的創業型項目，我作為項目經理，針對項目實施中遇到的：工作分解結構過于細化、范圍確認客戶不配合、控制范圍產生范圍蔓延等問題，一一化解。由于篇幅所限，本文就創建WBS，范圍確認和范圍控制結合實踐進行具體論述。

1 創建詳細工作分解結構

我們首先邀請公司相關領域的專家幫助，使用MSProject2013作為項目管理工具，采用三層WBS結構。PC、微信、App三個子系統作為WBS第一層；每個子系統的功能模塊作為WBS第二層，如PC網站包括：用戶模塊、商家模塊、網站管理模塊；以每個功能模塊的功能點作為WBS第三層，同時對WBS的每個任務明確了其可交付物。

由于系統涉及250多個職業分類，匯集5萬多個性化服務，WBS的分解粒度細化控制比較困難。我們組織項目組成員充分討論，依據范圍管理計劃、項目范圍說明書、需求文件等，將復雜的工作包大小控制在80小時內，每個任務都細化到每個人一周內可完成，保證每項任務都是可控的。同時制定完善的WBS字典，范圍變更計劃及規程、項目核實標準。詳細項目范圍說明書和范圍基準完成后，提交業務主管部門，經檢查和審核后確認，多方進行簽字確認，由項目組和業務管理單位共同實施。

2 與客戶緊密合作，確認項目范圍

作為承建方在項目每個階段末，自然希望客戶盡快確認項目可交付成果，以便開展后續相關工作。但客戶對項目可交付成果進行檢查、度量、核實時，總會有這樣或那樣的疑慮和想法。

例如在項目的某個階段末客戶檢查某次可交付成果后認為，原有的商家發布服務方式中服務時間設置不夠靈活只有單一時間模式可以選擇，提出應修改為服務有效期、固定服務時間、服務需預約等三種方式才能簽字接受。我們首先查閱項目管理計劃、需求文件、需求跟蹤矩陣表等文件發現之前定義的項目范圍并不包含這一客戶要求。然后我們與客戶進行良好溝通，告訴他們，尤其是客戶業務運營領導，確認范圍雖然是正式的，但并不意味著項目范圍不可更改，只是無論是現在還是將來更改范圍，都會引起項目的時間、進度和資源的變化?？蛻粢步邮芪覀兘ㄗh將這一范圍外計劃放到下一期項目進行，同意在“需求確認單”簽字留檔。最后我們也以此作為依據，繼續進入階段收尾過程。直到完成項目所有階段性成果的確認后，項目核實活動才算結束。

3 項目范圍跟蹤控制，避免范圍蔓延風險

控制范圍主要是監控項目范圍狀態、管理范圍基準變更的過程。引起項目范圍變更常見的原因有項目外部環境發生變化、范圍計劃不周密詳細，由錯誤或遺漏、市場上出現了或是設計人員提出新技術、新手段或方案、項目實施組織本身發生變化、客戶對項目產品或服務的要求發生變化等。未得到控制的變更通常被稱為項目范圍蔓延，它是項目失敗的原因之一。

如本項目在實施過程中客戶的業務運營部門的領導換了，原來的領導認可的東西，現任領導覺得不好，還需要增加用戶興趣愛好分享社區功能，并認為只需要增加少量的費用即可。我們很擔心按照這樣下去什么時候項目才能夠結束。本來計劃四月份就結束的工作，項目已經拖延了一個月。這一范圍變更是項目進展過程中所意料不到的。計劃改變了，人事也重新安排了。為了做出決策，我依據項目管理計劃、需求文件、需求跟蹤矩陣、工作績效數據，經過偏差分析并計算了這一變更所需的真實費用，列出了與這一變更申請相關的分解細目及全部成本，是原預計的兩倍有余。在得出項目所需的時間以及投入的精確估算后，經過溝通后，客戶最終采納了我們建議，取消變更請求，同意將有限資源運用在項目主要需求上，避免了項目范圍蔓延風險。

4 結論

在多方領導關懷下項目團隊團結協作，克服種種困難，如期完成項目。經客戶驗收，產品符合質量標準，獲得客戶好評?；仡櫾擁椖康姆秶芾磉^程，仍有不足之處。項目實施過程中由于不斷添加額外的工作而并不經過仔細的考慮，導致超出預算，延誤工期。這也提醒我們項目的漸進明細一定要在項目的邊界之內進行，以避免漸進明細演變成范圍潛變。項目團隊個別成員為了討好客戶、擅自承諾、送人情、好大喜功或者追求盡善盡美，干了許多不該自己干的活。我們應向團隊成員提倡給客戶提供你答應提供的東西，而不要多提供一些額外的東西，從而避免鍍金的產生。

參考文獻：

[1] 朱少民，韓瑩等.軟件項目管理 [M]. 2版.北京：人民郵電出版社，2015.

[2] 王雪峰. 淺談IT項目范圍管理[J]. 項目管理技術，2016（11）：66-68

[3] 劉榮杰.論信息系統項目范圍管理[J]. 信息技術與信息化，2015（8）：140-142.endprint