“項目”，在二千多年之前就已經(jīng)存在。著名的埃及金字塔、我國的萬里長城都是國際上眾人稱頌的典型項目。項目管理發(fā)展到今天，應(yīng)用相對成功的領(lǐng)域主要是在土木工程上，現(xiàn)已逐步應(yīng)用于軟件工程、航空、國防、金融、體育等行業(yè)。
一般來說，“項目”具有技術(shù)復(fù)雜，參與的人員還眾多，時間又非常緊迫，因此，人們開始關(guān)注如何有效地實行項目管理來實現(xiàn)既定的目標(biāo)。在這里，主要談?wù)勗谲浖こ填I(lǐng)域中項目管理的運用，也就是項目管理能夠給人們提供一種解決問題的思路和方法。
I. 當(dāng)前項目管理存在的問題
一項調(diào)查表明，大約70%的軟件開發(fā)項目超出了估算的時間，大型項目平均超出計劃交付時間20%至50%，90%以上的軟件項目開發(fā)費用超出預(yù)算，并且項目越大，超出項目計劃的程度越高。國內(nèi)絕大多數(shù)的IT企業(yè)正或多或少地承受著“項目黑洞”的痛楚：項目無法按期完成、項目合作方的工作難以協(xié)調(diào)、用戶需求經(jīng)常變動、工作質(zhì)量難以保證。很多企業(yè)常常抱怨說，我們的技術(shù)實力不比國外差，我們的員工也很努力，但是我們的產(chǎn)品和工作效率為什么總比不上國外？
諸如此類的問題，就是當(dāng)前軟件開發(fā)中，實現(xiàn)項目管理實施時帶來的問題。雖然，項目管理在土木工程中，項目管理在中國已經(jīng)實施得十分成熟。但是，軟件開發(fā)不同于其他產(chǎn)品的制造，軟件的整個過程都是設(shè)計過程（沒有制造過程）；另外，軟件開發(fā)不需要使用大量的物質(zhì)資源，而主要是人力資源；并且，軟件開發(fā)的產(chǎn)品只是程序代碼和技術(shù)文件，并沒有其他的物質(zhì)結(jié)果?；谏鲜鎏攸c，軟件項目管理與其他項目管理相比，有很大的獨特性。其問題的具體表現(xiàn)為：
一、工期失控，計劃失控。項目做多，往往會形成一種錯覺：不按計劃工期完成的項目是正常的；能按計劃工期準時完成的，往往是不正常的。這說明，項目的實際工期和計劃工期不符，是“家常便飯”。大多數(shù)工期延期，很少提前的。工期延期、失控，自然而言會導(dǎo)致計劃無法執(zhí)行；計劃無法執(zhí)行，成本就失控；產(chǎn)品就會變形．．．．．．
二、項目前期多數(shù)出現(xiàn)“沒事做”，后期“沒人做”。在項目啟動后，因為人員的配置，人員的銜接，硬件的配置，客戶需求的確定性，一般會造成很多人“沒事做”。而有些事是必須放在項目前期做的。前期不做，會對中后期有很大的影響?；蛘叻诺街泻笃谧觯瑫?，要多花幾倍的人力、物力。到了項目后期，會出現(xiàn)“虎頭蛇尾”，大量的事情需要人來做，項目的人員又是固定的，其他人因為不了解整個項目，無法“空降”，則只能刪除一些事情咯。這樣就造成很多事情，沒人做，后果可想而知。
三、開發(fā)人員心態(tài)失控。延期，趕進度；晚上加班。還是延期，星期六也加班吧。
還是不能按期完成，又到項目后期，只好封閉開發(fā)。平時晚上加班，星期六、星期天也加班。這就是很多開發(fā)人員開發(fā)項目漸進式的流程。不同項目的開發(fā)人員，只要問問對方是否加班，就大概可以了解到對方參加的項目的開發(fā)階段拉。先拋棄加班對開發(fā)人員的效率的影響，對開發(fā)人員心態(tài)的影響才是最重要的。每個人都有趨利弊害的天性，開發(fā)人員也不例外。既然要趕進度，效率沒有提高的情況下，要縮短開發(fā)時間，那只有簡化功能，減少處理異常的情況，能把功能完成再說，等以后測試或用戶哪里出問題再說。如果僥幸不出問題，那就沒問題拉。這種情況下，當(dāng)然希望測試的水平越“水”越好拉。哦，別忘了，測試也是開發(fā)人員的一部分。工期延期了，上面要求的進度又越來越緊，測試時間就更短，強度大，那只有有意無意去逃避錯誤，這樣就皆大歡喜拉。
這些共性的問題，就是項目管理所要解決的問題。只有解決了這些問題，項目管理水平就會得到質(zhì)的飛躍！當(dāng)然要解決這些問題，不是一兩篇文章，一兩個公司就能解決的，需要所有人的不斷探索才能解決的。這里，主要是個人的一些思考，供大家參考。
II. 定位問題
有人會問，產(chǎn)品或項目的需求不就是包含了定位，何須重復(fù)講呢。其實，這是一個誤區(qū)。同樣一個需求，在一個中學(xué)生中實現(xiàn)和在一個大學(xué)生中實現(xiàn)是完全不同的；在一個有經(jīng)驗的群體中實現(xiàn)和在一個缺乏經(jīng)驗的群體中實現(xiàn)是完全不同的。有些項目，由于定位未做好，未開始注定是失敗的，無論是需求分析得如何好，編碼、測試控制得十分完美，終究逃不過失敗這一關(guān)。
做軟件的都知道，是沒有真正的軟件。即使是通用做的最好的WINDOWS，也不可能是通用到每一類人，每一個國家，每一個民族的人，通用到那些只有幾千人的少數(shù)民族。因此，一個項目的定位是十分重要的。
產(chǎn)品和項目的定位是不一樣的。做項目不比賣產(chǎn)品，產(chǎn)品賣出就是成功，項目投產(chǎn)才算成功；產(chǎn)品是靜態(tài)的，項目是動態(tài)的；產(chǎn)品質(zhì)量有問題可以包換、保修，項目一旦失敗，時間不能倒流，客戶損失的可能就是市場競爭優(yōu)勢和機遇。
對于用戶定制的項目，定位相對簡單，只要了解到定制用戶的使用范圍，使用者的知識結(jié)構(gòu)、行業(yè)經(jīng)驗、電腦的基本知識及是否用過相關(guān)軟件即可。特別地，如果是用過相關(guān)地軟件，一定要了解清楚，哪些操作、功能是必須保留地，哪些操作、功能是可以修改或必須修改的。一段用戶的已習(xí)慣了某種辦法、操作方式，是很能更改的，如果定制的項目不遵照用戶的習(xí)慣進行開發(fā)，在軟件的運行初期，往往會出現(xiàn)很多意想不到的問題。此外，還必須注視用戶方人員流動、機構(gòu)變化造成的影響。
對于產(chǎn)品的開發(fā)，定位則相對復(fù)雜些。由于產(chǎn)品的使用者是不確定的，是預(yù)測的。因而產(chǎn)品的定位顯得特別重要。國內(nèi)的產(chǎn)品，是不存在通用產(chǎn)品的。通用，只相對于某些大行業(yè)或某個行業(yè)而言。有些產(chǎn)品，號稱是通用產(chǎn)品，既不能使通用領(lǐng)域的用戶滿意，更不能使專用領(lǐng)域的用戶滿意，是一個徹底失敗的產(chǎn)品。相反，一些產(chǎn)品，一開始就定位于某個行業(yè)，某個細分的行業(yè)，反而做的很好，用戶量比所謂的通用的產(chǎn)品的用戶量還要多。
如產(chǎn)品定位于專用，必須考慮，專用的范圍，是否能進一步細分，在細分的基礎(chǔ)上，所屬范圍的特征，有哪些情況是不適用，哪些情況是適用的等等。對范圍的特征分析得越清楚，定位越準確，產(chǎn)品失敗得概率就越少。同理，對于定位于通用的產(chǎn)品，就是將要通用所屬的范圍的同性提取出來?；趪鴥?nèi)軟件水平的現(xiàn)實，做通用產(chǎn)品，應(yīng)該是基于某些專用范圍，再兼顧其他的范圍，即以專用范圍為主。因此，定位的準確，是確保項目成功的底線（Bottom Line）之一。
III. 項目經(jīng)理及與開發(fā)人員的溝通
項目經(jīng)理類似于電影中的英雄人物，是項目的靈魂，他的一舉一動影響著項目的成敗。在危難時刻，優(yōu)秀的項目經(jīng)理甚至可以力挽狂瀾。眾所周知，衡量項目經(jīng)理一般是以在資質(zhì)、素質(zhì)、能力和經(jīng)驗等作為主要的依據(jù),即統(tǒng)籌能力、領(lǐng)導(dǎo)能力、交往能力、處理壓力、解決問題的能力和技術(shù)能力。但是，個人認為，項目經(jīng)理的心態(tài)才是決定一個項目成敗的關(guān)鍵因素。當(dāng)然，能力和經(jīng)驗也會影響項目經(jīng)理的心態(tài)。
一般出任項目經(jīng)理，要么是由開發(fā)骨干兼任(這在中、小型項目中很普片)，要么是由銷售或其他部門空降，專職項目經(jīng)理。這兩種方式都有各自的弊端。專職項目經(jīng)理，專做項目管理而不做任何分析、設(shè)計、編碼、測試等具體的技術(shù)實施工作，就會感覺“沒事做”，或是在打雜；開發(fā)骨干，由于主要或全部精力均忙于具體技術(shù)工作，各種項目管理任務(wù)（如：項目分析/評估、項目計劃的制定/檢查/調(diào)整、上下左右的溝通、專業(yè)資源調(diào)配、項目組織調(diào)整、項目財務(wù)控制、風(fēng)險分析/對策等）不可避免地疏于顧及，項目管理的事情“沒人做”，導(dǎo)致項目控制的問題“積勞成疾”，后悔莫及。
專職項目經(jīng)理，在項目管理過程中，一般比較注重對外的聯(lián)絡(luò)合作方面，即比較注重和銷售、用戶，其他部門的協(xié)調(diào)工作。相反，就會對技術(shù)及開發(fā)的技術(shù)重視不足。在很多情況下，只根據(jù)用戶、銷售確定的功能、工期來安排計劃，對相應(yīng)的技術(shù)難點不理解，每項功能所耗費的時間估計出現(xiàn)很大偏差，對每個開發(fā)人員的技術(shù)、知識水平認識不透徹。因此會造成有些任務(wù)需要強制、壓迫才能完成，開發(fā)人員不是建立在心服口服的情況下完成的。正所謂，上有政策，下有對策。開發(fā)人員都是高智商的動物，騙“外行”就更容易了。一般都是采取虛報工作難度，把本來一天能做完的，拖到一個星期，十天才做完；或者把正常要半個月才能做完的工作，在上面“強制”要求下，壓縮到一個星期做完，當(dāng)然拉，其中必然要偷工減料，只有極正常的操作才能會滿足要求，對非法操作，特殊情況的處理，項目經(jīng)理或測試工程師發(fā)現(xiàn)一個才處理一個。不能發(fā)現(xiàn)的，就等用戶去發(fā)現(xiàn)。項目的實施情況就可想而知拉。
在這種情況下，必須做到幾點：
一、 從開發(fā)人員的角度出發(fā)，結(jié)合市場的角度確定項目的功能，動之以情，曉之以理，盡量使開發(fā)人員心服口服地開發(fā)某個功能。
二、 由項目組討論確定每一項功能的開發(fā)耗時，以不是通過拍腦袋的方式確定耗時；
三、 加強測試；
四、 加強對開發(fā)人員責(zé)任心、成就感的教育。
技術(shù)骨干擔(dān)任的項目經(jīng)理，不可避免地存在著“技術(shù)崇拜”，盡可能采用新技術(shù)。即使是需求明確的功能，由于實現(xiàn)方式有多種路徑，一般都是從技術(shù)上采取最優(yōu)的路徑，而不是從用戶操作方便的角度上選擇操作最方便、快捷的路徑，用戶必須嚴格按開發(fā)人員所預(yù)設(shè)的操作方式進行操作。說句老實話，用戶是不管你用什么技術(shù)的，先進或落后的技術(shù)都可以，只要能滿足用戶的需求即可。這種類似閉門造車生產(chǎn)出來的產(chǎn)品，自然就是操作不便，功能差強人意的。還有一種情況是，這種情況一般發(fā)生在項目后期，開發(fā)產(chǎn)品的情況較多，隨著開發(fā)的深入，總會發(fā)現(xiàn)缺少某些功能，或者某些功能不夠強大。項目經(jīng)理對功能的增加、刪除、修改，不是通過集體討論確定或通過從市場前線人員中了解確定，而是通過憑空想象，拍腦袋來作出決定。特別是對于某些功能的添加，由于項目經(jīng)理都無法把握用戶是否需要這個功能，需要這個功能的程度，因此是很難令開發(fā)人員把握此功能的目的。當(dāng)然，既然大家都無法把握用戶是否會用這個功能，那自然是應(yīng)付式開發(fā)。只要過了測試，過了項目經(jīng)理這一關(guān)就OK拉。
初當(dāng)項目經(jīng)理的人，經(jīng)驗不足是必然的，這并不是構(gòu)成產(chǎn)品、項目失敗的關(guān)鍵因素，心態(tài)才是主要的。新官上任三把火，而且還是懷著“感謝黨，感謝組織，感謝領(lǐng)導(dǎo)”，有著一顆報恩的心態(tài)當(dāng)上項目經(jīng)理，自然就事事追求完美，沒有缺陷。但是，理想和現(xiàn)實是永遠都有很大的差距的。學(xué)會取舍才是項目、產(chǎn)品成功的因素，也是項目經(jīng)理走向成熟的關(guān)鍵。
成熟的項目經(jīng)理，應(yīng)確保項目實施中業(yè)務(wù)參與的全面性、深度和權(quán)威性。
在一、二十年前，也許您會經(jīng)常聽到某位大俠單獨完成了某種創(chuàng)舉，成了人們崇拜的對象?？山裉欤@種大俠，已經(jīng)很難有生存空間了。取而代之的是，某軍團，又攻克了一座什么樣的堡壘。這樣，溝通，可以說已經(jīng)變得無比的重要。在軟件業(yè)，溝通可以說是快速學(xué)習(xí)和掌握新知識，達到技術(shù)上的更高層次的最佳途徑。因此，無論是項目，管理都必須在以人為本的前提下進行，必須重視溝通。
以人為本，指的不只是軟件開發(fā)人員這一部分。這里的人主要指的是一些與項目有利害關(guān)系的一些人，即項目干系人(stakeholders)，一般包括客戶或者用戶、項目團隊、項公司的管理層等一些主要的利害關(guān)系者。 一個項目能否成功，很大程度上取決于能不能分清楚這些項目利害關(guān)系者各自對項目的影響，能不能利用好這些人力資源，溝通協(xié)調(diào)好他們之間的關(guān)系。
溝通是掌握各方信息，進行項目決策和項目協(xié)調(diào)的基礎(chǔ)，也是項目管理的基本內(nèi)容。項目經(jīng)理最重要的工作之一就是溝通，通?；ㄔ谶@方面的時間應(yīng)該占到全部工作的75%～90%。良好的交流才能獲取足夠的信息、發(fā)現(xiàn)潛在的問題、控制好項目的各個方面。盡早溝通、主動溝通就是其中的兩個原則?？傊疁贤ㄊ且婚T很重要的學(xué)問，在項目管理中也有專門的溝通管理，因而在本文中我們就不再討論了。
項目經(jīng)理只有以人為本，重視溝通，才會避免出現(xiàn)以下的情況：客戶在檢查項目階段成果時，指出曾經(jīng)要求的某個產(chǎn)品特性沒有包含在其中，并且抱怨說早就以口頭的方式反映給了項目組的成員，糟糕的是作為項目經(jīng)理的你卻一無所知，而那位成員解釋說把這點忘記了；或者，你手下的程序員在設(shè)計評審時描述了他所負責(zé)的模塊架構(gòu)，然而軟件開發(fā)出來后，你發(fā)現(xiàn)這和你所理解的結(jié)構(gòu)大相徑庭．．．．．．

