軟體專案進度延期關鍵因素和應對措施

1.專案進度本身不合理

　　本著多從自身找原因的準則，對於進度延遲時候應該首先分析專案進度計劃安排本身是否合理?對於專案進度計劃安排是否合理影響因素主要應該從以下幾個方面進行分析和考慮。

　　估算是否準確

　　對於估算是否準確是對專案進度計劃安排影響最大的一個因素，估算不準 確的原因很多，主要的兩個方面是確實有經驗的估算專家和專案缺少歷史資料的收集，對於這兩點只有通過專案多個版本的積累才可能得以改善，而沒有捷徑。另外 估算過程中還需要考慮一些特殊因素的影響，如專案新進了幾名新員工可能會降低專案的平均生產率，專案過程中需要採用某種新技術而需要投入額外的預研時間 等。

　　關鍵資源和關鍵路徑的安排是否合理

　　在進度計劃安排中是否優先保證了專案關鍵路徑上的資源，是否通過人員 技能矩陣對專案關鍵資源進行分析和安排。在我們任務安排過程中是否對關鍵資源進行了保護(儘量減少關鍵資源上非關鍵任務的安排)。另外我們在進度計劃安排 上應該適當安排10%-15%的餘量，這樣在專案遇到突發事件，或專案風險轉變為實際問題時候才能夠有人員和時間進行處理。

　　專案中的資源是否充分利用

　　由於存在關鍵路徑和崗位角色矩陣，所以專案中人力資源往往並不能充分 利用起來。在中小型專案中為了充分利用相關資源，專案更應該採用敏捷和迭代的開發方法，需求階段開發人員可以先熟悉需求和進行公有元件的開發，而測試階段 我們的需求人員也可以介入測試。所以對一個軟體專案而言，需要保證到專案成員的整體利用程度在70%以上，否則就應該考慮採用新的開發模式和生命週期模 型。

2.團隊和人的問題

　　軟體專案跟其它工程專案最大的不同就是人和團隊的因素對專案影響很 大，軟體專案中的編碼人員也是重複的創造性的非簡單重複的勞動。軟體工廠在短時間內是無法實現的，所以更必須承認專案中各個成員的價值。工程建設中走了一 個泥水工可能馬上就能找到替代人手，而軟體專案中人員流失及時很快找到了新成員，也需要花費不定長的培訓和學習時間，新成員才可能真正達到專案要求的生產 率。對於這方面影響因素主要分析如下：

　　人員技能未達到要求

　　在專案開始之初我們假設專案成員都能夠達到組織級的要求，但往往並不 是每個成員都能夠達到要求。而且專案中每個成員的生產率差異可能很大，也給專案進度安排造成影響。所以在專案開始之初應該對專案成員的技能進行一次總體的 評估，對於大家都欠缺的技能應該安排統一的培訓，後續還需要對培訓的效果進行跟蹤;對於個別人員技能欠缺的應該單獨預留自我學習時間或通過以師帶徒的方式 進行培養，使其技能能夠儘快達到要求;對於專案新員工的工作和任務應該加強評審和Review,保證輸出不出現大的偏差而導致後續大量的返工。

　　專案成員責任心不強

　　態度決定一切，細節決定成敗。對於專案過程中的各項任務，經常出現由 於專案成員責任心不強而敷衍了事，導致產出的工件質量較差，引起大量返工的情況。在這種情況下專案更應該加強專案規範的建設，專案經理應加強同這些成員的 單獨溝通，加強專案的團隊建設和集體榮譽感。讓專案成員感覺到做的系統是他們自己的產品，而不是公司的專案，專案經理的專案。

         專案溝通問題

　　在軟體專案中，保證專案各種角色和成員中的高效溝通是很重要的，如何 建立起快捷順暢的溝通渠道，採用最佳的溝通方式來解決問題必須在專案中經常強調。一週的專案任務花在實際做事情上只有2天，而花在溝通上佔有了3天，如果 出現這種情況必須及時分析和總結原因。溝通最重要的就是要在最短的時間裡面，採用可以採用的各種方法或工具使交流雙方或多方達成一致。

