凡事預則立，不預則廢。IT項目管理中的項目計劃既是CMMI的一個關鍵過程域，同時也涉及到PMBOK的啟動和計劃階段，涉及到範圍管理，成本質量管理和風險管理等多個知識領域的內容。

對於如何做一個項目計劃，在實施過程改進後一般會形成明確的項目主計劃模板，因此本文重點在於根據做項目計劃中遇到的問題和項目實際的一些改進方式和措施來分析如何優化改進項目計劃。

問題的提出

制定項目計劃的時間按業界的標準一般應該佔用項目周期的30%左右的時間，而我們現在做項目計劃的時間一般在10%左右，所以存在項目計劃中很多細節問題考慮不全的問題，或者是有些問題根本沒有根據項目實際情況進行分析和裁剪而直接採用項目計劃模板中的內容。

整個項目計劃的制定過程中經常遇到的問題有：

項目的範圍經常發生變動，從而導致項目延期，或者版本實現的用戶功能不能滿足用戶的需求而導致用戶滿意度下降。
估算數據不準確，用例的複雜度沒有一個較好的估算方法，很多時候項目成員估算時都採用通過估算工作量再反推用例複雜度的做法；導致估算數據有偏差直接影響到項目進度。
在編排項目進度計劃時，由於對IT項目管理有明顯的資源約束，如架構可能就是瓶頸資源，因此很多時候關鍵路徑並不是最快的可以完成的項目周期，這個時候應該如何去考慮資源約束對項目計划進行優化。
在項目計劃制定過程中制定了度量計劃，質量計劃和跟蹤控制計劃，但這些計劃間究竟相關關係是怎麼樣了，這些計劃的內容是如何體系到後續的跟蹤控制中的。
在項目計劃階段如何做好項目風險管理計劃，以及如何保證關鍵核心的風險能夠分析到不被遺漏，如何去量化一些風險參數以及如何確認某些耗成本和資源的風險減輕措施是否值得去做。
IT項目管理與其它工程項目管理最大的區別在於IT項目管理中人的因素是一個需要重點考慮的問題，在項目計劃中我們如何根據項目實際情況切實可行的制定相關的人力資源計劃和溝通，培訓計劃。

解決思路

項目計劃階段的相關問題會涉及到項目管理的很多知識領域。每個問題的解決思路都可能不同，但究其根源主要還是應該首先在項目經理個人的技能和素質的持續改進和不斷提高上面。項目經理是一種複合型的角色，既需要有相關的技術知識積累又需要熟悉和了解整個業務和模式，同時還需要具備團隊建設，溝通技能，時間管理等軟知識的積累，具備對概率，統計和運籌等基礎知識學科的積累和應用。

對於項目管理的知識體現結構可以通過思維導圖整理出來，如下：

下面根據每個問題提出相關的解決思路和方法。

1 項目範圍規劃時候充分考慮干係人，四要素和功能依賴的平衡

開始一個新項目或版本時候，首先是和用戶一起確認需求，進行項目的範圍規劃。項目經理在做範圍規劃時候應該平衡好範圍，進度，質量和資源四要素，另外在確定項目範圍時候還需要考慮到相關用戶功能的前後置依賴關係，對於那些需要依賴系統一些沒有開發的基礎功能的用戶功能，即使提前開發出來了也用不上，這塊要跟用戶確認清楚。

2 通過歷史經驗數據收集，複雜度估算類比，功能點法等提高項目估算準確性

估算前提是項目範圍必須要很明確，項目範圍明確了才可能準確地進行WBS分解。在WBS分解的時候推薦採用先功能後按生命周期的這種分解方式，這樣在後期較容易對相關的功能劃分增量和核算每個功能具體的成本和投入。在項目估算過程中會用到很多項目歷史版本的數據，因此必須做好數據收集和項目復盤工作。

專家法估算更多的時候依賴於專家的實際經驗數據和自我積累，但這種估算很難量化出來，為了將這些估算經驗量化或形成項目組織級的估算模式，在條件允許時候可以同時採用功能點法和專家法進行同時估算，積累功能點估算的相關數據，為後續完全採用功能點法估算打下基礎。

