风险重大问题跟踪表 项目编号： 项目名称： 风险类别 风险严重程度 技术风险 比较高 组织架构图的重构，将会按照灵活的设置方式，灵活的展示方式， 对于最终的设计方式进行反复的讨论 因此对于统一的数据操作设计、接口设计上要求比较高，如果设置 论证，保证得到最优的结果。 的方式不够灵活通用则会影响到整个功能的逻辑处理。 比较高 工作流的深度开发中涉及到复杂的逻辑处理方式，对于原来的设计 方式是否能够支持扩展开发需要进一步研究讨论。如果支持不了， 或者原来的设计模式存在一些问题，那么就可能需要验证修改会增 加开发时间。 针对原有的设计思路进行分析讨论， 尽量使用原有逻辑来满足当前需求。 如果满足不了则在原有基础上重新设 计。 目前项目需求收集阶段还没结束，在项目收集阶段完成的时候如果 需求量比较大的话就会影响整个项目的开发进度。 项目需求收集阶段进行严格把控，对 于一定需要开发的需求纳入到此次开 发中，对于不是非常着急的需求可以 放入到下个版本中进行控制。 技术风险 需求风险 比较高 技术风险描述 风险应对措施 责任人 注： 1、项目风险要注意“跟踪频次要求”，如一周一次、两周至少一次等，注意不要间隔太长 2、“风险应对措施”填写风险的缓解措施和应对措施，缓解措施是指风险尚未发生时采取的规避或缓解行动；对应措施是指风险发生后采取的应对行动 3、“风险类别”、“风险严重程度”等请参见“风险参数”中的说明 4、风险是有“阈值”的，主要描述风险必须采取行动临界点，用直观的可观察的测量值来设定（注意针对不同风险有不同定义），临界点最好通过相关的数字指标来表示 5、项目经理（或其指定成员）对风险进行评估和分析时必须考虑风险的应对措施 6、对于规模较小，面临的风险明确、清晰的项目可以裁剪掉“阈值”列，但必须将影响范围描述清楚 7、“实际落实情况”记录项目组为规避或减缓该项风险所采取的行动或者填写风险的当前状态，风险状态分为三种：“未发生”表示风险存在尚未发生；“已发生未关闭”表示 风险类别 技术风险 工程风险 商务风险 管理风险 财务风险 环境风险 需求风险 风险严重程度 很高 比较高 中等 比较低 很低 险重大问题跟踪表 文档编码： 要求解决时间 实际落实情况 备注 通过将数据设置 ，数据业务构造 ，树形结构构造 ，信息展示几个 业务分开来构造 处理来实现。以 后的逻辑只用实 现一个业务构造 树形即可实现一 个组织架构图的 展示。 原有的业务是通 过一个实例的方 式来实现，现在 的逻辑是将出现 的同步进行流程 分别划分为多子 实例的方式来实 现多流程。 已经出现一些需 求不能完全确认 的情况发生。目 前，部分需求正 自己新增的风险类别--需求风险 在与客户沟通确 。 认，大部分内容 基本上已经确定 下来。 意针对不同风险有不同定义），临界点最好通过相关的数字指标来表示 险状态分为三种：“未发生”表示风险存在尚未发生；“已发生未关闭”表示风险已发生但未解决；“已关闭”表示风险不存在了或已解决了 风险来源一 序号 风险来源分类 风险来源 风险描述 财务风险 公司内部 项目的经费是否充足 1 工程风险 公司内部 在开发的产品中是否存在很 少有人真正需要却自以为很 好的情况 2 工程风险 公司内部 开发小组是否采用比较有效 的分析、设计、编程、测试 工具 3 工程风险 公司内部 分析与设计工作是否过于简 单、草率，从而让程序员边 做边改 4 工程风险 公司内部 开发小组是否采用统一的编 程规范 5 工程风险 6 工程风险 客户 客户指定的需求和交付期限 在客观上是否可行 7 工程风险 客户 客户的合作态度是否友善 1 管理风险 公司内部 对项目的规模、难度估计是 否比较正确 2 管理风险 公司内部 进度安排是否过于紧张、是 否有合理的缓冲时间 3 管理风险 公司内部 4 管理风险 公司内部 5 管理风险 公司内部 6 管理风险 公司内部 7 管理风险 公司内部 财务风险 1 工程风险 基础平台/第三方 项目所需的软件、硬件是否 产品 能按时到位 管理风险 进度表中是否可能遗忘一些 重要的（必要的）任务 进度安排是否考虑了关键路 径 是否可能出现某一项工作延 误导致其他一连串的工作也 被延误 任务分配是否合理（即把任 务分配给合适的项目成员， 充分发挥其才能） 本项目是否得到上级领导的 重视 8 管理风险 公司内部 上级领导是否过多地介入本 项目的事务并且瞎指挥 9 管理风险 公司内部 行政部门的办事效率是否比 较底，以至于拖项目的后腿 10 管理风险 公司内部 行政部门是否经常干一些无 益于生产力的事情，以至于 骚扰本项目 11 管理风险 公司内部 13 管理风险 公司内部 14 管理风险 公司内部 17 管理风险 公司内部 18 管理风险 公司内部 19 管理风险 资源投入 21 管理风险 资源投入 项目成员是否团结 22 管理风险 资源投入 是否绝大部分的项目成员对 工作认真负责 23 管理风险 资源投入 是否绝大部分的项目成员有 工作热情 24 管理风险 资源投入 团队之中是否有“害群之马” 25 管理风险 资源投入 技术开发队伍中是否有临时 工 26 管理风险 资源投入 本项目开发过程中是否会有 核心人员辞职、调动 28 管理风险 资源投入 项目经理是否忙于行政事务 而无暇顾及项目的开发工作 29 管理风险 资源投入 上级领导是否随时会抽调本 项目的资源用于其他“高优先 级”的项目 环境风险 市场 是否有不可预测的市场动荡 机构是否能全面、公正地考 核员工的工作业绩 本项目的合作部门的态度是 否积极、做事与承诺的是否 不一致 开发人员对测试工作是否重 视、能否保证测试的客观性 开发人员懂得版本控制、变 更控制、能够按照配置管理 规范执行 开发人员是否重视质量、是 否会在进度延误时降低质量 要求 人力资源（开发人员、管理 人员）是否合格够用 环境风险 1 竞争对手可能有不正当的竞 争行为 政府或者其他机构对本项目 的开发是否有限制 5 环境风险 市场 1 环境风险 政策/法律 3 环境风险 政策/法律 是否有不利于我方的官司 3 技术风险 公司内部 需求文档是否能够正确地、 完备地表达用户需求 4 技术风险 公司内部 需求开发人员能否与客户对 有争议的需求达成共识 5 技术风险 公司内部 需求开发人员能否获得客户 对需求文档的承诺，以保证 客户不随便变更需求 6 技术风险 公司内部 开发人员是否有开发相似产 品的经验 7 技术风险 公司内部 待开发的产品是否要与未曾 证实的软硬件相连接 8 技术风险 公司内部 对开发人员而言，本项目的 技术难易程度如何 9 技术风险 公司内部 开发人员是否已经掌握了本 项目的关键技术 10 技术风险 公司内部 如果某项技术尚未实践过， 开发人员能否在预定时间内 掌握 11 技术风险 客户 客户的需求是否含糊不清 12 技术风险 客户 客户是否反反复复地改动需 求 13 技术风险 客户 客户对产品的健壮性、可靠 性、性能等质量因素是否有 非常过分的要求 1 商务风险 供应商/承包商 子承包商、供应商的信誉如 何 2 商务风险 供应商/承包商 子承包商、供应商是否有可 能倒闭 技术风险 商务风险 3 商务风险 子承包商、供应商是否能及 供应商/承包商 时交付质量合格的产品（或 部件） 4 商务风险 供应商/承包商 子承包商、供应商有能力做 好售后服务吗？ 5 商务风险 合同 与客户签的合同是否公正、 是否双方互利 6 商务风险 合同 与子承包商、供应商签订的 合同是否公正、双方是否互 利 7 商务风险 客户 客户的信誉如何？例如按客 户的需求开发了产品，但是 客户可能不购买。 风险来源一览表 可能影响范围 标准应对措施 1、项目资源投入 2、项目调研次数和力度 1、找公司高层沟通增加经费 2、或者找公司高层或客户缩小项目范围 1、进度、成本超出控制 2、增加了产品使用的复杂度和易用性 1、在需求分析阶段加强与客户的确认，让客户 确定功能是否需要 2、引入领域专家，通过领域专家的培训、沟通 说服相关人员 3、在形成《需求说明书》中必须确定需求实现 的先后顺序 1、在项目策划时评估项目组成员是否需要接受 1、沟通效率低 2、返工 工具的培训 2、通过小范围的预研工作确定项目组成员对工 具的掌握技能 1、不断返工 2、士气低落 3、进度超出控制 1、加强需求分析和设计的评审力度 2、评估分析和设计的时间安排是否合理，否则 加强与相关人员的沟通 1、沟通效率低 2、程序难以理解，难以维护 1、评估项目成员对公司内的编程规范的熟悉程 度 2、必要时，组织对公司编程规范的培训 项目的进度落后和工期延长 1、及时与公司商务人员、供应商商务人员的沟 通，了解设备到货情况 2、督促有关人员加快到货进度 3、考虑是否有替代的软件和硬件，必要与相关 人员落实 4、准备项目计划变更申请报告，通知有关方可 能需要更改项目计划 1、项目质量严重下降 2、无法按时交货 3、最终导致客户满意度降低 1、内部加强评审和确认 2、利用公司历史数据评估 3、必要时与客户沟通，准备相关材料说明理由 4、必要时增加人手或借助外部资源 1、需求分析的深度 2、项目的进度 3、员工的士气 1、及时向公司高层和市场人员汇报 2、找客户有关领导沟通 1、严重进度和成本/费用偏差 2、频繁的变更，增加了管理成本 估算时设定一个放宽系数 1、频繁的变更，增加了管理成本 2、项目质量的下降 1、严重进度和成本/费用偏差 2、频繁的变更，增加了管理成本 1、项目进度落后 2、重大问题增多 1、严重进度和成本/费用偏差 2、频繁的变更，增加了管理成本 1、内部加强评审和确认 2、利用公司历史数据评估 3、必要时与客户或高层沟通，准备相关材料说 明理由，准备计划变更 1、内部加强评审和确认 2、发生时及时汇报，变更计划和项目估算 内部加强评审和确认 1、内部加强评审和确认 2、高层经理加强进度和关键任务的监督 1、项目进度落后 2、员工满意度降低 内部加强评审和确认 1、得不到应有的资源支持 2、重大问题无法解决 1、项目启动会邀请高层经理