　　專案人員流失

　　專案人員特別是專案關鍵成員在專案進行過程中的流失對專案影響很大，對於這種情況應該在專案開始之初中就做為專門的風險進行跟蹤，並考慮具體的應對措施。

3.質量因素的制約

　　時間和質量是專案中兩個重要因素，在保證專案進度的情況下我們往往會 犧牲了專案的質量。而由於軟體專案中測試環節的引入，專案的最終產出又需要保證我們的最終產品滿足一定的質量規範。所有專案中經常出現專案後期測試問題太 多，BUG修改和迴歸測試等花費了大量的時間而導致專案的延遲。對於專案質量因素的制約主要分析為：

　　磨刀誤了砍柴工

　　由於專案本身進度緊張，往往在專案進行過程中忽略了對專案各階段產出 物的質量的評審和Review。導致到專案後期測試時候問題全部暴露出來，而這時候如果是需求引起的缺陷則往往會耗費到前期評審的5-20倍的工作量來進 行彌補。所以在軟體專案中應該注重專案各階段的評審和Review工作，提早發現問題並解決問題，避免專案後期大量返工。

4.專案的風險管理工作沒有做好

　　專案管理就是對專案中各種風險和突發事件的管理，管理住了專案的風險 專案就成功了一半。如果專案經理沒有風險管理意識，對專案可能發生的問題或潛在的不利因素都不能預測到，也沒有提前採取相關的應急措施，則在專案進行過程 中風險真正轉化為問題後就會導致專案很被動。如前期沒有分析出專案核心成員流失的風險，而在專案進行過程中該核心成員要離職，專案短期無法招到合適新成 員，專案中也沒有合適的技能替代成員，這樣對專案的打擊將是致命的。

　　另外專案還應該形成一套突發事件的應對機制，保證有突發事件時候能夠通過積累的各種方法，工具，預備的資源餘量進行跟蹤和處理。

5. 專案範圍出現大變動

　　專案範圍出現大變動，新增加了大量功能的時候往往會直接導致專案延期，在這個時候特別已經是在專案後期時候增加人員往往會使專案進度變的更糟糕。在這種時候往往沒有很好的應對辦法，加班趕進度往往成為了最常用的措施。

　　需求變更多也往往導致專案範圍的變動而影響專案進度，因此在專案管理過程中應該對變更的管理形成一套完善的管理，分析和控制機制，成立變更控制委員會專門對變更進行分析，調查和處理。

6. 專案開發模式和選用工具技術是否有問題

　　這個時候做這個分析已經不可能對當前專案有任何作用，而更多的會總結 為相關的經驗教訓避免重犯錯誤。專案開發模式，生命週期選擇，選擇的開發語言，開發環境，相關工具和技術都直接或間接的影響到專案成員的生產率，這些我們 在專案估算中可能會做相關考慮，但可能並不能從根本上解決問題，當我們預知客戶的進度要求的時候，更應該通過進度要求去約束我們工具和技術的選擇和使用。

7. 系統架構的原因

　　對於大中型系統總統設計和架構設計更顯重要。架構設計不僅僅要考慮滿 足業務的功能性需求，而進行子系統，介面，元件等的設計和劃分;同時架構設計更需要考慮滿足系統的健壯性，可擴充套件性，效能，安全性，可維護性等非功能性需 求。架構人員應該通過架構設計遮蔽整個系統的複雜性，而向模組設計和開發人員提供一套簡單，高效的開發規程和模式，這樣才能夠真正提高後續設計開發的效率 和質量。

　　對於一個新專案，更應該對專案的總體設計和架構設計預備充足的時間，架構不穩定和成熟代表根基不穩定，這樣的話修再高的樓都會倒塌。要設計一個成熟的架構，架構人員不僅僅要是技術方面的專家，也需要充分理解業務需求，這樣才能夠做出好的架構來。