风险重大问题跟踪表项目编号：项目名称：风险类别风险严重程度技术风险描述风险应对措施责任人要求解决时间实际落实情况比较高比较高比较高技术风险组织架构图的重构，将会按照灵活的设置方式，灵活的展示方式，因此对于统一的数据操作设计、接口设计上要求比较高，如果设置的方式不够灵活通用则会影响到整个功能的逻辑处理。对于最终的设计方式进行反复的讨论论证，保证得到最优的结果。通过将数据设置，数据业务构造，树形结构构造，信息展示几个业务分开来构造处理来实现。以后的逻辑只用实现一个业务构造树形即可实现一个组织架构图的展示。技术风险工作流的深度开发中涉及到复杂的逻辑处理方式，对于原来的设计方式是否能够支持扩展开发需要进一步研究讨论。如果支持不了，或者原来的设计模式存在一些问题，那么就可能需要验证修改会增加开发时间。针对原有的设计思路进行分析讨论，尽量使用原有逻辑来满足当前需求。如果满足不了则在原有基础上重新设计。原有的业务是通过一个实例的方式来实现，现在的逻辑是将出现的同步进行流程分别划分为多子实例的方式来实现多流程。需求风险目前项目需求收集阶段还没结束，在项目收集阶段完成的时候如果需求量比较大的话就会影响整个项目的开发进度。项目需求收集阶段进行严格把控，对于一定需要开发的需求纳入到此次开发中，对于不是非常着急的需求可以放入到下个版本中进行控制。已经出现一些需求不能完全确认的情况发生。目前，部分需求正在与客户沟通确认，大部分内容基本上已经确定下来。注：风险类别风险严重程度技术风险很高工程风险比较高商务风险中等管理风险比较低财务风险很低环境风险需求风险1、项目风险要注意“跟踪频次要求”，如一周一次、两周至少一次等，注意不要间隔太长2、“风险应对措施”填写风险的缓解措施和应对措施，缓解措施是指风险尚未发生时采取的规避或缓解行动；对应措施是指风险发生后采取的应对行动3、“风险类别”、“风险严重程度”等请参见“风险参数”中的说明4、风险是有“阈值”的，主要描述风险必须采取行动临界点，用直观的可观察的测量值来设定（注意针对不同风险有不同定义），临界点最好通过相关的数字指标来表5、项目经理（或其指定成员）对风险进行评估和分析时必须考虑风险的应对措施6、对于规模较小，面临的风险明确、清晰的项目可以裁剪掉“阈值”列，但必须将影响范围描述清楚7、“实际落实情况”记录项目组为规避或减缓该项风险所采取的行动或者填写...