3 考慮資源和關鍵路徑雙重約束來安排好進度計劃

由於有關鍵資源的約束，安排項目進度計劃已經不是簡單的求關鍵路徑問題，而是還需要考慮由於關鍵資源約束引起的活動排隊和等待的問題。

另外整個進度計划過程應該遵循WBS分解->確定活動和任務->確定依賴關係->關鍵資源和角色矩陣確認->對任務分配資源->對超負荷資源或資源不足進行反覆的平衡這幾個重要步驟來完成一個版本的項目進度計劃。

4 根據項目的質量目標來貫穿項目計劃中的質量計劃，度量計劃和後續跟蹤控制

質量計劃的一個重要內容就是確定質量目標，質量目標也是項目的一個重要目標，這個應該在做項目計劃時候提前確定下來，而且項目的質量目標會體現到後續的估算中。對於項目度量計劃也是一樣道理，首先是項目自身有度量的需求，項目經理需要去關注項目的進度，成本和質量，時刻了解到項目的健康狀態和偏差，這樣才能夠及時地去調整資源和進度，保證項目目標的實現，項目應該多去尋找度量指標的內在關係和影響，找到問題的根源，這樣度量計劃才能夠真正發揮價值。

這裡我整理後的各度量指標間的關係圖如下：

7 在項目一啟動就制定風險管理計劃分析風險，並適當對風險參數進行量化

風險管理必須貫穿整個項目管理過程，從風險管理計劃制定，到風險的識別分析和風險的具體應對和跟蹤。風險分析一定要分析到風險的根源，減輕計劃和應急計劃也是根據風險根源進行的。風險的不確定性應該量化，你需要用這些量化的數據去分析。

什麼時候需要對風險實施應對措施，你風險應對的投入是否划算？風險在項目不同的時間點對你項目的質量，工期的影響程度究竟有多大。風險的量化需要我們收集數據，採用相關的風險模型進行模擬。如風險圖或Riskology工具提供的蒙特卡洛模擬器。

8 根據進度計劃確認人員投入期，根據技能評估和培訓需求收集來計劃培訓的安排

IT項目由於自身生命周期的限制，需要在項目的不同階段投入不同角色和數量的資源來保證項目任務的完成，這個應該根據項目進度計划進行安排。

項目成員的知識和技能水平對軟件項目的質量有至關重要的影響，因此項目計劃階段應該對項目成員技能進行評估，同時根據培訓需求收集表收集相關的培訓需求，並將相關的培訓計劃安排到整個項目計劃中，同時對於培訓的效果後期還需要專門和相關人員進行溝通和確認。

實踐情況總結

以上問題都是在項目中出現過的相關問題，應該具有一定的代表性。在項目管理或日常工作中，很多時候並不是我們解決問題能力差，更多的時候是發現不了問題或發現不了引起問題的根源因素。項目計劃和管理中的多個問題都是通過整個項目團隊的復盤總結，開發過程的評審，項目經理自查等多種方式發現的。

1.通過與業務用戶的多次溝通確認項目版本的範圍。

項目一般會提前2-3周同用戶討論下個版本的具體用戶需求，所以作為用戶接口的技術管理部一般會提前一個月收集各個事業部的相關業務需求，這樣才能夠保證項目的各個版本很好的迭代起來。對於收集到的用戶需求，根據需求的重要性和緊急程度確認各個需求的優先級別，同時每個需求都還會附加上業務期望的解決和上線時間。

在第一次討論完成後，項目組會組織BA，架構和項目經理共同開會討論用戶需求信息，項目組內部討論一般會根據該功能實現後可能的使用頻度，實現的工作量，實現該功能對系統已有功能的影響等多個方面對用戶需求進行討論和規模工作量的初步估計，給出一個具體的項目周期和範圍的幾對可選值。如1個月可以實現前6個需求，2個月可以實現前十個需求，同時對那些暫時使用頻度不會很高，對系統的增值價值不高的需求提出自己的意見。

