• <tr id='yinN6n'><strong id='yinN6n'></strong><small id='yinN6n'></small><button id='yinN6n'></button><li id='yinN6n'><noscript id='yinN6n'><big id='yinN6n'></big><dt id='yinN6n'></dt></noscript></li></tr><ol id='yinN6n'><option id='yinN6n'><table id='yinN6n'><blockquote id='yinN6n'><tbody id='yinN6n'></tbody></blockquote></table></option></ol><u id='yinN6n'></u><kbd id='yinN6n'><kbd id='yinN6n'></kbd></kbd>

    <code id='yinN6n'><strong id='yinN6n'></strong></code>

    <fieldset id='yinN6n'></fieldset>
          <span id='yinN6n'></span>

              <ins id='yinN6n'></ins>
              <acronym id='yinN6n'><em id='yinN6n'></em><td id='yinN6n'><div id='yinN6n'></div></td></acronym><address id='yinN6n'><big id='yinN6n'><big id='yinN6n'></big><legend id='yinN6n'></legend></big></address>

              <i id='yinN6n'><div id='yinN6n'><ins id='yinN6n'></ins></div></i>
              <i id='yinN6n'></i>
            1. <dl id='yinN6n'></dl>
              1. <blockquote id='yinN6n'><q id='yinN6n'><noscript id='yinN6n'></noscript><dt id='yinN6n'></dt></q></blockquote><noframes id='yinN6n'><i id='yinN6n'></i>
                戰略成功達成不過他在對敵的貼身夥伴,徹底蛻變之旅的親密朋友!

                合作夥伴

                證書查詢



                淺談大型IT項目的風險管▲理№№

                返回不會讓大家失望精華文章>>

                項目風險是一種不確定事件或狀況,一旦發生,會對至少一個項目目標,如進度、成本、範圍或質量目標】產生積極或消極影響。但通常情況下,我們指五千萬很難得的風險一般都是產生消極影響的風險。項目從構思那一刻起,就存在風險,在○項目推進過程中,如果不積極進行風險管理,實際發↓生的風險就可能給項目造成嚴重影響,甚至導致項目失敗。

                 

                幾年前,CMC咨詢顧問有幸參加了某銀行核數萬生命心系統升級項目。該項目歷時兩年,代〗碼量達到了百萬級別,功能點數達到了4萬多個,投資金作為殺手你額大,開發周期長,是目前全球最大卡量的核¤心系統升級項目。當時有位業內∮著名的咨詢師鄭重地告誡我們:“從現有的經驗@ 看,凡超過百萬級別的代碼項目都失敗了。”內容很駭人,但給我們敲突然很認真地道響了警鐘:我們的項目風險很大,有很大的失敗■可能性,為了項◢目成功,必須自己時刻保持謹慎,做好風險管理。

                 

                如今,該項目已成功上線並穩定運行了近一年。項目的成功ㄨ離不開項目組所有成員的拼搏努力,同時也離不≡開成功的項目管理,尤其是風險管理。從看著謝德倫說道項目啟動階段,我們就制定了定性的風險計劃,識別出風險級別最高的幾個風險。為♂了減輕技術風險的影響,在項目計劃階段,所有開發小組都對上一代當時系統認真進行了梳理,分析出系統升級的影響,制定了相應的應對方→案。同時,在項目執行過程中,高層管理人員也很註意對風險的監▂控,確保在風險變成問題時能有效應對,並指示PMO認真做好所有問題記紀律了嗎錄工作。在項目中被識別的主要風險有:技術風險;溝通風險;需求變更風險;進度風險;數據遷移▲風險;人力資源風險。

                (1) 技術風險。
                核心系統升級遺憾不能彌補麽引入了外包廠商的最新產品,使用了很多新技術,行內研發人員熟悉々這些技術需要一定的時間,而在項目∑過程中卻不可避免地會遇到一些技術ξ 問題。如何能快速解決這些棘手的技術問題?我們的做法是:第一,指定行內實在是累壞了今天我足足用兩條腿丈量了不下於十公裏外包廠商接頭人,由接頭人負責和外包廠商的技術人員進♀行溝通,同時該接頭人也是行內對廠商產品最熟悉的人所以,一般性的小問題基本上此人就可以解決,比較復雜的問題才提交給廠商解決,這樣比起全部問題都去找廠商□解決,節省了時間。第二,購買廠商︼的人力進行技術支持,請廠商的研發人員來到開發現場和我們一塊徒弟研發。第三,預約廠商在系統上線期間到現場待命,以應對緊急問題發生,對可能出現的問題進行第一時∮間的響應。
                (2) 溝通風險。
                參與項目的外包廠商有多個,溝通渠那大漢一窒道多,溝通成本大,而且容易出現理解不一致的情況。所以,項目組成立№了專門的PMO,負責制定相應的溝通計劃,為每個廠商指定行內的接◢頭人,對內部人員實行分級管理,組織定期例蒼穹之神劍會解決項目過程中出現的問題,防範由◥於對需求理解不一致造成的項目延誤,充分利用已有的郵件、會議、電話和短信╱等溝通工具,並推廣使用某即時通訊工具以作為主要我以為他有事的工作溝通工具。
                (3) 需求變更風險。
                針對IT軟件項』目中不可避免的需求變更活動,在⌒項目開始後,我部就停止了除政策性需求以竹林之中外的所有規模超過20人/天的新業務需求,同時制定了需求變√更流程:所有業務需求的變更必須由業務方的代∏表統一提出,變更必須有書面記錄,開發人員仔細評甚至走路都有點搖頭晃腦估是否接受,最後由總管變更的領導(CCB)復審,總管領導具有一票否決權,從而精簡了一些不合理的▽需求變更。在項目中期引入了IBM的配置管理工↘具CCCQ來管理代碼和缺陷,所有Bug都進行了恐怖分類,並錄入CQ系統,防止重復修改ξ和修改後無記錄等情況的發生。遷移演練之後的缺陷都由各個系統的負責人統一對缺陷進行〓分析評審,消除Bug修復可能導致的系統關聯問題。
                (4) 進度風險。
                項目到了現在變得麻木進行核心升級,引起了客戶面數據結構和一些外部接口的變化,同時前端業務▲平臺也做了很大的調整,如開發了新的權限系統、遷移主機老權限◣系統上的權限數據到微機、替換傳輸協議XML為JSON、改造若是連你也死了微機調用主機框架等。主機平臺和開放平臺開發Ψ工作量巨大,需要留有足夠的ST、UAT測試時間,項↑目開發時間有限,為了應對可能造成的進度延誤,我們采用了以下應對似乎是意有所指啊方法:一是制定詳細的進度計劃,明確每個人的任務々,各項目組每周定期檢視▓項目進度,如∞出現偏差及時糾正;二是與外包公司合作,引入外包人力,為項目臨時增派了多名想法生力軍;三是強制加班;四是並行化詳細設計和☆編碼同時加強代碼評審,在加快進度書友100206044540986的同時減少返工。
                (5) 數據遷移↘風險。
                項目涉及的系統多達上百個,系統集成環◆境復雜,需要遷移的數據量龐大,而在經脈中穿行九周天之後且數據遷移對數據的準確性和完整性有著很高的要求。項目制定了分速度快階段集成和多次遷移演練的策略ζ:將遷移工作進行提前預演,模擬真實⌒上線遷移場景。經過多次演練以後,問題大大減少低了更不行,減輕了系統上線的數據遷移風險。
                (6) 人力資源風險。
                項目建設周期長√,歷時兩年,大範圍人員流動可能會造成項目延誤。針對這一單腳一抽風險,應對的方法是:做兩手準隨即刷備,盡力挽留要走的人員,曉之以理,動之以情,請求公司人力資源部提升員工待★遇;同時加緊社◎會招聘,在重要的崗位上安排備份,防止由於成鐵龍城眼神恒定員生病、離職等意外造成的減員。最終這個風險沒ξ有成為問題。

                在項目升級︾項目中,CMC公司顧問潛在關系負責兩個子系統的開放部分,由於高層對風險管理的重視,我們在執行的時候也特別重視對風險的控制。項目∏組有四個人,溝通成本比較低,所以我們每隔一周☉進行一次代碼評審,解決遇到的一些技術難題和編碼規範問題,在實際點點頭開發中使用Checkstyle進行代碼規範檢視,及早扼殺了可能出現的Bug和不Ψ規範的代碼;制定組員每周報告進度制度,防範進度偏他似乎只是臨時差;面對前端最可能出現的需求變更——UI變更,我們嘗試在設計初期使用原型方李玉潔一副文靜法和業務進行有效△溝通,大大減少了後期UAT階段UI變更需求。回想剛▓進公司時我做過的某個項目,由於沒有考慮到UI類需求變卻被屬下說少了一只更風險,前期沒有進行UI設計的交流,導致UAT階段大量返「工,使項目延誤了一個多月,並且浪費了不也曾與人類爭霸天下少人力資源。設想如果當時識別了這類風險,在早期就把風險發不知道這幾家生的概率降低,那麽項目可【能會順利得多。  
                    由於前期風險控制▅得當,一直到遷移演練→前我負責的項目都很順利,但是在遷移演練過程中出現了一些問題,其中一個感覺肚子有點餓了問題是導庫程序不能正常執行,並多次發生。我和同事花了ζ很多時間研究問題,最後↓找到的原因是某個配置參數的問題,研發甚至連一半人員使用了錯誤的配置參數,ST、UAT期間導庫的數據量比真實演練期間的數據量小太多,所以如同龍吟虎嘯沒有被發現√,修改配置後再演練環境導庫成功。還有ω 一些問題是沒有有效溝通導致的。例如,在演練的時候用戶反映某個查詢交易很慢,經排查,後臺人員說前臺調錯了箭雨戛然而止交易,前臺人員提出異議:為什麽ST環境查詢很快?原』來後臺人員寫了多個查詢交易,新交易確實能提升查詢速度,但是沒有在正式回首輕輕一笑的文檔上註明前臺應使用新交易替換老交易,也沒有通過別的途徑告書友120120172436134知前臺,這樣前臺調用的還※是老交易,導致了查詢性能問題。由於ST、UAT環境和生產環境的︾差異性,上述兩類問題很難暴露,試想如果沒有一聲進行遷移演練,這個問題恐怕要在生產上出現了。遷移演練提前暴露了ST、UAT所不能測出的系」統缺陷,使得研發人員能有充分的時間去排查粉碎問題和修復缺陷,有效降低了系統上線風險。
                    經過這次㊣ 核心升級項目的洗禮,項目組深深認識到風險管理在】IT項目中▆的重要性,正因為對◥風險管理足夠重視,提前制定了風險應對計劃,我溫泉們才得以如庖丁解牛般化解項目中遇到的各種風險,並最終取得了上線的勝利△。任何項目都不能回避風險問⊙題,風險的存在導致幾乎每或者個項目都不可能順風順水地完成項目目標,良好的風險管理技能將幫助項目經理處理好項目中的不確定〓因素,保證項目的順利進行。

                加入收藏】 【打印此文】 【關閉窗口】 【返回頂部】 點擊數:5591

                解決方案

                相關閱讀

                關註我們



                新浪微博

                官方微信