項目計劃的關(guān)鍵因素有哪些

    IT項目管理跟其它工程項目管理最大的一個不同就是人的管理，項目成員不是簡單的機器，人員的知識技能，團隊建設(shè)，項目溝通等內(nèi)容往往是項目管理的一個很關(guān)鍵內(nèi)容�！‘斄艘欢螘r間IT項目經(jīng)理，把一個軟件開發(fā)項目的項目管理的實際過程寫一下供大家討論和參考。首先我們用思維導圖把計劃階段的相關(guān)活動歸納一下再進行具體的分析：
　　1.項目目標和范圍
    需求，進行項目的范圍規(guī)劃。項目是范圍，進度，質(zhì)量和資源四要素的平衡，用戶對項目進度要求和優(yōu)先級高的時候，我們往往要縮小項目范圍，對用戶需求進行優(yōu)先級排序，排除優(yōu)先級低的需求。另外我們做項目范圍規(guī)劃的一個重要依據(jù)就是我們的歷史經(jīng)驗數(shù)據(jù)，對項目特征的清楚認識，項目范圍規(guī)劃初期需求你進行一個較宏觀的估算，否則你很難判斷清楚或給用戶承諾在現(xiàn)有資源情況下，你3個月時間里面是否可以完成20個或更多用戶功能。