IV. 產(chǎn)品的需求、系統(tǒng)分析、設(shè)計
總的而言，軟件開發(fā)主要分為六個階段：需求分析階段、概要設(shè)計階段、詳細設(shè)計階段、編碼階段、測試階段、安裝及維護階段。開發(fā)軟件就如八股文一樣：總體規(guī)劃、項目立項、需求分析、系統(tǒng)分析、系統(tǒng)設(shè)計、編碼實現(xiàn)、項目測試、文檔制作（八股文：破題、承題、起講、入手、起股、中股、后股、束股），一切都按部就班。同理，信息系統(tǒng)集成項目管理一般的過程分為：需求分析、項目調(diào)研、方案論證、實施方案、具體實施、測試、驗收、售后服務(wù)。同時項目管理按管理的方式可以分為售前、售中和售后。
在國內(nèi)，做的項目越多，就越容易產(chǎn)生這樣的感覺：項目感覺總是做不完，就像一個“無底洞”。用戶總是有新的需求要項目開發(fā)方來做，就像用戶在“漫天要價”，而開發(fā)方在“就地還錢”。 實際上，這里涉及到一個“范圍管理”的概念。項目中哪些該做，哪些不該做，做到什么程度，都是由“范圍管理”來決定的?！胺秶芾怼钡南嚓P(guān)知識，可以參考項目管理知識體系指南、項目管理九大知識體系的相關(guān)內(nèi)容。這里只說說兩點，核心需求和需求的變更。
一般說來，需求對用戶來說，可以分為核心需求和輔助需求。對于中國貪心的用戶來說，功能從來不嫌多的。核心需求就是用戶使用本軟件是，一定會使用的功能，沒有這些功能，會影響用戶的忠誠度。輔助功能，就是用戶可用可不用的功能。有了這些功能，用戶更喜歡，沒有這些功能，用戶不會太在意，或者是可以容忍。同樣一個軟件，不同的用戶，核心需求和輔助需求是不一樣的。在一個項目產(chǎn)品中我們應(yīng)該知道對方需要什么，自己要做什么，這是項目成功的基礎(chǔ)所在。
對于產(chǎn)品，因為用戶是不確定的，確定哪些需求是核心需求，哪些是輔助需求，則比較難。但是如果定位合理，對定位的用戶范圍的特征分析得準確，則不是什么太難得事。但無論是產(chǎn)品還是項目，都必須考慮以下三點：1、對于用戶提出的每個需求都要知道“為什么”，并判斷用戶提出的需求是否有充足的理由，并考慮由此而引申出來的問題，觸類旁通，舉一反三；2、對于用戶提出的每個需求都要知道“為什么”，并判斷用戶提出的需求是否有充足的理由；3、分析由用戶需求衍生出的隱含需求，并識別用戶沒有明確提出來的隱含需求（有可能是實現(xiàn)用戶需求的前提條件），這一點往往容易忽略掉，經(jīng)常因為對隱含需求考慮得不夠充分而引起需求變更。
需求確立后，重要的是規(guī)范化，文檔化，可參考常用的需求建模的方法如數(shù)據(jù)流圖（DFD）、實體關(guān)系圖（ERD）和用例圖（Use Case）三種方式。
需求的變更是不可避免的，如何以可控的方式管理軟件的需求，對于項目的順利進行有著重要的意義?，F(xiàn)在，重要的不是限制需求的變更，而是讓用戶、銷售、開發(fā)都明白，不管是哪種情況下變更，只要是造成變更的一方，都要背負相應(yīng)的責(zé)任。這就需要一個明確的約束機制。在制定制度時，大家都可以參議，提意見。但只要制度確定了，就必須恪守這個制度，是制度管人，而不是領(lǐng)導(dǎo)管人。也只有這樣，才不至于開發(fā)處于遙遙無期的狀態(tài)，而到最后則草草收兵。
本人認為，需求的確定可以分為三個階段則比較合適，這樣劃分也涉及到計劃、成本的管理，可參考后面的相關(guān)內(nèi)容。
一、 項目初期，用戶、銷售、開發(fā)三者，應(yīng)根據(jù)WBS方法確定整個項目的整體需求，即最起碼要確定WBS中最頂層的父作業(yè)，如需求一，需求二．．．．．． 并盡可能詳細地確定需求地具體劃分，如需求一.1，需求一.2，需求二.1，需求二.1.（1）．．．．．．對于開發(fā)周期比較長的項目，則可以確定每個需求開發(fā)開始的大概時間，周期比較段的項目，則只需確定整個項目的開始時間即可。對沒有確定的需求，則要明確在開發(fā)前一個相應(yīng)的時間，必須在確定的時間之前來落實詳細的需求。對已確定的需求則明確在開發(fā)前的一個具體時間內(nèi)可以修改的內(nèi)容，主要是框架性的需求。
二、 項目開發(fā)前，核實項目的所有需求，應(yīng)當(dāng)包括詳細的需求，并明確告知用戶以后只能修改細節(jié)上需求，主要是操作上的需求。如果在以后要修改框架性的需求，必須受到一定的約束，所產(chǎn)生的成本必須為要變更的一方負責(zé)。如是因為開發(fā)的原因造成的，則增加成本納入到項目的成本中；如因銷售工程師因銷售壓力而盲目對用戶作承諾的功能，則相應(yīng)成本必須納入銷售成本中；確定落實需求后，進行項目的開發(fā)階段。
三、 項目開發(fā)完成后，提交給用戶試用。用戶使用后，用戶明確要修改的內(nèi)容，主要范圍是操作上，細節(jié)的實現(xiàn)是否與需求一致，是否與用戶真正需要的一致。如要對框架性的需要修改，則必須按先前的約束條件進行。確定修改內(nèi)容后，向用戶明確，以后的修改內(nèi)容都只能局限于當(dāng)前提出的修改范圍，當(dāng)然，程序出錯除外。開發(fā)進行修改，用戶使用，將修改范圍進一步縮少。一次或多次迭代后，項目完成。
V. 工作量的估算及評價
項目管理最大的難度，就是每一模塊的工作量、開發(fā)時間的確定，這也是項目實施的主要風(fēng)險，最難預(yù)測、控制的風(fēng)險。
比較常用的估算方法有：估計項目交付日期的方法有很多，如基于經(jīng)驗的估計、基于模型的估計等。一種簡便易行的估計方法是采用Wideband Delphi估計方法，此方法可以降低不同人員所作估計的偏差?；谀Ｐ偷墓烙嫹椒▌t包括KLOC、FPA以及COCOMOⅡ等模型。在這里主要引用新的估算方法，以供參考。
如果，公司有著類似項目實施的豐富經(jīng)驗，則工作量、開發(fā)時間的確定則會更切實際。
首先，提取公司內(nèi)部數(shù)據(jù)，統(tǒng)計出類似模塊的工作量（M公）、開發(fā)時間（S公）。如果，公司沒有這方面的經(jīng)驗，那如何辦呢？不做這一步？！對，沒辦法，沒時間時也可以放棄這一步。有時間，有精力時，可以通過了解社會對類似模塊的工作量、開發(fā)時間的平均值再結(jié)合本公司的情況進行假設(shè)模塊的工作量、開發(fā)時間。
其次，項目開發(fā)成員對這一模塊的工作量、時間的估算。這一步是最耗時，這是很多公司都沒有去做的，包括國內(nèi)一些知名的軟件公司。軟件開發(fā)，不是工廠中的流水線生產(chǎn)，可以對產(chǎn)品的生產(chǎn)過程中每一個過程，每一個步驟，進行嚴格的控制和限制。在開發(fā)過程中，由于開發(fā)人員不同的學(xué)歷背景、知識水平、經(jīng)歷、開發(fā)經(jīng)驗、對模塊的理解程度、思維方式、編程習(xí)慣等因素，對同樣的模塊，所需求的工作量，開發(fā)時間是有很大區(qū)別的。因此，需要每個開發(fā)成員對相關(guān)模塊了解熟悉后，進行估計，再根據(jù)不同的系數(shù)，通過不同的公式進行轉(zhuǎn)換后確定每一個模塊的工作量、開發(fā)時間。
公式為：M＝M（公）*X1+M(項)*X2;
S＝S（公）*X1+S(項)*X2;
M(項)＝M（開1）*Y1+M(開2)*Y2+…+ M(開n)*Y.n;
S(項)＝S（開1）*Y1+S(開2)*Y2+…+ S(開n)*Y.n;
每一模塊，每項功能完成后，對小于原定工作量或成本的，可以直接以原工作量和成本作為考核的依據(jù)。對于超出原定工作量或成本的，必須組織相關(guān)人員進行成本、工作量的評估。主要的操作方法為，組織3到5人的評估小組，小組成員盡可能是在開發(fā)時對要評估模塊相當(dāng)熟悉的成員。小組成員利用一定的時間了解評估模塊的代碼，功能特點，模塊實現(xiàn)思路，難點，簡單的單元測試等，然后小組的成員假設(shè)是成員本人來開發(fā)評估模塊，需要用的成本、工作量并轉(zhuǎn)換為開發(fā)人員相應(yīng)級別的工作量、成本，最后綜合小組成員的估計的工作量、成本和開發(fā)人員開發(fā)時所耗費的成本、工作量進行加權(quán)平均，得出最后的成本、工作量，并以此作為考核的依據(jù)。
VI. 計劃的編排
有人這樣形容計劃的，“計劃，計劃，紙上畫畫，墻上掛掛，計劃不如變化，計劃不頂領(lǐng)導(dǎo)一個電話。！”。根據(jù)美國Hackett公司的一項調(diào)查發(fā)現(xiàn)，只有37%的信息化項目在計劃時間內(nèi)完成，只有42%的信息化項目在預(yù)算內(nèi)完成。計劃很容易成為空話，特別是在軟件工程中，影響計劃的因素太多，計劃就形同虛設(shè)了！但是，項目管理方法的主體就是項目計劃、計劃優(yōu)化方法,其目的就是綜合各種因素，制定合理的計劃，并通過計劃的實施，使其規(guī)范化，從而提高項目的效益，提高人員效率，降低項目的成本。
圍繞著項目計劃方法，可以把項目管理方法分為四個發(fā)展階段：Gannt圖階段、確定性網(wǎng)絡(luò)計劃技術(shù)階段，如關(guān)鍵路徑法CPM（Critical Path Method）等、概率型網(wǎng)絡(luò)計劃技術(shù)階段，如計劃評審技術(shù)PERT (Program Evaluation and Review Technique)和多因素隨機網(wǎng)絡(luò)計劃技術(shù)階段，如考慮資金因素的PERT/COST，考慮活動風(fēng)險的圖評審技術(shù)GERT(Graphics Evaluation and Review Technology)和風(fēng)險評審技術(shù)VERT(Venture Evaluation and Review Technology)，以及多種資源（資金、人力等）約束下的網(wǎng)絡(luò)優(yōu)化等等。無論項目管理發(fā)展到哪一階段，本人認為計劃要合理，合乎以后項目實施的實際情況，以下三點是前提：
一、 對計劃的態(tài)度問題。如果計劃只是為了讓上面的頭頭看看，放在墻上掛掛。那基本上這些計劃也就是沒什么意義的計劃，不說也罷。這些計劃不是小數(shù)。筆者曾經(jīng)看過這樣的計劃，某位同事出差在外面兩周，但在最新的計劃中，還有本周必須在公司完成的開發(fā)任務(wù)。這種計劃，一經(jīng)編排就意味著無法完成，或者要進行變更。還有，筆者親身經(jīng)歷的，在收到的計劃中（是8月15號制定的），已安排筆者在8月15號前的一個星期完成某一項工作。本人是在8月15號后才知道要完成這項工作的，自然就無法按時完成拉。這樣的例子還有很多，不勝枚舉。
二、 對計劃的編排要做到有粗有細。
傳統(tǒng)的計劃編制是這樣的：首先對項目進行估算，粗算出項目的總體進度。然后進行精化：確定概要設(shè)計階段、詳細設(shè)計階段、編碼階段、測試階段、安裝及維護階段等階段的具體要求、完成時間、投入人力物力，并確定幾個關(guān)鍵階段。這些關(guān)鍵階段的要求進度必須在指定日期之前完成。最后充分考慮影響項目計劃的因素，并做出相應(yīng)的措施，做出項目進度表，列出在每個階段的難點要點，要注意的問題。，并將需要分析階段的內(nèi)容和項目計劃、進度表整理成文檔，分發(fā)到相關(guān)人員手上。
這樣的計劃編制，在土木工程等運用項目管理比較成熟的行業(yè)時，還算相當(dāng)成功，但具體運用到軟件開發(fā)上，很多時候，就會出現(xiàn)變形，走樣。例如有些計劃，真是很細致，很細致，甚至細分到小時，分鐘。這樣的計劃很難執(zhí)行，只要外界有變化，或者前面的計劃出現(xiàn)誤差，則這個計劃就完了。有些計劃，很粗，很粗，粗到只有時間點，只有大框架，沒有具體的內(nèi)容。在實施時，根本無法知道具體怎樣做。這樣的計劃，一般被稱為里程碑式的計劃，比較適合領(lǐng)導(dǎo)對計劃的檢查。
在國內(nèi)，軟件開發(fā)中，計劃的制定，比較常用的方法為WBS方法，即將項目工作分解為更小、更易管理的工作包也叫活動或任務(wù)，這些小的活動應(yīng)該是能夠保障完成交付產(chǎn)品的可實施的詳細任務(wù)。首先就是周密地做好范圍計劃編制；然后以項目進度為依據(jù)劃分WBS，第一層是大的項目成果框架，每層下面再把工作分解，這種方式的優(yōu)點是結(jié)合進度劃分直觀，時間感強，評審中容易發(fā)現(xiàn)遺漏或多出的部分，也更容易被大多數(shù)人理解。其中，這部分內(nèi)容運用專門的項目管理軟件比較適合。Microsoft的項目管理工具Project就可以自動為各個層次的任務(wù)編碼，國內(nèi)的項目管理軟件中，同望EasyPlan不但具有自動編碼功能，還可以在甘特圖，單網(wǎng)圖，雙網(wǎng)圖三種視圖下快速編制計劃圖，并可對計劃、資源、成本費用的優(yōu)化，進行跟蹤比較，盈余分析等等，是一個不錯的軟件。
但是，WBS方法的前提是，對軟件開發(fā)所涉及的業(yè)務(wù)要比較熟悉，有多年的經(jīng)驗；要求涉及人員的流動性小，管理模式要穩(wěn)定。人對事物的認識是有一個過程的，不同的階段有不同的認識。因此，對一個計劃來說，計劃前期盡可能細化每一項工作，越具體越好。對于以往計劃執(zhí)行得比較好得的公司，項目受到外界干擾比較少的項目，前期計劃可以細化到日，或半天。對執(zhí)行得一般的項目，可以細化到兩天、三天或一周。對執(zhí)行得比較差，或者容易受到外界影響的項目，如項目組成員要經(jīng)常出差，或支援其他項目，或者要中斷進行前面項目的維護工作等等，可以細化到旬、半個月，最好不要超過一個月，否則計劃失去其本來的意義。對計劃后期工作的制定，則可以比較粗些，用以適應(yīng)前期計劃執(zhí)行情況造成的變化。
當(dāng)然，這樣的計劃，也要避免采取每周制定下周工作計劃的逐周項目計劃方式，避免“項目失控合法化”。項目計劃的Breakdown或曰“粒度”，是一個需要小心把握平衡的問題。越細則控制力度越大（筆者曾見過細到0.25小時/人的），但項目管理的成本越高；反之亦然。以國內(nèi)目前的狀況，個人看法，項目的周期越長，應(yīng)越粗。項目周期為三到六個月的，可以粗到一周或半個月。周期為一到兩年的，則可以粗到一個月，一個季度。無論多大的項目，應(yīng)該也不要超過半年。
三、關(guān)鍵線路的制定。一般來說，先確定關(guān)鍵工作，整個項目的關(guān)鍵線路。然后，確定非關(guān)鍵工作。最后通過甘特圖（橫道圖），網(wǎng)絡(luò)圖（單代號網(wǎng)絡(luò)圖，雙代號帶邏輯時標(biāo)的網(wǎng)絡(luò)圖）找出自由時差、總時差，并通過縮短關(guān)鍵線路的工期來對項目進一步優(yōu)化。在這里，最重要的，關(guān)鍵線路的資源，即關(guān)鍵線路中的關(guān)鍵工作是由哪個開發(fā)人員負責(zé)。現(xiàn)在的項目管理工作中，存在這樣一個誤區(qū)，整個項目的關(guān)鍵路線通常是由一兩個開發(fā)精英、骨干、核心來承擔(dān)。這樣存在很大的風(fēng)險。當(dāng)開發(fā)核心在項目中途離職或者不得不暫停開發(fā)工作，如生病，出差等，會造成整個項目延誤，而其他開發(fā)人員窩工。同時，一個人長期處于高壓下工作，當(dāng)前工作延誤了，導(dǎo)致整個項目的延誤；下一個工作延誤了，又導(dǎo)致整個項目的延誤。反正已經(jīng)連續(xù)延誤了，就無所謂了，做到哪里就算哪里好了，整個人崩潰了，對開發(fā)計劃確定的時間就放棄了，從而形成一人加班，全員加班。因此，一個好的計劃，出關(guān)鍵線路合理外，還必須時關(guān)鍵線路有多個人員在不同時段進行承擔(dān)，避免一兩個人長期承擔(dān)整個關(guān)鍵線路，同時，還要預(yù)料，還有哪些因素影響，使某些非關(guān)鍵工作會上升為關(guān)鍵工作，成為關(guān)鍵線路，影響整個關(guān)鍵線路。
VII. 計劃的執(zhí)行、變更
影響計劃執(zhí)行的因素可以分為主觀因素和客觀因素?？陀^因素有客戶相關(guān)風(fēng)險，外部環(huán)境的影響，停電，機器損壞，不能上網(wǎng)等原因。主觀因素有：人的因素、技術(shù)因素，資源因素。如果項目計劃的Breakdown或曰“粒度”不符合實際情況，也是影響計劃執(zhí)行的因素。
設(shè)立里程碑，加強項目進度的檢查（與進度計劃比對）和控制，維護項目計劃的嚴肅性，是規(guī)避計劃執(zhí)行風(fēng)險的一個有效辦法。但這是不夠的。只有建立合理、實用的計劃，計劃的執(zhí)行才會有可能。依照前面所提到的計劃編排原則，那計劃的執(zhí)行應(yīng)是這樣進行的。在執(zhí)行計劃A時，應(yīng)先審查計劃B的內(nèi)容，利用WBS方法，確定計劃B的內(nèi)容是不可再細分，需求在現(xiàn)階段是否要作進一步的調(diào)整，功能點是否要刪除、修改、添加等等，然后再確定計劃B的具體執(zhí)行時間，粗略調(diào)整由此引發(fā)后面的計劃的變更。換句話說，也就是，迭代計劃B，使計劃B更你能滿足現(xiàn)實的情況。計劃B的具體執(zhí)行時間已經(jīng)制定，就是“死的”，不允許作調(diào)整，必須想盡一切辦法按時、按質(zhì)完成計劃。因為這時計劃是比較符合實際的，不能按時按質(zhì)完成，不是態(tài)度問題，就是效率問題。完成計劃A，在執(zhí)行計劃B時，迭代計劃C……通過執(zhí)行，迭代，完成整個計劃?？傊褪鞘褂媱澨幱谙鄬討B(tài)中，不是靜態(tài)，也不是動態(tài)的，頻頻變化，要避免“項目失控合法化”。
一個項目的范圍計劃可能制訂的非常好，但是想不出現(xiàn)任何改變幾乎是不可能的。因此對變更的管理是項目經(jīng)理必備的素質(zhì)之一。在這里，我們定義在執(zhí)行計劃A前，對計劃B的修改，稱為調(diào)整；執(zhí)行計劃A后直到完成計劃B中對計劃B的修改，稱為計劃的變更。從常識來說，對計劃的調(diào)整，相對而言，成本的變化不大。因此，計劃的調(diào)整是約束最少的，只要有合理的理由，對整個系統(tǒng)沒有特別大的影響，都可以進行調(diào)整。相反，對計劃變更的約束是最大的，不是哪個人，哪個領(lǐng)導(dǎo)拍個腦袋，想怎么變更就怎么變更的。誰變更，誰就應(yīng)該負擔(dān)變更所引發(fā)的成本。在變更之前，應(yīng)該進行集體討論。這時，千萬要避免項目領(lǐng)導(dǎo)閉著門，想個三天兩夜，然后對眾人來個宣布，決定要怎樣怎樣變更。這時，來個“一言堂”，項目很容易失敗的。談?wù)摃r，要明確以下目的：一，為什么要變更？二，可不可以通過其他方法來彌補，而不需要變更？三，要變更，是最少的，最優(yōu)的變更嗎？？四，變更造成的成本差，具體由誰來負擔(dān)，這一定要明確，不能模糊。總之，抓住一個宗旨：能不變更就不變更，能少變更就少變更，變更了就應(yīng)該有具體的人員來負擔(dān)相應(yīng)的責(zé)任、成本。一般來說，可以變更的原因有客觀原因和主觀原因?？陀^原因，如項目組成員計劃外出差，生病，公司大型活動等等而造成無法按計劃執(zhí)行，這時的變更所造成的成本，則只能有公司來負責(zé)或整個項目組來負責(zé)。主觀原因，即使是加班加點，提高工作效率，也無法按計劃時間來執(zhí)行計劃。這種情況，是制定和調(diào)整計劃的人沒有做好，需求的功能比較模糊，細化得不徹底，難點估計不足。這種情況下的變更，則計劃的制定和調(diào)整者，應(yīng)負擔(dān)相當(dāng)大的責(zé)任和成本，開發(fā)人員所負擔(dān)的責(zé)任和成本則相應(yīng)小一些。如果是由于開發(fā)人員的責(zé)任心不夠而造成的變更，則開發(fā)人員要負擔(dān)大部分的成本，開發(fā)人員的領(lǐng)導(dǎo)也要負擔(dān)一小部分的成本。
不管怎么樣，只要變更確定了，就應(yīng)該嚴格執(zhí)行，絕對要避免同一內(nèi)容一而再，再而三地進行變更，使計劃成為擺設(shè)。這時，對計劃地對計劃地執(zhí)行，應(yīng)該是專制的，“一言堂”式地進行。

