多年以前参加过一次架构师培训,老师给了一份风险检查表,每次读来,都觉得能警醒自己,而无数次项目成果或失败的经历,无不重复证明这些风险的警示意义。现在把这个表格放到自己的blog里面,以免自己忘记。如果当年的老师看见了,请别怪我传播了,相信您也希望优秀的东西能广为流传的。
商业风险 |
|
风险类型 |
检查项 |
政治 法律 市场 |
政府或者其它机构对本项目的开发有限制吗? |
有不可预测的市场动荡吗? |
|
有不利于我方的官司要打吗? |
|
本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗? |
|
竞争对手有不正当的竞争行为吗? |
|
本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗? |
|
是否在开发很少有人真正需要却自以为很好的产品? |
|
是否在开发可能亏本的产品? |
|
客户 |
客户的需求是否含糊不清? |
客户是否反反复复地改动需求? |
|
客户指定的需求和交付期限在客观上可行吗? |
|
客户对产品的健壮性、可靠性、性能等质量因素有非常过分的要求吗? |
|
客户的合作态度友善吗? |
|
与客户签的合同公正吗?双方互利吗? |
|
客户的信誉好吗?例如按客户的需求开发了产品,但是客户可能不购买。 |
|
子承包商 供应商 |
与子承包商、供应商签订的合同公正吗?双方互利吗? |
子承包商、供应商的信誉好吗? |
|
子承包商、供应商有可能倒闭吗? |
|
子承包商、供应商能及时交付质量合格的产品(或部件)吗? |
|
子承包商、供应商有能力做好售后服务吗? |
|
管理风险 |
|
风险类型 |
检查项 |
项目计划
|
对项目的规模、难度估计是否比较正确? |
人力资源(开发人员、管理人员)够用吗?合格吗? |
|
项目所需的软件、硬件能按时到位吗? |
|
项目的经费够用吗? |
|
进度安排是否过于紧张?有合理的缓冲时间吗? |
|
进度表中是否遗忘了一些重要的(必要的)任务? |
|
进度安排是否考虑了关键路径? |
|
是否可能出现某一项工作延误导致其它一连串的工作也被延误? |
|
任务分配是否合理?(即把任务分配给合适的项目成员,充分发挥其才能) |
|
是否为了节省钱,不采用(购买)成熟的软件模块,一切从零做起? |
|
… |
|
项目团队 |
项目成员团结吗?是否存在矛盾? |
是否绝大部分的项目成员对工作认真负责? |
|
绝大部分的项目成员有工作热情吗? |
|
团队之中有“害群之马”吗? |
|
技术开发队伍中有临时工吗? |
|
本项目开发过程中是否会有核心人员辞职、调动? |
|
是否能保证“人员流动基本不会影响工作的连续性”? |
|
项目经理是否忙于行政事务而无暇顾及项目的开发工作? |
|
上级领导 行政部门 合作部门 |
本项目是否得到上级领导的重视? 上级领导是否随时会抽调本项目的资源用于其它“高优先级”的项目? |
上级领导是否过多地介入本项目的事务并且瞎指挥? |
|
行政部门的办事效率是否比较底,以至于拖项目的后腿? |
|
行政部门是否经常干一些无益于生产力的事情,以至于骚扰本项目? |
|
机构是否能全面、公正地考核员工的工作业绩? |
|
机构是否有较好的奖励和惩罚措施? |
|
本项目的合作部门的态度积极吗?是否应付了事?或者做事与承诺的不一致? |
|
技术风险 |
|
风险类型 |
检查项 |
需求开发
需求管理 |
需求开发人员懂得如何获取用户需求吗?效率高吗? |
需求开发人员懂得项目所涉及的具体业务吗?能否理解用户的需求? |
|
需求文档能够正确地、完备地表达用户需求吗? |
|
需求开发人员能否与客户对有争议的需求达成共识? |
|
需求开发人员能否获得客户对需求文档的承诺?以保证客户不随便变更需求? |
|
综合技术 开发能力 包括设计 编程、测试等 |
开发人员是否有开发相似产品的经验? |
待开发的产品是否要与未曾证实的软硬件相连接? |
|
对开发人员而言,本项目的技术难度高吗? |
|
开发人员是否已经掌握了本项目的关键技术? |
|
如果某项技术尚未实践过,开发人员能否在预定时间内掌握? |
|
开发小组是否采用比较有效的分析、设计、编程、测试工具? |
|
分析与设计工作是否过于简单、草率,从而让程序员边做边改? |
|
开发小组采用统一的编程规范吗? |
|
开发人员对测试工作重视吗?能保证测试的客观性吗? |
|
项目有独立的测试人员吗?懂得如何进行高效率地测试吗? |
|
是否对所有重要的工作成果进行了同行评审(正式评审或快速检查)? |
|
开发人员懂得版本控制、变更控制吗?能够按照配置管理规范执行吗? |
|
开发人员重视质量吗?是否会在进度延误时降低质量要求? |