0引言
  項(xiàng)目管理是一項(xiàng)非常有挑戰(zhàn)性的工作,尤其是軟件項(xiàng)目管理。做項(xiàng)目管理的人都知道“項(xiàng)目三角形”法則,也就是制約項(xiàng)目的三個(gè)因素———時(shí)間、成本、范圍各構(gòu)成三角形的一邊,其中一個(gè)因素的變化必然引起另一個(gè)或者兩個(gè)同時(shí)發(fā)生變化,
例如項(xiàng)目要趕進(jìn)度(縮短項(xiàng)目時(shí)間),可以投入成本、增加人力,或者將原定計(jì)劃要實(shí)現(xiàn)的范圍縮小,如何做取舍就要靠項(xiàng)目經(jīng)理進(jìn)行權(quán)衡選擇。如果要做個(gè)譬喻,項(xiàng)目經(jīng)理不亞于是“在針尖上跳舞”的舞者,他甚至可能要在捉襟見肘的寸方三角形舞臺(tái)上導(dǎo)出一段“不可能完成任務(wù)”(mission impossible)的“群舞”。
1 范圍管理概論
  項(xiàng)目經(jīng)理如此不幸,而軟件項(xiàng)目經(jīng)理就更可以說是“不幸中的不幸”,因?yàn)楦鶕?jù)經(jīng)典數(shù)據(jù)統(tǒng)計(jì),軟件開發(fā)項(xiàng)目的成功率目前不超過50%,如果時(shí)光回退十幾年,這個(gè)數(shù)字會(huì)再低十個(gè)百分點(diǎn),而且對于規(guī)模越大的項(xiàng)目,其成功率越低。