VIII. 測試及產(chǎn)品的收尾階段
目前市場競爭的激烈和市場的成熟度不足，可能導(dǎo)致應(yīng)用開發(fā)項目的惡性競爭風(fēng)險?？蛻粝Ｍ锩纼r廉而加需求、壓價格、壓進度；廠商惟恐出局而拍胸脯、打包票。這是很多項目經(jīng)理面臨的類似的情況，特別是在項目后期。

到了項目后期，主要是在進度和軟件質(zhì)量取得一個平衡點。在實際的項目質(zhì)量管理中，質(zhì)量管理總是圍繞著質(zhì)量保證(Quality Assurance)過程和質(zhì)量控制(Quality Control)過程兩方面。質(zhì)量管理就不在這里展開，主要還是說說，編碼等的修改和進度與系統(tǒng)測試的關(guān)系。
一般而言，隨著項目的深入，環(huán)境各方面的變化，具體實現(xiàn)總是和原先的設(shè)計或多或少地出現(xiàn)偏差。這是很正常，不必驚慌。原則上是，能不修改則盡可能不修改。實在要修改，則只要不是原則性的錯誤，盡量不要推倒前面所做的一切，重新做，畢竟以前做的時候也是考慮了方方面面的因素的，現(xiàn)在出現(xiàn)的問題只是在某方面考慮不周而已，一切都作廢，太浪費了。還有，要是數(shù)據(jù)庫字段已存在，除非萬不得已，千萬不要修改數(shù)據(jù)庫字段，實在不行就添加字段。因為已經(jīng)存在的字段，很有可能已被軟件開發(fā)小組的其他成員在使用，不要因為你的修改而令其他人也要跟你做相應(yīng)的修改。最后，軟件界面的修改要慎重，界面的修改很容易使你忽略修改相應(yīng)的內(nèi)容，造成軟件大問題沒有，小問題一大堆。要盡量避免出現(xiàn)以下兩種情況：一，不顧進度、成果，盡量修改，務(wù)必做到盡可能和預(yù)設(shè)功能一致；二，為了盡快完成項目，以時間點為準，做些表面修改，也就是不負責(zé)任的修改，以求盡快完整，早日解脫這個項目的苦海。這種情況，在管理過程中，出現(xiàn)波折，有大量、頻繁的修改的項目，出現(xiàn)得特別多。

