项目风险常见清单列表库

---

前言

        很多项目经理对于项目风险非常重视，但是在风险管理中经常不清楚会遇到什么风险，其实在项目的每个阶段遇到的风险都不尽相同。
        比如需求阶段，经常会遇到的需求变更问题，产品规划问题，需求不清晰等等，还有人员、流程、计划，沟通等风险。提供给大家一些常见的风险清单，不过因为每一家企业和组织的环境不同，项目的不同，风险也各不相同。
        需要每个项目经理建立属于自己的风险库，并且对应的建设风险应对措施库，这样在当你遇到相关风险的时候就再也不会无所适从了，轻松自如应对，方能显示你的专业能力。

---

提示：以下是本篇文章正文内容，下面案例可供参考

一、需求

• 需求变更导致的项目计划变更风险
• 需求变更导致的测试用例追加以及测试工作变更风险
• 产品规划和定位不清晰
• 干系人对需求的决策视角较长
• 频繁添加额外的需求，产品规模比估算的要大
• 需求不清晰，产品定义模糊混乱的部分比期望 需求更多的时间
• 需求涉及到模块重构导致额外工作量
• 涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多
• 开发额外不需要的功能（镀金）延长了计划进度
• 需求已经成为项目基准，但需求还在继续变化
• 需求定义欠佳，而进一步的定义会扩展项目范畴
• 在做需求中客户参与不够
• 缺少有效的需求变更管理过程

二、人员风险

• 项目人手不足。（一般会有一个估算资源需求，但实际资源）
• 招聘人员所花时间比预期的长
• 项目结束前有人离职
• 新入项目成员，额外的沟通成本
• 有问题的成员拖慢团队效率
• 项目缺乏关键核心人员
• 关键人物只能兼职参与
• 没有找到项目急需的具有特定技能的人
• 任务的分配与人员技能不匹配
• 新人太多，学习上手时间长
• 开发人员与管理层之间关系不佳，导致决策缓慢，影响全局
• 缺乏激励措施，士气低下，降低了生产能力
• 项目后期加入新的开发人员，需要进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低
• 由于项目组成员之间发生冲突、导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作
• 不适应工作的成员没有调离项目组，影响了项目组其他成员的积极性

三、流程

• 缺乏必要的标准规范，增加了工作失误与重复工作。（一般采用技能培训、代码Review、过程优化等进行对应）
• 文档工作多影响进度
• 进度跟踪不准确，导致无法预知项目是否已落后于计划进度
• 任务描述信息不清晰，导致沟通成本高
• 变更管理不能及时跟踪记录，导致未能及时进行开发和测试

四、计划编制风险

• 计划是“最佳状态”（但计划不现实，只能算是“期望状态”）
• 计划遗漏了必要的任务
• 工作量远大于估算
• 没有预留缓冲时间（学习、评审、分享等）
• 任务分配不合理，工作量不均衡
• 加班过多影响效率(其实加班过多还严重影响项目质量，如果测试比较细致和完整会导致返工时间过多，如果测试不细致，可能会导致很对缺陷流到客户)
• 先决条件的任务不能按时完成，影响后续任务（任务之间依赖）
• 目标日期提前，但没有相应地调整产品范围或可用资源
• 人员休假影响
• 节假日前后请假过多，效率降低
• 计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致
• 计划基于特定的小组成员，而特定的小组成员其实指望不上
• 产品规模（代码行数、功能点、与前一产品规模的百分比）比估计的要大

五、沟通

• 跨团队协调资源，沟通链路过多
• 缺乏激励措施，效率打折扣
• 项目成员间有冲突，导致信息沟通不到位
• 沟通方式、信息传递方式不明确、不统一
• 对其他外部依赖沟通不到位
• 与客户沟通不到位
• 与项目干系人沟通不到位

六、技术

• 复杂的技术调研选型时间长
• 开发环境不稳定导致联调延期
• 线上紧急问题修复影响当前开发进度
• 上线计划不完善
• 测试环境问题影响测试进度
• 研发提测质量低于预期影响测试进度
• 设计有逻辑漏洞导致返工
• 方案设计评审不够，设计存在漏洞和问题
• 对技术难点调研评估不足
• code review 未能提前发现代码问题
• 开发自测不充分
• 代码管理不到位
• 测试难度和复杂度未提前充分考虑
• 部署过程不熟悉导致时间过长

七、外部依赖

• 外部依赖接口没有按承诺交付
• 外部依赖产品不稳定，有问题
• 外部合作关系难以预期

八、组织和管理风险

• 仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长
• 低效的项目组结构降低生产效率
• 管理层审查、决策周期比预期的时间长
• 预算削减，打乱项目计划
• 管理层做出了打击项目组织积极性的决定
• 缺乏必要的规范，导致工作失误与重复工作
• 非技术的第三方的工作（预算批准、设备采购批准、法律方面的审查、安全保证等）时间比预期的延长

九、开发环境风险

• 设施未及时到位
• 设施虽然到位，但不配套，如没有电话、网线、办公用品等
• 设施拥挤、杂乱或者破损
• 开发工具未及时到位
• 开发工具不如期望的那样有效，开发人员需要时间创建工作环境或者切换新的工具
• 新的开发工具的学习期比预期的长，内容繁多

十、客户风险

• 客户对于最后交付的产品不满意，要求重新设计和重做
• 客户的意见未被采纳，造成产品最终无法满足用户要求，因而必须重做
• 客户对规划、原型和规格的审查、决策周期比预期的要长
• 客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更
• 客户答复的时间（如回答或澄清与需求相关问题的时间）比预期长
• 客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作

十一、产品风险

• 矫正质量低下的不可接受的产品，需要比预期更多的测试、设计和实现工作
• 开发额外的不需要的功能（镀金），延长了计划进度
• 严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作
• 要求与其他系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作
• 在不熟悉或者未经检验的软件和硬件环境中运行所产生的的未预料到的问题
• 开发一种全新的模块化将比预期花费更多的时间
• 依赖正在开发中的技术奖延长计划进度

十二、设计和实现风险

• 设计质量低下，导致重复设计
• 一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发新的功能
• 代码和库质量低下，导致需要进行额外的测试，修正错误或重新开发
• 过高估计了增量型工具对计划进度的节省量
• 分别开发的模块无法有效集成，需要重新设计或开发

十三、过程风险

• 大量的纸面工作导致进度比预期慢
• 前期的质量保证行为不真实，导致后期的重复工作
• 太不正规（缺乏对软件开发策略和标准的遵循），导致过多的耗时无用的工作
• 过于正规（教条地坚持软件开发策略和标准），导致过多的耗时于无用的工作
• 向管理层撰写进度报告占开发人员的时间比预期的多
• 风险管理粗心，导致未发现重大的项目风险

十四、其他

• 服务器没有及时到位
• 移动设备机型不全面
• 法律法规
• 技术大趋势
• 商业模式
• 市场竞争

总结

        整理内容比较粗糙，一般在实际应用中首先会进行分类，并对具体的风险制定应对措施，甚至影响比较严重的会有Plan A 和Plan B，主要目标是尽可能降低风险对项目消极的影响。