到底是哪些原因?qū)е氯绱说偷某晒β?通過對過往失敗項(xiàng)目案例進(jìn)行整理和分析,人們生了問題才臨時(shí)采取行動(dòng),試圖迅速地解決問題。這樣的管理方式往往讓項(xiàng)目組很被動(dòng),也大大增加了管理成本,并使項(xiàng)目的進(jìn)度面臨很大的風(fēng)險(xiǎn),所以必須采用主動(dòng)式的風(fēng)險(xiǎn)管理模式,防患于未然。
發(fā)現(xiàn)其中一個(gè)主要的“敗因”是范圍管理失去了控制,從而引發(fā)“范圍蔓延”(Scope Creep),以這種方式失敗的項(xiàng)目表現(xiàn)為:項(xiàng)目已經(jīng)比原定計(jì)劃大大延期,客戶仍在源源不斷地有新需求,或者對已經(jīng)完成的功能提出各種修改意見,開發(fā)團(tuán)隊(duì)士氣低迷,總有完不成的開發(fā)任務(wù),項(xiàng)目預(yù)算已幾乎消耗殆盡,而距離項(xiàng)目收尾卻遙遙無期。
范圍管理難在何處?通過對以這類原因失敗的項(xiàng)目進(jìn)行分析和總結(jié),大致可以歸為客戶方和開發(fā)方兩大“責(zé)任方”。這里有兩種觀點(diǎn)。
(1) 責(zé)任在于客戶。這類觀點(diǎn)通常是由開發(fā)方“總結(jié)”得出的,經(jīng)常從開發(fā)方的技術(shù)人員口中聽到諸如此類的抱怨,“我們的客戶從項(xiàng)目一開始就不清楚需要做什么”,“他們總是在變,今天想要這個(gè),明天又想要那個(gè),更難以忍受的是他們的要求又往往是矛盾的”,
這種來自于客戶方的需求“模糊”以及“朝三暮四”,使得項(xiàng)目的范圍充滿了不確定性,而開發(fā)方頭上懸著“范圍”—“時(shí)間”—“成本”這一“項(xiàng)目三角形”達(dá)摩克利斯之劍,范圍的變動(dòng)就意味著項(xiàng)目開發(fā)周期的延長和成本增加,帶來的嚴(yán)重后果就是項(xiàng)目嚴(yán)重超支、項(xiàng)目延期難以交付而導(dǎo)致最終的項(xiàng)目失敗。
(2)責(zé)任在于開發(fā)方。幸運(yùn)的是開放方的責(zé)任并不是客戶“投桃報(bào)李”總結(jié)出來的,開發(fā)方擁有很好的自覺反省,自己道出了“苦水”。他們通常認(rèn)為,項(xiàng)目失敗很大的一個(gè)主因是范圍的定義不夠明確,做不到可量化、可驗(yàn)證的程度,因而在進(jìn)度和成本的量度和控制上面引發(fā)了多米諾效應(yīng),最后導(dǎo)致項(xiàng)目的“滑鐵盧”。
而為什么項(xiàng)目開發(fā)方的管理團(tuán)隊(duì)無法做到范圍界定明確的程度,原因有以下幾個(gè):
1)開發(fā)方缺乏規(guī)范的項(xiàng)目范圍管理過程是最主要的原因。比如缺少范圍評審環(huán)節(jié),開發(fā)方與客戶方無法在項(xiàng)目開頭就對項(xiàng)目范圍進(jìn)行很好的商討、澄清,并達(dá)成共識(shí)而且共同簽署范圍確認(rèn)書,給后來的范圍蔓延埋下隱患;
又比如開發(fā)方?jīng)]有對變更進(jìn)行有效的管理控制,在項(xiàng)目進(jìn)行過程中,面對客戶方“漫天要價(jià)”提出的后續(xù)需求缺乏有效變更系統(tǒng)加以辨別、遴選、記錄和處理,最終由“量變”引發(fā)“質(zhì)變”,項(xiàng)目范圍遠(yuǎn)遠(yuǎn)超出最初預(yù)計(jì)。
2)開發(fā)方缺乏正確的方法作為指導(dǎo)。這里的方法即指軟件工程領(lǐng)域中的方法,比如需求采集方法,也指項(xiàng)目管理中的方法,比如在范圍分解的時(shí)候,運(yùn)用正確的工作分解結(jié)構(gòu)(WBS)法進(jìn)行范圍劃分。
3)沒有使用必要的項(xiàng)目管理工具進(jìn)一步加強(qiáng)范圍管理以及其他管理活動(dòng),給項(xiàng)目成功帶來更高的保險(xiǎn)系數(shù)。典型的工具有微軟的Project 2000,以及IBM的統(tǒng)一項(xiàng)目管理平臺(tái)。
以上對范圍管理失控原因的總結(jié)和分析都很有道理,從中拿出任何一條,都可以在眾多失敗的項(xiàng)目中找到支持的佐證。為了解決范圍管理這個(gè)難題,項(xiàng)目管理協(xié)會(huì)(PMI)和軟件工程協(xié)會(huì)(SEI)都提出相應(yīng)的范圍管理體系。
PMI的項(xiàng)目管理知識(shí)體系指南(PM-BOK)對范圍管理的定義是“為了成功完成項(xiàng)目,需要確保項(xiàng)目包括所需的全部工作,但又只包括必須完成的工作的各個(gè)過程”,從這個(gè)定義可以得知PMI的范圍管理是一個(gè)過程管理,它關(guān)注的是在項(xiàng)目進(jìn)行過程中的各項(xiàng)工作活動(dòng)需要圍繞項(xiàng)目交付展開,既要包含所有必需的活動(dòng),
也不能包含不必要的活動(dòng),簡而言之就是不多不少(just-in-time)。PMI的范圍管理主要?jiǎng)澐譃槲鍌€(gè)過程展開,這五個(gè)過程分別是范圍規(guī)劃(planning)、范圍定義(definition)、范圍分解(break-down)、范圍核實(shí)(verification)以及范圍變更控制(con-trol),這五個(gè)過程是這么定義的。
(1)范圍規(guī)劃。規(guī)劃主要指的是實(shí)現(xiàn)范圍管理的策略,比如通過什么辦法來采集需求以得到項(xiàng)目范圍,以什么方式來進(jìn)行范圍分解等,范圍規(guī)劃相當(dāng)于整個(gè)范圍管理的一個(gè)計(jì)劃,這個(gè)過程主要是得出一份項(xiàng)目范圍管理計(jì)劃書。
(2)范圍定義。在范圍管理計(jì)劃的指導(dǎo)下,對要交付的項(xiàng)目制品進(jìn)行分析,或者對歷史同類項(xiàng)目制品進(jìn)行識(shí)別,編寫出一份項(xiàng)目范圍說明書。
(3)范圍分解。利用定義過程輸出的項(xiàng)目范圍說明書,按層次將項(xiàng)目制品分解成較小的可交付部分,同時(shí)也將項(xiàng)目工作分成較小和更便于管理的多項(xiàng)子工作,分解后得到一個(gè)樹狀分解結(jié)構(gòu),“根”代表項(xiàng)目,底層組成部分(“樹葉”)的計(jì)劃工作稱作“工作包”,
這些工作包可以安排在進(jìn)度表中,進(jìn)行費(fèi)用估算以及監(jiān)控。
(4)范圍核實(shí)。范圍核實(shí)將對上述過程產(chǎn)生的成果進(jìn)行評審,如開發(fā)方的項(xiàng)目管理委員會(huì)召開專家評審會(huì)議進(jìn)行范圍評估,范圍核實(shí)也包括在項(xiàng)目收尾階段客戶對項(xiàng)目制品進(jìn)行驗(yàn)收的過程。
(5)范圍控制。范圍控制將對造成項(xiàng)目范圍變更的因素施加影響,并控制變更造成的后果,PMI認(rèn)為變更是不可避免的,但是必須強(qiáng)制一定形式的變更控制過程,使得變更盡量可控。
綜合而論,PMI的范圍管理定義了一個(gè)過程棧,在這個(gè)過程棧中以上一個(gè)過程的輸出(通常是一個(gè)或多個(gè)文檔)作為輸入,采用組織既有的資產(chǎn)(比如文檔模板、表格、歷史項(xiàng)目數(shù)據(jù))以及方法(比如專家判斷)進(jìn)行處理,然后得到一份或多份結(jié)果文檔,
而這些結(jié)果文檔又可以作為下一過程的輸入。通過有序的過程將項(xiàng)目利益相關(guān)方以及有關(guān)資源組織起來,并且通過專家判斷、會(huì)議評審等方法,使項(xiàng)目范圍定義漸進(jìn)地得到明朗化,使其定義和分解較為全面與合理,達(dá)到可量化、可計(jì)劃、可控制的一個(gè)良好管理狀態(tài)。
2 軟件項(xiàng)目中的范圍管理
  PMI只對項(xiàng)目范圍的管理提供指導(dǎo),不涉及具體的應(yīng)用領(lǐng)域,比如軟件開發(fā)領(lǐng)域,因而PMBOK只是一個(gè)通用項(xiàng)目管理的指導(dǎo)體系,要完整地進(jìn)行范圍管理,還須結(jié)合特定的應(yīng)用領(lǐng)域加以運(yùn)用。對于軟件開發(fā)項(xiàng)目來說,項(xiàng)目制品指項(xiàng)目要交付的軟件產(chǎn)品,因?yàn)轫?xiàng)目范圍取決于產(chǎn)品范圍,