到了項目后期，迫于公司、用戶的壓力、或者項目本身已經(jīng)延遲了，盡早結(jié)束整個項目，就是自然而言的事情了。大多數(shù)的做法是，壓縮系統(tǒng)測試時間。系統(tǒng)測試的時間少了，發(fā)現(xiàn)的問題也就少了，時間就更加可控了。這樣做，也沒大錯，但必須注意，如在系統(tǒng)測試發(fā)現(xiàn)的大部分問題是low的，則壓縮系統(tǒng)測試時間問題都不大；如發(fā)現(xiàn)的問題有相當(dāng)一部分是影響使用的，比較hight的，則不能壓縮系統(tǒng)測試時間，甚至要延長系統(tǒng)測試時間。不要抱著現(xiàn)在先混過驗收測試，等以后有時間再詳細測。從我了解的情況來說，這是不可能的，只要一過了驗收測試，不管是程序員，還是測試員，其心態(tài)都已經(jīng)發(fā)生變化了，不可能全身心投入測試、修改中。即使是勉為其難投入，其效率就可想而知拉。不管怎樣，進行系統(tǒng)測試時，
最后的修改，必須預(yù)備一定的時間進行較全面的測試，以避免修改而引發(fā)的錯誤，特別是簡單的錯誤。經(jīng)驗告訴我們，很多低級錯誤，都是在最后修改時引入的，因為預(yù)料測試時間不足而沒有被發(fā)現(xiàn)。
到了項目后期，即使是進度延誤得十分厲害，建議還是不要增加成員。因為，新成員得加入，熟悉業(yè)務(wù)需要，了解、理解業(yè)務(wù)需要一定的時間，除本身所消耗的時間外，還會有意無意地損耗其他成員的時間，造成進度的進一步拖延，等完全熟悉時，能上手，可能就是項目結(jié)束之日。此外，還會因為不熟悉，而引入新的錯誤，新的不穩(wěn)定因素。
到了項目后期，除了進度的執(zhí)行外，也要特別重視和相關(guān)人員的溝通及處理相應(yīng)的關(guān)系。主要溝通人員有：用戶方的項目管理人員、用戶方的業(yè)務(wù)人員、用戶方的決策層、開發(fā)方的項目管理人員、開發(fā)方的軟件編程人員等。主要的關(guān)系有：用戶方與開發(fā)方的關(guān)系、用戶方項目管理人員與使用人員(業(yè)務(wù)人員)及決策層的關(guān)系、項目管理人員與軟件編程人員的關(guān)系、硬件與軟件的關(guān)系、性能與靈活的關(guān)系。

這樣，整個項目才會取得成功?。?BR>