有了這些基礎信息後再組織和用戶的第二次業務討論，這個時候用戶基本可以從幾對可選值中選擇可以滿足自己的安排。如果存在很多個功能優先級都很高，又對解決期限有強烈要求的時候，這時候產品經理就會考慮在項目人力資源上的多投入來滿足用戶的需求。

這裡通過項目多個版本實踐，強調的幾點是：

1)一些用戶提出很緊急的需求對整個用戶群或系統來說並不緊急，如一些業務管理員的操作新需求，這些功能基本上一個月才使用幾次，使用人數在1/1000以下，所以花費較大的人力資源實現這種需求對整個系統的增值並不高。一般這種需求即使用戶優先級高，IT通過討論後也會降低其優先級。

2)如果用戶需求存在對系統的核心模塊重大改造時，一般會延期實現或考慮替代方案，如項目在系統管理和工作流模塊，經過多次的系統測試，回歸測試和驗收測試才運行穩定，如果用戶提出的新需求對這塊存在重大改造，那對整個系統引起的風險是相當高的。

3)在項目範圍確定中存在了需求挖掘過程，IT協助用戶將點的需求擴展為面的需求。如項目的V4.1版本用戶提出了在齊套清單功能上，增加對清單內容表格的搜索功能，這個功能後期轉化為了對整個系統的GRID都支持模糊搜索。

通過這種方式確認出來的項目範圍和項目周期就和用戶很好的達成了一致，保證了後續計劃和執行階段工作的順利開展。

2.不斷地對估算方法進行總結和實踐以提高估算準確性

對於專家法估算，困擾項目的一個主要問題是如何把用例複雜度估計的準確點，因為在估算時候WBS的工作包基本上都會分解到1個用例的粒度，但很明顯的是各個用例的複雜度是明顯不同的，組織級在用例複雜度上面根據基本流+擴展流+業務規則的流總數來進行的定義。由於第一次估算時候軟件需求還沒有出來，因此問題轉化為了如何較準確的確認清楚軟件需求的流總數，這個數據的估算難度相當大，更多的只要依賴專家的經驗。

在項目的前續幾個版本中，對該複雜度的估算也不是很理想，很多時候只能倒推的方式來進行估算，為了進一步估算準確，從V2.2版本開始項目關注與各個版本的復盤和歷史數據的收集，爭取找到需求頁數，用例數，流總數，業務對象數，數據庫設計字段數，界面元素各數，工作量，代碼行這些因子的關係，收集數據如下：

通過對這些採集數據的關聯性分析，基本得到的可以借鑒的經驗數據如下：

用例複雜度可以和用戶需求建立一定的對應關係，關係可以體現到頁數，如果更細化一點可以體現到用戶需求中的輸入輸出列表和數據項，但要求用戶需求足夠細化。

用戶需求中可以看到的是處理，而處理更多的是體現業務規則，原有估算中把業務規則的一個流和基本流擴展流等同看待有問題，這裡根據項目經驗提出業務規則對用例複雜度的影響權重應該加大，3-5個業務規則複雜度應該到2，5-10個業務規則複雜度應該為3或4,對於出現超過10個業務規則的用例必須進行子用例的拆分。這樣在用戶需求寫得較好情況下很容易根據用戶需求判定出用例的複雜度。

對於設計界面操作的用戶需求，當其用戶需求說明書涉及到的輸入輸出項超過20的時候要考慮增加估算用例的複雜度，在這裡數據項再每增加10個用例複雜度加1。

在項目大版本，而且剛開始用戶需求說明書不夠詳細的情況下，在軟件需求完成後必須進行第二次估算，這點在項目 V4.0版本中按此規則進行，由於軟需已經完成，需求和設計人員都可以較為準確地估算出用例的規模和複雜度。確立該規則的一個重要原因在於需求和設計開發工作量比一般為1:5，說明需求階段2天的工作量偏差反映到設計開發階段將是10天的工作量偏差，這個工期偏差對項目來說往往是致命的打擊。

