系統(tǒng)集成項目管理工程師知識點：南方移動項目案例解析(范圍管理)

1)規(guī)劃項目范圍管理過程

“這個項目的工作范圍應該是明確的、固定的（《技術規(guī)范》我還沒看過呢）”一一王東對范圍管理沒有給予應有的重視。

王東又打電話問負責這個合同的銷售代表老楊：關于接入的準備工作當初跟局方是怎么定的、怎么交待的，老楊說：“哎呀小李，你不找我我還想找你呢，簽完合同就不知道這個項目怎么樣了。你說各地市的接入準備工作嗎？他們說是他們負責的呀，我就沒多管，你是不是該督促他們一下??？”——實際上，項目的范圍邊界很不明確。

2)收集需求過程

“小凌和另外兩位局方的人員針對未來的網(wǎng)管系統(tǒng)各個功能分別提出他們的想法，李鵬就跟他們談并逐一作記錄。雖然談需求進行得不是很有規(guī)律，最后需求分析還是按時完成了，得到了一份關于該項目網(wǎng)管系統(tǒng)的需求說明。該說明對系統(tǒng)的各個功能、使用方法都提出了要求，有些要求非常具體”——需求不只是做記錄，這是典型的被動式需求調研，或守株待兔式需求調研。

3)定義范圍過程

“李鵬告訴王東說這份需求文擋的內容雖然有些方面提得比較細，但有不少地方跟《技術規(guī)范》不一致，想商量商量怎么處理。最后他們覺得這份需求有些地方是對《技術規(guī)范》的發(fā)展，有些地方是細化，體現(xiàn)了局方現(xiàn)在對網(wǎng)管系統(tǒng)的實現(xiàn)要求，與其到測試或驗收時再處理，還不如現(xiàn)在就考慮”——不符合《技術規(guī)范》的內容，怎么能納入需求呢，如果用戶堅持，應啟動變更程序，變更合同附件《技術規(guī)范》。

4)創(chuàng)建WBS過程

“項目工作鋪開后大家才發(fā)現(xiàn)項目的工作沒有原來計劃的那么簡單，有些工作在原WBS中是沒有的，還有不少工作是計劃外的，這都占用了項目成員的很多精力。王東習慣性地感嘆：“意外太多了！怎么我們做的每一個項目都有這么多意外，原來做出來的計劃就沒有辦法順當?shù)貓?zhí)行下去，計劃沒有變化快??！”這樣項目計劃就沒辦法按原來的進度要求走下去了，原來每個人的正常工作節(jié)奏全都被打亂了，每個人都很忙”——WBS分解的一個重要原則就是不能遺漏任務，一個遺漏的任務會摧毀整個進度計劃。項目中的意外通常有兩個來源：一是遺漏的任務，二是未識別的風險。顯然，案例中的意外主要來源于任務遺漏，比如：國外采購設備的到貨時間問題，“郭處知道了設備到貨時間的問題后問王東：你們公司沒有去考慮過這個問題嗎？”

5)確認范圍過程

“系統(tǒng)演示出的功能與《技術規(guī)范》不一致，最后的驗收將以《技術規(guī)范》為標準”一一項目經理要盡早搞清楚：誰負責驗收、驗收標準是什么、誰有驗收表決權或評判權。

6)控制范圍過程

“局方領導在觀看軟件演示時多次提出了修改意見。對于這些意見李鵬提出這屬于項目范圍變更，要求按變更來處理。但郭處說這不是范圍變更，軟件功能本來就該做成這樣子，是開發(fā)組理解錯了，不存在變更不變更的問題。為了能夠說服郭處，李鵬和王東詳細查閱了《技術規(guī)范》，結果悲觀地發(fā)現(xiàn)在很多地方《技術規(guī)范》并沒有清楚描述要做成什么樣，所以很難判定局方的意見是不是屬于變更。既然是這樣就只有滿足局方的要求了?！薄枨笫恰都夹g規(guī)范》的細化，查《技術規(guī)范》當然沒用了；需求收集完成后，應要求用戶進行確認（是否是他們想要的軟件功能），確認后的需求成為需求基線，若要變更就需要走變更控制流程了。

“局方提出的這些意見有的跟《技術規(guī)范》一致、有時不一致，一開始我和李鵬還想部分頂住，但因為局方領導層次較高，我覺得他要是震怒可能公司領導一定又會很緊張，同時也不希望因為我不同意滿足局方的要求讓局方向高層領導投訴，這樣會讓我很被動”——這是因為局方領導不知道他們的要求與技術規(guī)范相違背，有必要提醒他們；《技術規(guī)范》是驗收標準，最終項目驗收還是要按照《技術規(guī)范》來。

“這種對修改要求的滿足一旦開始就很難停止，這樣項目就陷入了很被動的循環(huán)，剛把上次的要求改好了，想回復正常的開發(fā)節(jié)奏，新的一輪又開始了。這讓我覺得就像轉輪里的小白鼠，自己永遠不知道什么時候是盡頭，直到累死為止，而外人覺得你在干你該干的事情?！薄褂玫Ｐ突蛎艚莘椒?，每8天一個迭代周期，先開發(fā)優(yōu)先級高、穩(wěn)定性強的需求。