所以軟件的項(xiàng)目范圍管理依賴于軟件產(chǎn)品范圍管理,軟件產(chǎn)品范圍則來源于軟件的使用者———客戶對軟件所提出的需求。由于認(rèn)識(shí)到軟件需求的重要性,在20世紀(jì)80年代中期,從SEI中分離并形成了軟件工程的子領(lǐng)域———需求工程(Require-ment Engineering,RE)。
進(jìn)入到20世紀(jì)90年代,需求工程逐漸成為研究的熱點(diǎn)之一,1993年起每兩年舉辦一次需求工程國際研討會(huì)(ISRE),1994年起每兩年舉辦一次需求工程國際會(huì)議(ICRE)。此外一些關(guān)于需求工程的工作小組也相繼成立,
如歐洲的RENOIR(Requirements Engineering Network of International Co-operating Research Groups),并開始開展與需求工程研究有關(guān)的各項(xiàng)工作。需求工程研究使用已證實(shí)有效的技術(shù)、方法進(jìn)行需求分析,確定用戶需求,幫助分析人員理解問題并定義目標(biāo)系統(tǒng)的所有外部特征。
與軟件工程提出的生命周期類似,需求工程也有需求生命周期,它將最初用戶的設(shè)想和要求通過一系列過程,并采用適合的工程方法轉(zhuǎn)化為可以指導(dǎo)軟件開發(fā)的需求規(guī)格,并提出要對這些需求進(jìn)行相應(yīng)的管理以跟蹤和控制。
從上述特征來看,需求工程與PMI的范圍管理實(shí)質(zhì)上都是過程管理,而且重點(diǎn)在于各種說明詳盡的文檔編制,通過文檔來驅(qū)動(dòng)和指導(dǎo)開發(fā),以求做到任何的進(jìn)展和變動(dòng)都有文檔記錄和跟蹤,在開發(fā)流程和開發(fā)文檔的雙重保險(xiǎn)機(jī)制下,盡可能避免發(fā)生差錯(cuò),提高過程控制能力。
但是依靠過程式的管理是否完全適合軟件這樣一種特別的項(xiàng)目制品?是否能夠有效地對范圍進(jìn)行管理,以提高項(xiàng)目成功系數(shù)?回答這個(gè)問題可以從三個(gè)方面入手:第一,軟件這種制品有什么特征;第二,如何衡量一個(gè)軟件開發(fā)項(xiàng)目的成功;第三,管理的本質(zhì)又是什么。
先來看軟件這一特殊的項(xiàng)目制品,說它特殊是因?yàn)檐浖煌诳梢姷挠行挝锲?有形物品比如房屋、橋梁可以用計(jì)量單位和計(jì)量方法進(jìn)行描述和標(biāo)識(shí),比如建筑物的位置、高度、面積、體積及空間位置等,軟件則不然,軟件是運(yùn)行于計(jì)算機(jī)中的代碼,