所以工作量比例分佈僅僅是經驗數據，很多時候不能完全地不加分析地採用，更多的時候還需要考慮到設計開發工作的實際情況和特殊性。在項目項目中第二次估算時估計出設計開發總量後，項目經理都通知到各大功能的設計負責人對功能進行功能點的細分，並對該模塊的開發進度進行細排，細排後發現保存和載入默認值這塊有一周的工作量，但體現到需求文檔僅僅是一句話；對於部件的版本控制需要考慮抽象和復用出公用的版本控制服務，但前期作軟件需求的時候這個公用服務根本沒有需求用例對應，根據這些情況，項目經理進一步對進度計划進行了細化並增加了一個人力資源投入。

確定了估算的規模後，另外一個重點要確認的就是項目的生產率和工作量比例的分佈，需求階段的生產率經過多個版本的積累已經較穩定在0.8到1之間，但設計開發的生產率由於項目成員的變動導致不穩定，V4.0版本項目有三名新員工參加，因此需求與設計開發的比例數據不能夠完全採用上個版本的復盤數據，在這裡項目稍微做了調整，將需求與設計開發的比例調整到1:5左右，以使設計開發的工作量適當增加。

如果一直停留在估計需求規模層次上，估算準確度是很難提高的，而且項目也迫切地需求了解到代碼行的生產效率情況，每個人在設計開發階段的工作量的實際分佈情況，因此在V4.0版本，決定在南京項目組推廣個體軟件過程，並引入了PSP Studio工具對過程數據進行了準確記錄，如下：

由於結隊中有一名新員工，配置管理編碼生產率為：6223÷313×8≈159行/人日。而全是老員工的部件管理功能的代碼生產率為 14500/55 = 264 行/人日。所以基本上可以得出有新員工的時候編碼生產率可以取150行/人日。而對於全是老員工可以取250行/人日。這個數據的採集和積累對項目後期的編碼工作量估算有很好的指導意義。對於PSP具體應用請參考項目組高波提交的《PSP應用最佳實踐》一文。

具體的採用PSP Studio收集數據見如下截圖：

另外對於將估算的經驗更好的文檔化或量化出來，個人建議在大功能版本時候採用功能點進行估算，或者同時採用專家法和功能點法進行估算，根據多個版本的積累來推算出功能點法的生產率數據，否則功能點法很難用起來。項目項目Q02.01版本在第二次估算中採用了功能點法，得出的一些經驗生產率數據如下：

具體的功能點法原理和使用方法也在項目組內進行了培訓，並形成了相關的使用文檔，使項目成員都能夠理解功能點法的具體使用方法。

註：數據收集和分析是清楚知道自己效率的基礎，也是項目計劃逐步收斂和偏差可控的基礎，不要想着一開始計劃就準確無偏差，而是應該通過持續迭代計劃不斷的調整基準參考。

3.考慮資源和關鍵路徑雙重約束來安排進度計劃

項目的V4.0版本是一個15個人的3個月的大版本，通過最後復盤的5萬多行代碼行產出也基本可以說明這點。

資源約束和依賴關係約束一直是排進度計劃的兩大要點，V4.0版本分解到最後有200多個任務項，如果全部依賴關係都建立差不多有50個依賴關係，這樣即使Project能夠自動計算關鍵路徑，項目經理拿到這些數據也無從下手。因此制定進度計劃應該遵循先粗後細的原則，首先應該在工作包這個層次對依賴關係和關鍵路徑進行尋找，在做這個工作之前，項目組首先對角色責任矩陣進行了識別，如下：

圖中可以明顯地看出架構工程是項目的關鍵資源，必須在架構結構上優先保證架構設計工作。整個V4.0版本共6個工作包，因此可以得到的粗進度計劃圖如下，其中紅色為關鍵路徑：

對該粗進度計划進行分析可以得到以下結論：