　　正規(guī)過程好像是先確認項目范圍，然后根據(jù)WBS->進度計劃確認實際的項目周期，但實際情況往往很難如此，用戶往往對進度的關(guān)注度大于對范圍的關(guān)注度，一個項目半年或一年都看不到具體的產(chǎn)品出來用戶肯定是無法接受的，所以我們的軟件項目一般也是按版本增量迭代進行開發(fā)。
　　另外這里需要強調(diào)下項目目標的確定，項目的目標不能簡單理解為在某個時間點完成所有功能。項目另外一個重要目標就是項目的質(zhì)量目標，你完成的這個項目需要達到那個等級的質(zhì)量標準，交出的產(chǎn)品BUG泄漏率要控制在什么范圍內(nèi)等內(nèi)容。項目的質(zhì)量目標不會影響到我們的范圍，但會影響到我們后續(xù)評審，測試等時間的安排，直接影響到項目的進度。
　　PMBOK里已經(jīng)明確提到項目范圍定義的另一個重要目的就是項目的績效測量和驗收準則，你交付項目的時候用戶會根據(jù)用戶需求說明書內(nèi)容對項目進行驗收，所有我們項目的范圍的定義必須是明確，量化，可驗證和可測試的，這樣才能夠避免后期無謂的糾紛。
　　另外在概述階段需要分析項目的假設(shè)和約束，假設(shè)和約束又分為技術(shù)方面和非技術(shù)方面，在這里我們分析的所有假設(shè)都可能成為項目的風險。
　　2.項目進度的確定
　　項目的目標和范圍確定后，需要開始確定項目的過程，項目整個過程中采用何種生命周期模型?項目過程是否需要對組織級定義的標準過程進行裁剪等相關(guān)內(nèi)容。項目過程定義是進行WBS分解前必須確定的一個環(huán)節(jié)，你采用瀑布模型和增量迭代模型對WBS分解和進度計劃安排顯然是完全不同的。
　　項目過程確認清楚后開始進行項目的WBS分解，WBS分解一般是項目組的核心成員參加，但項目經(jīng)理應(yīng)該是起主導和協(xié)調(diào)作用。WBS分解方法一般有基于過程和基于成功兩種方式，但兩種方式可以混合使用，比如在高層分解的時候先分解出子系統(tǒng)和工作包，在底層的時候再按照需求，設(shè)計，編碼和測試各個過程進行分解。WBS的最底層工作單元需要是可以獨立核實的產(chǎn)品，需要去下達計劃和任務(wù)，工作單元需要有明確的責任人，因此有時候在沒有做仔細的估算時候我們很難讓工作單元滿足這些要求，這樣就難免在進行估算過程中還要對WBS進行優(yōu)化和調(diào)整。
　　WBS分解完成后可以開始進行工作單元的估算，估算一般有專家法，三點法和功能點法估算，由于我們的項目采用專家法估算，因此更需要項目核心成員和有經(jīng)驗的成員參加，估算一般會針對工作單元的單位和復雜度進行估算，最后估算出項目的總規(guī)模，再除以項目的生產(chǎn)率后得到項目的工作量數(shù)據(jù)。專家法估算一般會進行很多輪，直到所有指標都收斂(收斂標準是組織或項目事先確定清楚了，如偏差人員的責任矩陣進行分析，對于關(guān)鍵路徑一般直接用運籌學中的關(guān)鍵路徑分析法確定ES，EF，LE和LF四個時間即可。
　　在項目進度計劃基本排出來后就可以規(guī)劃和確定項目的里程碑和基線了，項目的里程碑和基線是項目重要的跟蹤控制檢查點，在里程碑項目還會做專門的里程碑報告，對項目的當前狀態(tài)，項目的進度，工作量，規(guī)模，缺陷等各項指標的偏離進行分析。
　　整個項目進度計劃基本出來后需要和項目組的所有項目成員確認，獲取項目的內(nèi)部承諾，項目成員應(yīng)該對整個進度計劃安排基本達成一致。項目計劃還有需要支持計劃需要制定，項目進度計劃出來后整個可以通知QA和配置管理員分別制定質(zhì)量保證計劃和配置管理計劃，項目經(jīng)理協(xié)助測試負責人制定項目的系統(tǒng)測試計劃。
　　3.項目計劃的其它關(guān)鍵因素分析和確認
　　項目的方法，技術(shù)，工具和標準：
    IT項目管理跟其它工程項目管理最大的一個不同就是人的管理，項目成員不是簡單的機器，人員的知識技能，團隊建設(shè)，項目溝通等內(nèi)容往往是項目管理的一個很關(guān)鍵內(nèi)容�！‘斄艘欢螘r間IT項目經(jīng)理，把一個軟件開發(fā)項目的項目管理的實際過程寫一下供大家討論和參考。首先我們用思維導圖把計劃階段的相關(guān)活動歸納一下再進行具體的分析：
　　1.項目目標和范圍
　　開始一個新項目或版本時候，首先是和用戶一起確認需求，進行項目的范圍規(guī)劃。項目是范圍，進度，質(zhì)量和資源四要素的平衡，用戶對項目進度要求和優(yōu)先級高的時候，我們往往要縮小項目范圍，對用戶需求進行優(yōu)先級排序，排除優(yōu)先級低的需求。另外我們做項目范圍規(guī)劃的一個重要依據(jù)就是我們的歷史經(jīng)驗數(shù)據(jù)，對項目特征的清楚認識，項目范圍規(guī)劃初期需求你進行一個較宏觀的估算，否則你很難判斷清楚或給用戶承諾在現(xiàn)有資源情況下，你3個月時間里面是否可以完成20個或更多用戶功能。
　　正規(guī)過程好像是先確認項目范圍，然后根據(jù)WBS->進度計劃確認實際的項目周期，但實際情況往往很難如此，用戶往往對進度的關(guān)注度大于對范圍的關(guān)注度，一個項目半年或一年都看不到具體的產(chǎn)品出來用戶肯定是無法接受的，所以我們的軟件項目一般也是按版本增量迭代進行開發(fā)。
　　另外這里需要強調(diào)下項目目標的確定，項目的目標不能簡單理解為在某個時間點完成所有功能。項目另外一個重要目標就是項目的質(zhì)量目標，你完成的這個項目需要達到那個等級的質(zhì)量標準，交出的產(chǎn)品BUG泄漏率要控制在什么范圍內(nèi)等內(nèi)容。項目的質(zhì)量目標不會影響到我們的范圍，但會影響到我們后續(xù)評審，測試等時間的安排，直接影響到項目的進度。
　　PMBOK里已經(jīng)明確提到項目范圍定義的另一個重要目的就是項目的績效測量和驗收準則，你交付項目的時候用戶會根據(jù)用戶需求說明書內(nèi)容對項目進行驗收，所有我們項目的范圍的定義必須是明確，量化，可驗證和可測試的，這樣才能夠避免后期無謂的糾紛。
　　另外在概述階段需要分析項目的假設(shè)和約束，假設(shè)和約束又分為技術(shù)方面和非技術(shù)方面，在這里我們分析的所有假設(shè)都可能成為項目的風險。
　　2.項目進度的確定
　　項目的目標和范圍確定后，需要開始確定項目的過程，項目整個過程中采用何種生命周期模型?項目過程是否需要對組織級定義的標準過程進行裁剪等相關(guān)內(nèi)容。項目過程定義是進行WBS分解前必須確定的一個環(huán)節(jié)，你采用瀑布模型和增量迭代模型對WBS分解和進度計劃安排顯然是完全不同的。
　　項目過程確認清楚后開始進行項目的WBS分解，WBS分解一般是項目組的核心成員參加，但項目經(jīng)理應(yīng)該是起主導和協(xié)調(diào)作用。WBS分解方法一般有基于過程和基于成功兩種方式，但兩種方式可以混合使用，比如在高層分解的時候先分解出子系統(tǒng)和工作包，在底層的時候再按照需求，設(shè)計，編碼和測試各個過程進行分解。WBS的最底層工作單元需要是可以獨立核實的產(chǎn)品，需要去下達計劃和任務(wù)，工作單元需要有明確的責任人，因此有時候在沒有做仔細的估算時候我們很難讓工作單元滿足這些要求，這樣就難免在進行估算過程中還要對WBS進行優(yōu)化和調(diào)整。
　　WBS分解完成后可以開始進行工作單元的估算，估算一般有專家法，三點法和功能點法估算，由于我們的項目采用專家法估算，因此更需要項目核心成員和有經(jīng)驗的成員參加，估算一般會針對工作單元的單位和復雜度進行估算，最后估算出項目的總規(guī)模，再除以項目的生產(chǎn)率后得到項目的工作量數(shù)據(jù)。專家法估算一般會進行很多輪，直到所有指標都收斂(收斂標準是組織或項目事先確定清楚了，如偏差人員的責任矩陣進行分析，對于關(guān)鍵路徑一般直接用運籌學中的關(guān)鍵路徑分析法確定ES，EF，LE和LF四個時間即可。
　　在項目進度計劃基本排出來后就可以規(guī)劃和確定項目的里程碑和基線了，項目的里程碑和基線是項目重要的跟蹤控制檢查點，在里程碑項目還會做專門的里程碑報告，對項目的當前狀態(tài)，項目的進度，工作量，規(guī)模，缺陷等各項指標的偏離進行分析。
　　整個項目進度計劃基本出來后需要和項目組的所有項目成員確認，獲取項目的內(nèi)部承諾，項目成員應(yīng)該對整個進度計劃安排基本達成一致。項目計劃還有需要支持計劃需要制定，項目進度計劃出來后整個可以通知QA和配置管理員分別制定質(zhì)量保證計劃和配置管理計劃，項目經(jīng)理協(xié)助測試負責人制定項目的系統(tǒng)測試計劃。
　　3.項目計劃的其它關(guān)鍵因素分析和確認
　　項目的方法，技術(shù)，工具和標準：
    IT項目管理跟其它工程項目管理最大的一個不同就是人的管理，項目成員不是簡單的機器，人員的知識技能，團隊建設(shè)，項目溝通等內(nèi)容往往是項目管理的一個很關(guān)鍵內(nèi)容。　當了一段時間IT項目經(jīng)理，把一個軟件開發(fā)項目的項目管理的實際過程寫一下供大家討論和參考。首先我們用思維導圖把計劃階段的相關(guān)活動歸納一下再進行具體的分析：
　　1.項目目標和范圍
　　開始一個新項目或版本時候，首先是和用戶一起確認需求，進行項目的范圍規(guī)劃。項目是范圍，進度，質(zhì)量和資源四要素的平衡，用戶對項目進度要求和優(yōu)先級高的時候，我們往往要縮小項目范圍，對用戶需求進行優(yōu)先級排序，排除優(yōu)先級低的需求。另外我們做項目范圍規(guī)劃的一個重要依據(jù)就是我們的歷史經(jīng)驗數(shù)據(jù)，對項目特征的清楚認識，項目范圍規(guī)劃初期需求你進行一個較宏觀的估算，否則你很難判斷清楚或給用戶承諾在現(xiàn)有資源情況下，你3個月時間里面是否可以完成20個或更多用戶功能。
　　正規(guī)過程好像是先確認項目范圍，然后根據(jù)WBS->進度計劃確認實際的項目周期，但實際情況往往很難如此，用戶往往對進度的關(guān)注度大于對范圍的關(guān)注度，一個項目半年或一年都看不到具體的產(chǎn)品出來用戶肯定是無法接受的，所以我們的軟件項目一般也是按版本增量迭代進行開發(fā)。
　　另外這里需要強調(diào)下項目目標的確定，項目的目標不能簡單理解為在某個時間點完成所有功能。項目另外一個重要目標就是項目的質(zhì)量目標，你完成的這個項目需要達到那個等級的質(zhì)量標準，交出的產(chǎn)品BUG泄漏率要控制在什么范圍內(nèi)等內(nèi)容。項目的質(zhì)量目標不會影響到我們的范圍，但會影響到我們后續(xù)評審，測試等時間的安排，直接影響到項目的進度。
　　PMBOK里已經(jīng)明確提到項目范圍定義的另一個重要目的就是項目的績效測量和驗收準則，你交付項目的時候用戶會根據(jù)用戶需求說明書內(nèi)容對項目進行驗收，所有我們項目的范圍的定義必須是明確，量化，可驗證和可測試的，這樣才能夠避免后期無謂的糾紛。
　　另外在概述階段需要分析項目的假設(shè)和約束，假設(shè)和約束又分為技術(shù)方面和非技術(shù)方面，在這里我們分析的所有假設(shè)都可能成為項目的風險。
　　2.項目進度的確定
　　項目的目標和范圍確定后，需要開始確定項目的過程，項目整個過程中采用何種生命周期模型?項目過程是否需要對組織級定義的標準過程進行裁剪等相關(guān)內(nèi)容。項目過程定義是進行WBS分解前必須確定的一個環(huán)節(jié)，你采用瀑布模型和增量迭代模型對WBS分解和進度計劃安排顯然是完全不同的。
　　項目過程確認清楚后開始進行項目的WBS分解，WBS分解一般是項目組的核心成員參加，但項目經(jīng)理應(yīng)該是起主導和協(xié)調(diào)作用。WBS分解方法一般有基于過程和基于成功兩種方式，但兩種方式可以混合使用，比如在高層分解的時候先分解出子系統(tǒng)和工作包，在底層的時候再按照需求，設(shè)計，編碼和測試各個過程進行分解。WBS的最底層工作單元需要是可以獨立核實的產(chǎn)品，需要去下達計劃和任務(wù)，工作單元需要有明確的責任人，因此有時候在沒有做仔細的估算時候我們很難讓工作單元滿足這些要求，這樣就難免在進行估算過程中還要對WBS進行優(yōu)化和調(diào)整。
　　WBS分解完成后可以開始進行工作單元的估算，估算一般有專家法，三點法和功能點法估算，由于我們的項目采用專家法估算，因此更需要項目核心成員和有經(jīng)驗的成員參加，估算一般會針對工作單元的單位和復雜度進行估算，最后估算出項目的總規(guī)模，再除以項目的生產(chǎn)率后得到項目的工作量數(shù)據(jù)。專家法估算一般會進行很多輪，直到所有指標都收斂(收斂標準是組織或項目事先確定清楚了，如偏差人員的責任矩陣進行分析，對于關(guān)鍵路徑一般直接用運籌學中的關(guān)鍵路徑分析法確定ES，EF，LE和LF四個時間即可。
　　在項目進度計劃基本排出來后就可以規(guī)劃和確定項目的里程碑和基線了，項目的里程碑和基線是項目重要的跟蹤控制檢查點，在里程碑項目還會做專門的里程碑報告，對項目的當前狀態(tài)，項目的進度，工作量，規(guī)模，缺陷等各項指標的偏離進行分析。
　　整個項目進度計劃基本出來后需要和項目組的所有項目成員確認，獲取項目的內(nèi)部承諾，項目成員應(yīng)該對整個進度計劃安排基本達成一致。項目計劃還有需要支持計劃需要制定，項目進度計劃出來后整個可以通知QA和配置管理員分別制定質(zhì)量保證計劃和配置管理計劃，項目經(jīng)理協(xié)助測試負責人制定項目的系統(tǒng)測試計劃。
　　3.項目計劃的其它關(guān)鍵因素分析和確認
　　項目的方法，技術(shù)，工具和標準：
    這是項目計劃中需要確定的一個重要內(nèi)容，即項目過程需要使用哪些方法和技術(shù)，采用哪些工具，項目各個階段的輸出應(yīng)該滿足哪些檢查標準等。一個項目中除了使用到常用的開發(fā)工具外，還會使用到需求管理，設(shè)計建模，配置管理，變更管理，IM溝通等諸多工具;使用到面對對象分析和設(shè)計，開發(fā)語言，數(shù)據(jù)庫，測試等多種技術(shù)，在這里都需要分析和定義清楚，這將成為后續(xù)技能評估和培訓的一個重要依據(jù)。
　　干系人分析：
　　所有對你項目有直接和間接影響的相關(guān)人員都是項目的干系人，在這里我們一般會按項目內(nèi)部角色和外部角色進行劃分。在對所有的干系人分析清楚后，還應(yīng)該通過責任矩陣來分析各個干系人說涉及到的項目各階段的相關(guān)活動。
　　項目的關(guān)鍵依賴和承諾：
　　項目的內(nèi)部關(guān)鍵依賴和承諾一般會直接體現(xiàn)到項目進度計劃中，但項目的外部依賴和承諾必須有專門的地方進行記錄和定期進行跟蹤。因為當你外部關(guān)鍵依賴無法得到滿足時候?qū)⒅苯佑绊懙秸麄�項目的進度，打亂整個項目的步調(diào)。
　　項目風險分析：
　　風險管理是項目管理的一個重要知識領(lǐng)域，也是CMMI評估的一個關(guān)鍵過程域。整個項目管理的過程就是不斷的去分析，跟蹤和減輕項目風險的過程。我們在分析項目風險過程中可以借助風險庫，風險檢查單，專家法，頭腦風暴法等多種手段。一個風險主要包括了風險的概率，后果，影響范圍，處理期限等方面的內(nèi)容;風險的應(yīng)對措施主要有減輕，承擔，緩解和轉(zhuǎn)移等;風險分析一個重要內(nèi)容就是分析風險的根源，然后根據(jù)根源去制定專門的應(yīng)對措施。風險管理貫穿整個項目管理過程，需要定期的對風險進行跟蹤和重新評估，對于轉(zhuǎn)變成了問題的風險還需要事先制定相關(guān)的應(yīng)急計劃。
　　項目成員技能和培訓：
　　其實這是項目計劃的一個重要內(nèi)容，就是要對項目中的各個成員的技能進行評估，根據(jù)項目評估的結(jié)果來制定項目的培訓計劃，并對培訓的效果進行跟蹤。在這里常用的方法和工具有《項目成員培訓需求收集表》，《項目成員技能評估表》，《項目成員技能溝通確認表》，《項目培訓計劃》。(項目管理者聯(lián)盟)
更多內(nèi)容詳細咨詢：http://cdforum.cn/