項目管理是一項非常有挑戰(zhàn)性的工作,尤其是軟件項目管理。做項目管理的人都知道“項目三角形”法則,也就是制約項目的三個因素———時間、成本、范圍各構成三角形的一邊,其中一個因素的變化必然引起另一個或者兩個同時發(fā)生變化。
　　例如項目要趕進度(縮短項目時間),可以投入成本、增加人力,或者將原定計劃要實現(xiàn)的范圍縮小,如何做取舍就要靠項目經理進行權衡選擇。如果要做個譬喻,項目經理不亞于是“在針尖上跳舞”的舞者,他甚至可能要在捉襟見肘的寸方三角形舞臺上導出一段“不可能完成任務”(mission impossible)的“群舞”。
　　1 范圍管理概論
　　項目經理如此不幸,而軟件項目經理就更可以說是“不幸中的不幸”,因為根據(jù)經典數(shù)據(jù)統(tǒng)計,軟件開發(fā)項目的成功率目前不超過50%,如果時光回退十幾年,這個數(shù)字會再低十個百分點,而且對于規(guī)模越大的項目,其成功率越低。
　　到底是哪些原因導致如此低的成功率,通過對過往失敗項目案例進行整理和分析,人們生了問題才臨時采取行動,試圖迅速地解決問題。這樣的管理方式往往讓項目組很被動,也大大增加了管理成本,并使項目的進度面臨很大的風險,所以必須采用主動式的風險管理模式,防患于未然。
　　發(fā)現(xiàn)其中一個主要的“敗因”是范圍管理失去了控制,從而引發(fā)“范圍蔓延”(Scope Creep),以這種方式失敗的項目表現(xiàn)為:項目已經比原定計劃大大延期,客戶仍在源源不斷地有新需求,或者對已經完成的功能提出各種修改意見,開發(fā)團隊士氣低迷,總有完不成的開發(fā)任務,項目預算已幾乎消耗殆盡,而距離項目收尾卻遙遙無期。
　　范圍管理難在何處?通過對以這類原因失敗的項目進行分析和總結,大致可以歸為客戶方和開發(fā)方兩大“責任方”。這里有兩種觀點。
　　(1) 責任在于客戶。這類觀點通常是由開發(fā)方“總結”得出的,經常從開發(fā)方的技術人員口中聽到諸如此類的抱怨,“我們的客戶從項目一開始就不清楚需要做什么”,“他們總是在變,今天想要這個,明天又想要那個,更難以忍受的是他們的要求又往往是矛盾的”,這種來自于客戶方的需求“模糊”以及“朝三暮四”,使得項目的范圍充滿了不確定性,而開發(fā)方頭上懸著“范圍”—“時間”—“成本”這一“項目三角形”達摩克利斯之劍,范圍的變動就意味著項目開發(fā)周期的延長和成本增加,帶來的嚴重后果就是項目嚴重超支、項目延期難以交付而導致最終的項目失敗。
　　(2)責任在于開發(fā)方。幸運的是開放方的責任并不是客戶“投桃報李”總結出來的,開發(fā)方擁有很好的自覺反省,自己道出了“苦水”。他們通常認為,項目失敗很大的一個主因是范圍的定義不夠明確,做不到可量化、可驗證的程度,因而在進度和成本的量度和控制上面引發(fā)了多米諾效應,最后導致項目的“滑鐵盧”。
　　而為什么項目開發(fā)方的管理團隊無法做到范圍界定明確的程度,原因有以下幾個:
　　1)開發(fā)方缺乏規(guī)范的項目范圍管理過程是最主要的原因。比如缺少范圍評審環(huán)節(jié),開發(fā)方與客戶方無法在項目開頭就對項目范圍進行很好的商討、澄清,并達成共識而且共同簽署范圍確認書,給后來的范圍蔓延埋下隱患;
　　又比如開發(fā)方沒有對變更進行有效的管理控制,在項目進行過程中,面對客戶方“漫天要價”提出的后續(xù)需求缺乏有效變更系統(tǒng)加以辨別、遴選、記錄和處理,最終由“量變”引發(fā)“質變”,項目范圍遠遠超出最初預計。
　　2)開發(fā)方缺乏正確的方法作為指導。這里的方法即指軟件工程領域中的方法,比如需求采集方法,也指項目管理中的方法,比如在范圍分解的時候,運用正確的工作分解結構(WBS)法進行范圍劃分。
　　3)沒有使用必要的項目管理工具進一步加強范圍管理以及其他管理活動,給項目成功帶來更高的保險系數(shù)。典型的工具有微軟的Project 2000,以及IBM的統(tǒng)一項目管理平臺。
　　以上對范圍管理失控原因的總結和分析都很有道理,從中拿出任何一條,都可以在眾多失敗的項目中找到支持的佐證。為了解決范圍管理這個難題,項目管理協(xié)會(PMI)和軟件工程協(xié)會(SEI)都提出相應的范圍管理體系。
　　PMI的項目管理知識體系指南(PM-BOK)對范圍管理的定義是“為了成功完成項目,需要確保項目包括所需的全部工作,但又只包括必須完成的工作的各個過程”,從這個定義可以得知PMI的范圍管理是一個過程管理,它關注的是在項目進行過程中的各項工作活動需要圍繞項目交付展開,既要包含所有必需的活動,也不能包含不必要的活動,簡而言之就是不多不少(just-in-time)。PMI的范圍管理主要劃分為五個過程展開,這五個過程分別是范圍規(guī)劃(planning)、范圍定義(definition)、范圍分解(break-down)、范圍核實(verification)以及范圍變更控制(con-trol),這五個過程是這么定義的。
　　(1)范圍規(guī)劃。規(guī)劃主要指的是實現(xiàn)范圍管理的策略,比如通過什么辦法來采集需求以得到項目范圍,以什么方式來進行范圍分解等,范圍規(guī)劃相當于整個范圍管理的一個計劃,這個過程主要是得出一份項目范圍管理計劃書。
　　(2)范圍定義。在范圍管理計劃的指導下,對要交付的項目制品進行分析,或者對歷史同類項目制品進行識別,編寫出一份項目范圍說明書。
　　(3)范圍分解。利用定義過程輸出的項目范圍說明書,按層次將項目制品分解成較小的可交付部分,同時也將項目工作分成較小和更便于管理的多項子工作,分解后得到一個樹狀分解結構,“根”代表項目,底層組成部分(“樹葉”)的計劃工作稱作“工作包”,這些工作包可以安排在進度表中,進行費用估算以及監(jiān)控。
　　(4)范圍核實。范圍核實將對上述過程產生的成果進行評審,如開發(fā)方的項目管理委員會召開專家評審會議進行范圍評估,范圍核實也包括在項目收尾階段客戶對項目制品進行驗收的過程。
　　(5)范圍控制。范圍控制將對造成項目范圍變更的因素施加影響,并控制變更造成的后果,PMI認為變更是不可避免的,但是必須強制一定形式的變更控制過程,使得變更盡量可控。
　　綜合而論,PMI的范圍管理定義了一個過程棧,在這個過程棧中以上一個過程的輸出(通常是一個或多個文檔)作為輸入,采用組織既有的資產(比如文檔模板、表格、歷史項目數(shù)據(jù))以及方法(比如專家判斷)進行處理,然后得到一份或多份結果文檔,而這些結果文檔又可以作為下一過程的輸入。通過有序的過程將項目利益相關方以及有關資源組織起來,并且通過專家判斷、會議評審等方法,使項目范圍定義漸進地得到明朗化,使其定義和分解較為全面與合理,達到可量化、可計劃、可控制的一個良好管理狀態(tài)。
　　2 軟件項目中的范圍管理
　　PMI只對項目范圍的管理提供指導,不涉及具體的應用領域,比如軟件開發(fā)領域,因而PMBOK只是一個通用項目管理的指導體系,要完整地進行范圍管理,還須結合特定的應用領域加以運用。對于軟件開發(fā)項目來說,項目制品指項目要交付的軟件產品,因為項目范圍取決于產品范圍,所以軟件的項目范圍管理依賴于軟件產品范圍管理,軟件產品范圍則來源于軟件的使用者———客戶對軟件所提出的需求。由于認識到軟件需求的重要性,在20世紀80年代中期,從SEI中分離并形成了軟件工程的子領域———需求工程(Require-ment Engineering,RE)。
　　進入到20世紀90年代,需求工程逐漸成為研究的熱點之一,1993年起每兩年舉辦一次需求工程國際研討會(ISRE),1994年起每兩年舉辦一次需求工程國際會議(ICRE)。此外一些關于需求工程的工作小組也相繼成立,如歐洲的RENOIR(Requirements Engineering Network of International Co-operating Research Groups),并開始開展與需求工程研究有關的各項工作。需求工程研究使用已證實有效的技術、方法進行需求分析,確定用戶需求,幫助分析人員理解問題并定義目標系統(tǒng)的所有外部特征。
　　與軟件工程提出的生命周期類似,需求工程也有需求生命周期,它將最初用戶的設想和要求通過一系列過程,并采用適合的工程方法轉化為可以指導軟件開發(fā)的需求規(guī)格,并提出要對這些需求進行相應的管理以跟蹤和控制。
　　從上述特征來看,需求工程與PMI的范圍管理實質上都是過程管理,而且重點在于各種說明詳盡的文檔編制,通過文檔來驅動和指導開發(fā),以求做到任何的進展和變動都有文檔記錄和跟蹤,在開發(fā)流程和開發(fā)文檔的雙重保險機制下,盡可能避免發(fā)生差錯,提高過程控制能力。
　　但是依靠過程式的管理是否完全適合軟件這樣一種特別的項目制品?是否能夠有效地對范圍進行管理,以提高項目成功系數(shù)?回答這個問題可以從三個方面入手:第一,軟件這種制品有什么特征;第二,如何衡量一個軟件開發(fā)項目的成功;第三,管理的本質又是什么。
　　先來看軟件這一特殊的項目制品,說它特殊是因為軟件不同于可見的有形物品,有形物品比如房屋、橋梁可以用計量單位和計量方法進行描述和標識,比如建筑物的位置、高度、面積、體積及空間位置等,軟件則不然,軟件是運行于計算機中的代碼,它不是有形實體,無法進行嚴格而且形象的量化。軟件要模擬并解決人在現(xiàn)實世界中發(fā)生的活動事務,而人的活動與事務又是千差萬別,不同組織不同人其行事方式各有不同,期待的結果也不一,這就是具備相同功能的同一個軟件產品不能完全適用于所有客戶的原因,用軟件行業(yè)術語講需要進行“本地化”和“客戶化”以滿足不同需求。軟件所能滿足的對象就是所說的客戶,軟件的生產者即開發(fā)方,一個軟件從最初的想法到具體構思,再到設計和實現(xiàn)這一系列過程,需要客戶向開發(fā)方描述所要構建的是一個什么樣的系統(tǒng),
　　將解決和能解決什么問題,最終達到什么樣的一個效果,這個過程需要雙方的溝通,以達成對要構建系統(tǒng)的較為一致的認識。但是正如我們熟知的,在溝通的過程中,人們所處的觀察角度不同,思考方式不同,表達方式也不盡相同,這都會導致信息在傳達過程中發(fā)生丟失與變形,會出現(xiàn)客戶所想不是開發(fā)方所做的這么一種狀況,有人將客戶與開發(fā)方這種矛盾做了有趣的比方,“客戶奢望得到一張沙發(fā),開發(fā)人員卻提供一條板凳;客戶僅要求得到一把椅子,開發(fā)人員卻提供了一張豪華沙發(fā)”。也正是這種矛盾,才會出現(xiàn)客戶方在軟件需求上面為什么會“朝三暮四”,因為第一,客戶方對要做什么是一個由淺入深的過程,剛開始需求提出少是因為認識不夠,隨著項目深入其認識也逐步加深,對于系統(tǒng)要構建成什么樣子更加明朗化,自然需求就提得越多;
　　第二,項目是一個過程,它跨越一個時間階段,在這個階段中客戶的活動方式和事務內容往往會發(fā)生變化,在這個時候軟件的開發(fā)也隨之發(fā)生變化是一個再自然不過的事情,而且規(guī)模越大、時間跨度越大的項目就越是要面臨這種挑戰(zhàn)。
　　再反觀過程式管理,該管理模式要求項目一開始就能較清楚地確定要完成事項的大致范圍,進而安排計劃進度,確定投入的成本與資源,顯然這與軟件這一特殊項目制品漸進和反復式的構建特點以及構建過程有相違的地方。
　　過程式管理理論源于20世紀初的機器工業(yè)生產時代,管理的對象是機器化作業(yè)流程以及流程中的生產者,典型的代表是流水線作業(yè),這種管理對于固定生產方式是非常有效的,因為一旦作業(yè)流程和單位人員生產效率確定之后,輸入和產出間有一個線性關系,自然也就可以進行量化和計劃,并通過計劃來指導和管理生產,投入成本、產量、交付時間等可以做到比較準確而沒有多大偏差,但是由于軟件制品的上述產品特征以及其漸進的過程特征,這種線性管理模式比較難發(fā)揮作用,因為從一開始它就缺乏準確的量化作為輸入,并且計劃一旦形成,就很難再適應后續(xù)需求的變化。
　　再來看一個軟件項目如何才算成功,由于軟件項目牽涉兩方,那么自然成功的衡量標準是同時滿足兩方的期待?？蛻舴绞擒浖a品的投入者,其期待自然就是產出,這種產出從商業(yè)角度講就是獲得價值,無論這種價值是以什么樣一種方式提供,比如客戶通過軟件產品節(jié)約運作成本,提高工作效率,或者是給用戶提供更好的服務質量,增強企業(yè)競爭力,直接產生經濟效益等。對于軟件開發(fā)方來說,作為一個商業(yè)實體其期待是通過項目獲取開發(fā)利潤,能否獲取到預期的利潤自然又回到“項目三角形”這個簡單的原理,當項目的范圍、時間、成本符合計劃預期時,項目可以獲得最大的贏利,反之如果這三個因素有一個增大,利潤就減少,因此開發(fā)方的項目經理顯然更操心的是計劃制訂的合理性,希望范圍能夠定得準確,希望計劃能夠做得完美,希望變更不要太多,希望項目進展一如預期。然而正如人們常說的,世間沒有兩全其美的事,“魚與熊掌不可兼得”,而且應該可以看到客戶方和開發(fā)方兩邊的期待其實暗含一種此消彼長的邏輯關系,那么假定在極端情況下,如果只可以確保一方的利益,應該優(yōu)先考慮哪一方呢?無論是從“甲方乙方”這個簡單商業(yè)原則,或者從項目最終是為了提供特定產品、服務、成果這個宗旨來看,應該優(yōu)先考慮的是客戶這一方,因為只有在客戶取得成功、實現(xiàn)增值目標的前提下,開發(fā)方才獲得真正意義的最大“利潤”。
　　從一些著名的項目實例可以找到對這一選擇的支持,“銥星”是摩托羅拉耗費巨資投入的一個項目,盡管項目進展一如預期,但是這個項目最終卻沒有給摩托羅拉帶來商業(yè)上的成功,這無疑是個徹頭徹尾失敗的項目;電影《泰坦尼克號》的拍攝嚴重超支超時,早期被批評家認為2億美金打了水漂,但是最后卻成為全球第一部超過10億票房收入的電影,毫無疑問這是一個經典的成功項目。過程式管理強調計劃、控制,而審慎詳盡的計劃往往耗時費力,又難免遇到范圍信息輸入較少這樣的尷尬境界,因而如果項目經理死守一份僵化的計劃,為了維護“項目三角”關系,有意無意地利用事先設置的種種流程環(huán)節(jié)以拖延、回避、拒絕合理的范圍變更,所導致的嚴重后果勢必是交付給客戶一個不符合期待、不能創(chuàng)造價值的平庸軟件產品,甚至可能成為客戶日常作業(yè)的“累贅”,或者是“食之無味”的“雞肋”。應該找到一種管理方法,使得項目既能滿足客戶的要求,又能為客戶帶來真正的價值,并且使客戶方與開發(fā)方實現(xiàn)一種“雙贏”的合作方式,很顯然單獨依靠過程管理難以做到這點。最后來看管理的本質。無論軟件是如何一種特殊的制品,其管理仍是通常意義“管理”中的一種,它的管理目標、管理方法應該與通常意義的“管理”一致。
　　對于“管理是什么”這樣一個深奧的本體論話題,誕生了百年的管理學界仍無法形成統(tǒng)一的看法,盡管如此,對于管理包含什么,具備什么職能,實現(xiàn)什么目標還是比較明確。管理存在于人類社會,自從出現(xiàn)了群體以及發(fā)生了共同勞動,就出現(xiàn)了管理,管理將獨立分散的生產要素結合起來,以完成特定群體即組織的共同目標,并且在實現(xiàn)這個共同目標的過程中,管理可以并且必須充分發(fā)揮各個組織以及成員的潛能。軟件開發(fā)說其特殊,是因為其主要的“生產要素”是人,不像一個生產流水線,軟件生產甚至不需要提供一個固定的生產空間—廠房,軟件生產可以是分布在地球任何角落的一個或者多個個體———程序員或者開發(fā)組織;也不需要強制規(guī)定工作時間,因為有些開發(fā)人員的晚上工作效率往往高于白天;軟件生產的產出并不是線性的,當遇到技術難題的時候,開發(fā)人員會被擱置在難點攻關上而不產生任何可見的成果,比如一行代碼,如果在思維活躍的時候,開發(fā)人員又可能會變得異常高效,他可以在幾天當中完成原計劃需要半個月甚至更長時間的任務。“軟件產品開發(fā)主要基于人”這樣一個最大的生產特性被過程式管理所忽略,因為過程式管理的一個出發(fā)點和作用是防范整個過程體系中有個別人能力不足或者由于人員流失而給組織帶來損失,防范由于人的自由性使事情偏離預想軌道,因此通過在一系列過程中安排檢查點及時進行糾偏,并且設置層級的組織結構對此進行制約。過程式管理在生產型組織中做得非常成功,但在軟件項目開發(fā)中并沒有預期的理想,因此軟件開發(fā)應該需要這么一個管理體系,它能夠發(fā)揮人的主觀能動性,激發(fā)團隊合作潛能,實現(xiàn)客戶提出的有價值的業(yè)務“思維”,開發(fā)出軟件這樣一種“純思想”的制品,最終提供客戶價值。這個更能適合軟件項目開發(fā)的管理體系需要引入的是“敏捷”。