需求不存在前後依賴總工作量55，三個BA考慮加班三周總工作量為54，可以滿足需求三周完成。
架構設計跨度10天，由於關鍵路徑，其它任務都無法進行，這裡必須進行調整，因此調整計劃為架構設計和最後一周需求並行，這裡壓縮工期5天。
視圖管理在關鍵路徑上，造成了配置管理和產品結構瀏覽任務的等待，但視圖管理和總體架構設計關係不大，架構花一天完全可以考慮清楚，因此視圖管理在這裡考慮闖紅燈提前進行結隊開發，壓縮工期3天。
整個項目共可以結隊5組人員，其中除了屬性類型管理功能外，其它功能都基本安排飽和，而且設計最多帶兩個編碼，一個任務上最多安排三個資源，不能再通過安排更多的資源來壓縮工期。

先分解再集成，粗粒度工作分解後能夠形成並行作業，同時長周期工作分解後能夠快速形成上游輸出推送到下游活動，減少等待時間。在關鍵資源受限情況下，需要首先考慮最大化地提升前期的資源利用率，其次才是關鍵路徑。

通過粗進度計劃的編排，項目經理基本對整個進度情況就有了總體的認識，這個時候才能夠進一步分解工作包為任務，排細化的進度計劃。在進度計劃的制定中，我們常使用固定工期的方法進行，這個方法好處就是某個進度延誤可以通過周末加班趕工而不影響後續的任務，但這個方法的一個大弊端就是在估算和下達任務時候思維裏面老是按照一周的概念再考慮問題，有時候反而無法充分利用資源，設置的關鍵路徑也無法起到很好的作用。

因此可以更科學的採用固定工時的方式來排PMS任務，工時可以直接從估算的數據中取到，在對任務分配資源的時候，優先保證關鍵資源分配到關鍵任務上面，同時當關鍵資源承擔多個任務的時候一個普遍原則是：

設A1,B1是兩個關鍵任務，A的後續依賴任務是A2,B1的後續依賴任務是B2，A1可以比B1早3天開始，A2到結束關鍵路徑長為L1，B2到結束關鍵路徑長為L2.

A.當兩個從後續任務開始算起的關鍵路徑長差不多時，關鍵資源優先開始可以提前開始的任務。即優先開始A1任務。
B.當L1比L2短3天以上時候，這個時候反而要優先開始B1任務，雖然這個時候開始要閑置關鍵資源，這點很重要。

這個可以根據運籌學的最優化方法進行建模，去尋找最優解。但在進行進度計劃制定時候不可能採用這麼複雜的方法，更多的是採用一些普遍的經驗和原則。

通過設置了關鍵路徑，對任務安排了相關資源後，Project就可以自動的生成出整個版本的工期了，在生成工期完成後需要進入到資源負荷圖對資源負荷情況進行確認，如果考慮到加班，資源負荷在120%，因此當負荷超過120%的時候就需要對資源負荷情況進行適當的調整，如此反覆多次，可以得到一個比較可行的進度計劃。

在V4.0版本進行完第二次估算後，項目經理又對進度計划進一步細化和完善，得到了每一個功能確切的可以交付測試的時間點，根據最後的時間情況來看，屬性類型管理和視圖管理都提前交付測試，部件管理，批置管理和產品結構瀏覽正常交付，但集成時間多花2天，工程變更延後2天交付，偏差都在受控範圍內。

4.確定項目的質量目標和質量計劃

一個軟件項目除了進度目標外，另外一個最重要的目標就是質量目標，而質量目標並不是簡單指版本發佈的時候測試問題全部解決，而更多關注的是你版本發佈後的缺陷泄露情況，這個質量目標在項目完成的時候無法馬上得到數據和進行驗證的。所以一般是通過間接控制的方式，即可以去估計我們期望的缺陷和BUG的發現情況，當質量目標高的時候，就期望在評審和測試階段近可能多的發現BUG，直接自然泄露到版本發佈後的缺陷就少。

由於一個項目版本的總缺陷數量應該是一定的，只是在交付後發現出來還是在交付前發現出來。如果能夠在交付前發現出來我們軟件的質量就高。BUG缺陷密度，總缺陷數，交付後缺陷數，代碼行這些指標間有着相互影響和作用。在做一個項目版本的時候，應該對這些關係有比較明確的了解，具體關係如下圖(中間為交付前BUG比重)

