風險重大問題跟蹤表,,,,,,,

,,,,,,,文檔編碼：

項目編號：,,項目名稱：,,,,,

風險類別,風險嚴重程度,技術風險描述,風險應對措施,責任人,要求解決時間,實際落實情況,備注

技術風險,比較高,組織架構圖的重構，將會按照靈活的設置方式，靈活的展示方式，因此對于統一的數據操作設計、接口設計上要求比較高，如果設置的方式不夠靈活通用則會影響到整個功能的邏輯處理。,對于最終的設計方式進行反復的討論論證，保證得到最優的結果。,,,通過將數據設置，數據業務構造，樹形結構構造，信息展示幾個業務分開來構造處理來實現。以后的邏輯只用實現一個業務構造樹形即可實現一個組織架構圖的展示。,

技術風險,比較高,工作流的深度開發中涉及到復雜的邏輯處理方式，對于原來的設計方式是否能夠支持擴展開發需要進一步研究討論。如果支持不了，或者原來的設計模式存在一些問題，那么就可能需要驗證修改會增加開發時間。,針對原有的設計思路進行分析討論，盡量使用原有邏輯來滿足當前需求。如果滿足不了則在原有基礎上重新設計。,,,原有的業務是通過一個實例的方式來實現，現在的邏輯是將出現的同步進行流程分別劃分為多子實例的方式來實現多流程。,

需求風險,比較高,目前項目需求收集階段還沒結束，在項目收集階段完成的時候如果需求量比較大的話就會影響整個項目的開發進度。,項目需求收集階段進行嚴格把控，對于一定需要開發的需求納入到此次開發中，對于不是非常著急的需求可以放入到下個版本中進行控制。,,,已經出現一些需求不能完全確認的情況發生。目前，部分需求正在與客戶溝通確認，大部分內容基本上已經確定下來。,自己新增的風險類別--需求風險。

,,,,,,,,

,,,,,,,,

,,,,,,,,

,,,,,,,,

,,,,,,,,

,,,,,,,,

,,,,,,,,

,,,,,,,,

,,,,,,,,

,,,,,,,,

,,,,,,,,

,,,,,,,,

注：,1、項目風險要注意“跟蹤頻次要求”，如一周一次、兩周至少一次等，注意不要間隔太長,,,,,,

,2、“風險應對措施”填寫風險的緩解措施和應對措施，緩解措施是指風險尚未發生時采取的規避或緩解行動；對應措施是指風險發生后采取的應對行動,,,,,,

,3、“風險類別”、“風險嚴重程度”等請參見“風險參數”中的說明,,,,,,

,4、風險是有“閾值”的，主要描述風險必須采取行動臨界點，用直觀的可觀察的測量值來設定（注意針對不同風險有不同定義），臨界點最好通過相關的數字指標來表示,,,,,,

,5、項目經理（或其指定成員）對風險進行評估和分析時必須考慮風險的應對措施,,,,,,

,6、對于規模較小，面臨的風險明確、清晰的項目可以裁剪掉“閾值”列，但必須將影響范圍描述清楚,,,,,,

,7、“實際落實情況”記錄項目組為規避或減緩該項風險所采取的行動或者填寫風險的當前狀態，風險狀態分為三種：“未發生”表示風險存在尚未發生；“已發生未關閉”表示風險已發生但未解決；“已關閉”表示風險不存在了或已解決了,,,,,,

,,,,,,,,

,,,,,,,,

風險類別,風險嚴重程度,,,,,,

技術風險,很高,,,,,,

工程風險,比較高,,,,