針對中小銀行實施類項目風險管理分享
只要是項目肯定都會存在或多或少的風險，一個看似風平浪靜的項目不是他沒有風險、沒有問題，而是要麼風險被我們提前預估並解決掉；要麼風險一直隱藏在項目中，並終會爆發成問題，對項目產生不利的影響，甚至導致項目的失敗。
「
總述：
針對中小銀行客戶（包括城商行、外資銀行等），在行方科技和業務沒有規範的管理流程和管理經驗時，我們在這類客戶現場實施項目需要全靠自己來把控。大家都知道項目管理中必須要有風險意識是非常重要的，那針對這類客戶，如何在項目周期的每個環節預知風險、應對風險並化險為夷？下面以某一家中小銀行客戶實施類項目為例，分享這個實施類項目整個項目周期中每個風險節點及解決措施。
」
（案例）某中小銀行客戶基本情況：
這家小銀行有國資和外資背景，目前在國內只有3個分行，4個支行。我們中標這家新客戶做一個實施類項目，項目成員由我們公司和行方科技開發人員組成。由於該銀行剛剛起步，行方科技和業務沒有管理流程，主要靠我們來推動整個項目的實施。而且該銀行在業務需求方面要求與其他行也不同，行方要求在需求討論、需求確認、UI設計確認、UI設計評審、需求評審、需求籤字都需要總行及各個分支行負責人都評審簽字確認才算通過。與我們之前實施的大多數行是以總行主導存在很大差異，增加了我們實施項目的不確定性和風險。
項目全生命周期中每個關鍵節點的風險點如下：
1、確定項目範圍階段
2、需求討論和需求確認階段
3、UI設計確認階段
4、需求評審、UI設計評審及需求確認簽字階段
5、開發階段
6、測試階段
7、項目投產階段
8、項目結束後的成本控制
下面針對每個風險節點展開陳述：
風險一：確定項目範圍階段風險：
風險描述：
（一）、當項目範圍與合同的SOW不一致時。在我們入場後與行方過SOW時（合同中項目範圍SOW），由於行方基於實際現狀，SOW範圍裡面的一些功能：比如代發工資、理財版塊、票據等功能在一期不做，這樣我們在合同中的SOW就縮剪了很大一部分內容。
（二）、當時意識到潛在風險是如果SOW中的內容被裁剪，在項目投產驗收時，就會出現兩種可能：要麼縮減合同金額，要麼以沒有完成合同中SOW範圍的功能而延遲驗收和付款。
解決措施：
當時和公司領導協商後，我們和行里積極溝通，提出了方案並得到行方認可：
（一）、我們與業務負責人溝通，從行方挖掘出不在一期範圍內的業務緊急訴求，比如想做大量的報表等。
（二）、我們把被行方從一期裁剪的功能評估詳細的工作量和等量的新增功能詳細工作量提交給行方科技和業務負責人，說明了新增的工作量是替換裁剪的功能，確保合同額不變，計劃不變。
風險二、需求討論和需求確認階段風險：
風險描述：
剛開始需求討論階段，我們先按照項目範圍寫好一版需求文檔，然後提前約好各個業務部門的介面人，在會議室一起需求討論，然後根據修改意見進行修改。再郵件發給各個分支行進行確認。在這個過程進行兩周左右，發現了如下嚴重的問題：
（一）、由於項目周期緊張，在約各個業務部門介面人時，由於他們也比較忙，經常約不齊參會的人，一周約不了兩次。
（二）、在討論會上，各持己見，參會人員對一個功能有不同的想法，更可怕的是，經常會返工，原本以確定的功能又經常變化，導致需求討論和確認進度很慢。
（三）、在具體需求討論和需求漸進明細時，根據談合同時定的需求範圍，除了上面風險一講的確定項目範圍所採用的方式，另外還有其他刪減和新增功能範圍，與行里無法達成一致。根據這些情況按照原定的項目計劃根本無法完成需求討論和需求確認。
解決措施：
我們與行方科技和業務負責人詳細溝通了問題的嚴重性，提出方案並獲得行方的認可：
（一）、需求討論不再以討論會的形式進行，以我們線下單獨分別找各自的業務介面人進行需求討論，可以錯開不同業務介面人忙的時間。
（二）、並且把線下溝通確認後的需求文檔，由業務介面人發郵件給各個分支行業務做確認，在規定時間內如果沒有回復就默認同意，如果有回復，我們會和業務介面人確認後更改需求文檔。
（三）、我們與行方確定規則，在談需求的過程中與原範圍不一致時，新增的功能都配合談，不單獨對某個功能是否實現糾結，等到全部談完後，把之前談的所有範圍外新需求與行方開會評估一次，排一個優先順序，確定哪些是一期必須實現的，哪些是後期實現。
通過這樣的方式保證了進度，按照原計劃完成了需求討論和需求確認。
風險三、UI設計確認階段風險
風險描述：
UI設計確認行方延遲。在我們為行方做了三套不同風格的首頁及頁面樣式，行里發給總行和各個分支行提建議，這個過程中我們做了很多次的修改，但是行里遲遲沒有給我們確認使用哪一套風格，按照我們的項目計劃，對我們的開發進度有影響。
解決措施：
我們與行方科技和業務負責人溝通好，在UI設計行方未確認前，我們暫時不考慮頁面樣式，先進入開發階段，待行里確定了首頁和頁面樣式風格後，我們集中安排前端人員進行切圖和寫前端頁面，並且提前定出前端和後台的介面規範，方便前後台對接，這樣就不會影響我們的進度。同時也催行里儘快確認頁面樣式。
風險四、
需求評審、UI設計評審及需求確認簽字階段風險
風險描述：
由於行方要求需求和UI設計必須由總行和各個分支行負責人都同意才能評審通過並簽字，所以給需求和UI設計評審增加了難度和風險。如果需求不通過評審和簽字，為我們後續開發過程中的需求變更和項目驗收收款埋下了不可控的隱患。
解決措施：
（一）、我們與行方科技和業務負責人溝通，需求和UI設計評審通過視頻會議方式邀請各個分支行全員參加，集中兩天時間進行評審。
（二）、考慮到評審時的效果，我們專門做了動態演示demo，在評審過程中以動態演示demo為主，需求文檔解釋為輔的方式進行。
（三）、需求確認簽字由我們幫行方製作了簽字表，並由總行牽頭要求涉及到的負責人都簽字，各個分支行簽字後傳真給總行。
（四）、由於行方科技和業務負責人擔心簽字後有需求變更時我們不配合修改的情況，對此我們給行方保證，我們和行方一起規範需求變更流程，當後續在開發、測試階段有業務提出變更，我們會和行方一起評估變更的可行性、修改難度和工作量，如果不影響進度的改動我們是可以修改，如果改動太大，我們會考慮在二期實現。這樣就掃除了行里的顧慮。而且在評審會期間，分管副行長、科技部門和業務部門老總全程參加了需求評審，並在會後分管副行長詳細交流了記錄的業務疑問。通過上面的方法，我們達到了預期的效果，並且保證了進度和消除了隱患。
風險五、開發階段風險
風險描述：
由於實施的子項目多，每個子項目功能點多，時間緊，並且項目組大部分開發人員是新人的情況下，按照項目計劃，是無法完成開發並順利提交測試。
解決措施：
（一）、我們制定好前後端介面規範，採用前後端分離，並行開發的方式。
（二）、並且與行方溝通評估實際情況，採用分批次提交測試的方式進行。
（三）、針對新人多的情況，我們一方面採取晚上給新人集中培訓技術和業務，另一方面採用以老帶新，鼓勵新人不懂就多問，並由老人開發一個模塊作為模板，由新人參考來做，能夠讓新人快速上手。
（四）、我們每天根據站立會上拋出的問題，並以天為單位，給行方郵件和當面彙報，包括：目前開發中遇到的問題及解決方案，涉及到行里環境問題、關聯繫統的問題就請行方協調解決，通過這種方式讓行方能夠參與進來並實時了解到項目的實際情況。通過上面的措施，項目順利按照分批次逐步提交測試。
風險六、測試階段風險：
風險描述：
由於開發周期短，測試階段缺陷多，居高不下，行方對我們的開發質量和進度產生質疑。
解決措施：
（一）、一方面要求開發人員當日缺陷當日關閉。當日未關閉的缺陷要說明原因。
（二）、同時每天與每個開發人員、測試人員分別過所有的缺陷，對缺陷進行分類：哪些是我們自己的缺陷，並制定修復計劃，明確到每個缺陷的修復時間點。哪些是關聯繫統的缺陷，哪些是環境引起的缺陷，需要讓行方協調解決。
（三）、在每天過完缺陷後給行方郵件和當面進行彙報，讓行方能夠實時了解目前的缺陷修復進度和協調行方環境及關聯繫統的問題。
（四）、進行到測試階段後期出現大部分的缺陷是行方科技開發人員的，我們幫行方科技開發人員修復了不少缺陷。通過這樣的方式讓行方打消了對我們的質疑，並取得行方對我們的認可和信任。
風險七：項目投產階段風險：
風險描述：
由於行方針對本次投產是新老系統更替，之前的老系統是其他公司做的，老系統的數據遷移行方也要求我們來做，我們預估到投產後問題多的風險。
解決措施：
（一）、我們給行方建議新系統至少進行1個月的投產試運行，採用白名單的方式，由行方找一家關係老客戶，我們廣州分公司也在該行開了對公戶用於試運行期間的測試，針對這兩個真實客戶在投產試運行時，通過真實環境把全功能進行測試，並且驗證了數據遷移結果。
（二）、協調行方在試運行期間安排了多次問題投產。確保了項目在正式對外後我們項目的穩定性。
風險八：項目結束後的成本控制風險：
風險描述：
在項目投產正式對外後，行方原因無法及時確定二期的實施範圍和時間，中間出現了斷層的情況，當項目組沒有產出，項目成員都還在客戶現場時，成本無法控制。
風險措施：
（一）、針對這個問題，我們提前預估，一方面在一期項目的測試階段，我們就開始找行方負責人溝通後續優化需求。為二期項目做準備。並且把投入二期的成本放到新立的二期項目中。
（二）、行方安排三輪UAT測試，每輪UAT測試結束都會抽調各個分支行的業務人員到總行進行階段性驗收，在這個過程中，我們也積極與分支行業務人員溝通，挖掘優化需求和新的訴求並整理，並把投入二期的成本放到新立的二期項目中。
（三）、另一方面項目組在測試後期，我們就和公司領導協商逐步把項目成員抽調到公司的其他項目組支持。
（四）項目組留下部分人員作為遵循合同中的維護期運維，同時談二期的優化需求。以確保一期項目的成本可控和盈利。
精銳學習的平台 | 學習精銳的平台
TAG:YNET精銳營 |