上表說明當交付前缺陷密度過高的時候就很難保證交付後的缺陷密度很低。所以根據經驗應該將交付前BUG的比重控制在80-90%的範圍內。上表中的綠色底紋數據是我們可以參考和借鑒的數據。

根據項目歷史版本數據統計，缺陷密度一般在4-6之間，因此交付密度採用0.8或1都是可行的。對於交付後的軟件的缺陷數據，CMMI三級的企業一般在0.5-1.5個/千行代碼，CMMI四級企業在0.5個/千行代碼。所以根據業界這個標準和組織級的建議，項目V4.0版本採用的交付後缺陷密度為0.8個/千行。

在項目 V2.6版本，項目就根據組織級的規程仔細進行了復盤，其中得出的需求規模是39用例，產出的代碼行是30068，實際的缺陷總數是319個，測試階段的BUG數量為115個。

因此可以得出的總缺陷密度為8.17個/UC，而跟測試BUG相關的測試缺陷密度為3.8。因此在項目V4.0版本項目的估算中也採用了這些數據，並取得了較好的效果，具體的對比和偏差如下：

如果項目某個版本用戶提出特殊的質量要求，就需要對項目的質量目標進行調整，質量目標在確定後將直接影響到估算的工作量分佈，因此在制定項目計劃的時候一定是先制定出項目的質量目標，然後在根據質量目標去指導和約束估算過程。

質量目標預計出來的數據在項目執行和跟蹤過程中也有用處，我們時刻要使用該數據去檢查我整個項目過程是否出現偏離，如果預計的需求缺陷是160個時候，如果需求階段實際完成缺陷只有50個或更少，這個時候就要進行分析是否是同行評審過程有問題，該發現的缺陷沒有發現出來，是否需要重新組織評審或增加預審時間，只有這樣才能夠真正保證上游缺陷不泄露到後續工作中。

需要注意的是項目質量目標的確認過程不僅僅是項目組成員自己確定，更多的是需要和QA和測試負責人根據該版本的業務需求共同討論和確定，QA可以根據其它項目情況或業界的一些標準給出有建設性的意見，測試也可以根據項目前續版本的測試情況來確認項目是否可以達到制定的質量目標。

項目質量目標確認後，還要進一步的確認項目的質量策略，質量策略就是你為了達到這些質量目標而需要採用的方法或手段。如質量目標要求高的時候，推算出評審需要發現100個缺陷，如果採用單人複審或多人複審就根本做不到發現這麼多缺陷，這個時候就要考慮哪些要採用審查的方式以及審查的具體比例規劃。

在項目質量目標確認後，在後續的項目執行過程中要時刻關注這些目標的執行情況，如評審是否充分，測試是否發現了預計多的BUG，當出現較大偏差的時候要及時分析原因和採用相關的應對措施。

制定項目的風險管理計劃

風險管理是項目管理的一個重要內容，風險管理的過程貫穿整個項目生命周期。風險管理計劃中首先要確定風險管理小組的成員和各自的職責，對於項目項目，風險小組負責人為項目經理，項目B為核心成員主要負責分析需求方面的風險，架構為核心成員主要分析技術方面的風險，用戶主要分析業務方面的風險。

風險小組確認後就要確定風險管理過程中需要使用的相關的工具和方法。其中包括風險識別的方法，風險分析的方法，風險監控的方法和風險應對的方法。這些方法和工具組織級都有明確的定義和指導原則，對於存在多種方法時要根據項目實際情況選擇。

對於項目的風險來源和分類，組織級都有明確的標準和定義，項目一般都可以直接採用，但需要注意的是有可能需要項目實際情況對其進行裁剪。如項目本身不可能存在採購方面的風險時候，就需要將其裁剪到，這樣在後續的風險識別和分析中都不用再過多考慮。

項目在制定具體的風險管理參數的時候，雖然組織級有了明確的參數具體的含義定義，但項目更多應該根據實際情況進行調整。如組織級定義項目延期兩個月該風險後果為0.8，但當項目版本周期僅僅是1個多月的時候，這個時候當項目延期一周後果就相當高而應該取0.8了。所以這裡項目經理應該特別注意進行修改。

