管理軟體開發專案關鍵風險 (轉)

ger8發表於2007-08-15
1.人員流失風險
考慮了下,還是把人員流失作為專案第一大風險,軟體專案管理最重要的還是人的因素。特別是關鍵專案成員流失可能會導致整個專案的重大延期和失敗。人的職業過程中主要受到金脈,知脈和人脈三個因素的影響,任何一個因素出現重大問題或積累到一定量後都會導致直接的人員流失。所以這三個因素就是人員流失的真正根源,我們的應對措施也分為了積極樂觀應對措施和消極悲觀應對措施兩大型別。

對於積極樂觀應對措施:
金脈-給專案關鍵和貢獻大成員加薪,提高福利和待遇水平。
知脈-讓專案成員在專案中始終能夠學到東西,始終能夠承擔有調整性的工作,組織專案成員進行新知識和新技能的培訓。
人脈-持續進行專案團隊建設,溝通,活躍整個專案團隊氣氛,使專案成員相處融洽。

對於消極悲觀的應對措施
CMMI過程和文件-所有東西都要形成過程和文件
資源後備-對關鍵崗位的資源要進行人力的後備,可以透過崗位互換,專案內培訓等多種方式進行。

2.專案內人員技能無法達到要求
專案人員技能無法達到要求會影響到整個軟體產品的質量,其中包括易用性,健壯性,可擴充套件性和可維護性等多方面的內容。在軟體整個生命週期中,需要有需求,設計開發和測試等相關人員的專業分工,期望透過軟體工廠似的流水化作業創造產品。這個問題的解決方式應該更好的透過事前預防和事後控制的途徑進行更好的應對。

事前預防:
招聘和選人-專案應該投入到更多的精力到人才的招聘和選擇上。有時候我們並不是一定期望選擇到優秀的人才,但往往是選擇到合適的人也很困難,其中一個重要因素是我們沒有認真的去對待這件事情,如何招聘到一個合適的人才的方式和方法我們並不是充分理解。
架構獨立-把專案總體設計和架構設計安排專門的1-2個人員來完成,減小對模組設計開發人員的技能要求。

事後控制:
以師帶徒-以師帶徒是專案內輔助新員工成長和發展的最佳和最有效的途徑。
專案內培訓-統一組織專案新員工進行專案內相關特殊技能的培訓
自我學習-安排專門的時間給新員工自學,包括組織級規範,專案內特殊規範,專案開發模式和原始碼方面的學習。

3.需求不明確和需求變更多
需求不明確直接的表現就是目標和範圍不明確,專案管理的首要過程域就是專案範圍管理,如果這個都不明確直接導致一個專案無法開展,導致專案成員沒有共同奮鬥的目標。需求是源,需求階段的洩露會導致整個專案各階段工作量的增加,導致原有已經完成功能的推倒重來,影響專案成員的信心和積極性。
對於需求不明確和需求變更多的應對措施主要有:
快速原型-儘快給使用者一個快速原型啟發使用者的需求。
增量迭代-整個開發中遵循增量迭代的思路,加強各階段與使用者的溝通,對各個功能逐步完善
架構考慮可擴充套件性-架構和設計都要考慮是為變更而設計,而不僅僅是滿足當前需求。
需求開發-需求人員不僅僅是描述清楚使用者需求,而更多的應該是去開發使用者需求,去挖掘使用者的潛在需求。

4.專案中應用新技術
新技術的使用可以使專案滿足一些特殊的需求,增加專案的靈活性,擴充套件性和複用。但新技術的應用也不可避免的帶來風險。其一是專案成員是否能夠很快的學習和掌握這麼新技術,其二是新技術本身是否存在缺陷。對新技術使用的應對主要考慮:
新技術使用前培訓-對專案所有成員進行新技術的培訓,並驗證培訓效果,確保成員已經掌握新技術。
新技術原型驗證-要出一個採用新技術的原型和框架,對新技術進行確認和驗證。
計劃上考慮-使用新技術的時候,做專案進度計劃時候應該適當降低生產率和安排專門的學習時間。

5.系統介面受外部諸多系統的影響
這些內容都屬於專案關鍵依賴的內容,而且這些東西不是透過你專案自身努力就可以達到和完成的。關鍵依賴能否滿足存在諸多的不確定性,這些都是專案實實在在存在的風險。
對外部-提前和外部介面系統進行溝通和協商,提前進行分析,提前確認相關的進度和整合,聯調計劃。
對自己-可以自己模擬些相關的介面,提前進行驗證和分析。
[@more@]

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7839396/viewspace-960389/,如需轉載,請註明出處,否則將追究法律責任。

相關文章