項目計劃中的風險應對策略不是針對某個特定風險的，所以這裡的應對策略更多是通用的應對策略：如開發原型，技能評估和培訓，數據模擬等。當遇到實際的風險時候，如何去應對還要根據風險的實際情況進行分析。

項目計劃階段就應該分析出項目在當前狀況下的所有風險，並對風險進行優先級排序，當確認了是項目的關鍵風險後，需要制定這些風險的減輕計劃和應對措施，這些內容都需要體現到PMS進度計劃中，PMS進度計劃必須包含這些內容才是一份完整的進度計劃。

當我們積累了足夠多的歷史數據後可以對風險進行組合分析和量化分析，對於風險量化分析可以採用決策樹和蒙特卡洛模擬等方法進行。具體的方法可以參考以下文檔：

制定項目的人員培訓和技能評估計劃

在IT現階段項目計劃中有專門的資源計劃，這裏面有相關各階段軟硬件資源的需求，個人認為在這裡更重要的是人員培訓和技能評估計劃的制定，因為需求不穩定和人員流動一直被公認為軟件項目的兩大最高危風險。

項目系統早在V2.2版本就開始考慮培訓需求的收集工作，每個項目成員都有很多相關的培訓需求而且可能會比較發散，因此項目首先通過歷史版本的總結，從業務，技術和管理相關的培訓列出的可能的培訓課程，然後製作成相關的數據庫表格，規定每位成員最多只能選擇三門希望參加的培訓課程，然後對培訓結果進行匯總分析，排定培訓安排的優先級別計劃。

如下圖：

這樣根據收集的數據進行分析後，得出具體的培訓計劃安排。通過這種方式確認出來的培訓計劃將很有針對性，可以滿足大多數項目成員的培訓需求，同時培訓課程是大家選擇出來的，培訓的積極性和主動性也較高。

在項目計劃中除了安排培訓外，還需要制定相關的技能評估計劃，第一個是有效的檢查培訓的效果，第二是考查項目成員的真實技能情況便於後期安排有針對性的指導。在項目項目的V4.0版本中，由於有多名新員工，因此項目一開始就安排了相關的培訓和以師帶徒的輔導，同時制定計劃要在階段任務開始時候對新員工的技能進行一次當面的溝通和確認，以安排後期的需求和確認新員工是否達到項目要求。

因此在項目中，項目5月底項目經理專門和每位新員工進行當面溝通確認技能情況。涉及了項目開發模式，工作流，系統管理，文檔管理，系統業務，數據庫等多項內容，並對各個分項內容進行技能評估，綠色表示技能基本達到，紅色表示技能有明顯欠缺。新員工在經過培訓和自學後基本可以勝任編碼工作，但遇到功能模塊跟工作流和系統管理接口部分的開發時候，需要設計人員仔細講解。

效果評價

對於項目計劃的優化改進實施體現在項目項目管理的多個版本中，具體的效果可以總結為以下幾個點：

對於在1到1個半月左右小版本，估算準確度在90%以上，一般只做一次估算即滿足要求，項目進度偏差也很小，基本都正常發版。
對於大於2個月的版本，項目一般做兩次估算，第一次估算準確度在70%左右，軟件需求完成後第二次估算準確度在90%以上，因此第二次估算完成後對進度計划進行調整，調整後項目進度偏差可以控制在5%以內。
從V2.1版本以來的項目多個版本，由於前期跟業務溝通的充分，用戶需求變更很少，基本沒有出現過需求頻繁變更對項目進度和質量造成影響情況。
項目形成了一套大版本進度計劃排定，關鍵資源和關鍵路徑考慮的方法，使得2-3個月的大版本也可以在計劃需求階段排出較為細緻的進度計劃來。
項目重視風險計劃和風險的管理，風險轉化為實際問題的情況很少。
培訓計劃，技能評估，異地溝通和團隊管理在項目項目已經形成了相關的規程和方法，項目基本可以做到個別人員流失不會對整個項目造成較大衝擊。