diff --git a/doc/沟通管理与风险管理计划.md b/doc/沟通管理与风险管理计划.md new file mode 100644 index 0000000..31a75b1 --- /dev/null +++ b/doc/沟通管理与风险管理计划.md @@ -0,0 +1,305 @@ + + +# 1. 沟通管理计划 + +| 沟通内容 | 频度 | 沟通方式 | 产出物 | +| :----------------------: | :--: | :------------------------: | :--------------------------------------------------: | +| 选题 | 1 | 交互式(团队讨论) | 产品使命、口号、策略 | +| 产品定义设计 | 1 | 交互式(团队讨论) | 产品的定义(包括产品的名称、发布时间、目标客户等信息) | +| 人员分配情况 | 3 | 交互式(团队讨论) | 任务分配表 | +| 产品原型设计 | 1 | 交互式(团队讨论) | 眼镜原型图设计、配套APP原型 | +| 产品用户故事 | 1 | 交互式(团队讨论) | 产品核心功能文件 | +| 产品功能实现 | 5 | 交互式(功能实现小组讨论) | 功能算法 | +| 产品测试 | 4 | 交互式(团队讨论) | 产品测试结果 | +| 交流方法 | 1 | 交互式(团队讨论) | 传递信息的技术与方法 | +| 信息收集和文件归档的结构 | 1 | 交互式(团队讨论) | 金山文档项目文件 | + +# 2. 风险管理计划 +
风险名称 | +所属维度 | +风险说明 | +影响程度 | +对工作量的影响 | +对进度和成本的影响 | +优先权 | +跟踪频率 | +||||
资源 | +项目管理 | +外部因素 | +技术 | +进度 | +|||||||
+ | + | + | + | + | + | + | (根据严重性等级由低至高从1-5)中选择数值 | +(根据严重性等级由低至高从1-5)中选择数值 | +(根据严重性等级由低至高从1-5)中选择数值 | +(数值越小,优先权越高) | +(根据严重性等级由低至高从1-5)中选择数值 | +
需求变化风险 | ++ | + | + | √ | ++ | 需求已经成为项目基准,但需求还在继续变化,最终因无法满足需求而导致任务失败 | +5 | +5 | +5 | +1 | +5 | +
需求定义风险 | ++ | + | + | √ | ++ | 需求定义欠佳,而进一步的定义会扩展项目范畴,或导致软件性能下降 | +4 | +3 | +4 | +2 | +5 | +
产品定义含混风险 | ++ | + | + | √ | ++ | 产品定义含混的部分比预期需要更多的时间 | +3 | +4 | +4 | +3 | +4 | +
计划风险 | ++ | √ | ++ | + | + | 计划是优化的,是"最佳状态",但计划不现实,只能算是"期望状态",可能导致任务失败 | +5 | +5 | +5 | +1 | +5 | +
计划设计风险 | ++ | √ | ++ | + | + | 涉足不熟悉的产品领域,花费在设计和实现上的时间比预期的要多 | +3 | +4 | +4 | +3 | +3 | +
组织管理风险 | ++ | √ | ++ | + | + | 低效的项目组结构降低生产率,或者缺乏必要的规范,导致工作失误与重复工作。 | +4 | +4 | +5 | +4 | +3 | +
人员关系风险 | +√ | ++ | + | + | + | 开发人员之间关系不佳,导致决策缓慢,导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作,影响全局 | +4 | +3 | +4 | +5 | +4 | +
人员技术风险 | +√ | ++ | + | + | + | 某些人员需要更多的时间适应还不熟悉的软件工具和环境 | +3 | +3 | +3 | +6 | +3 | +
开发工具风险 | +√ | ++ | + | + | + | 开发工具不如期望的那样有效,开发人员需要时间创建工作环境或者切换新的工具 | +3 | +4 | +4 | +4 | +3 | +
第三方工作风险 | ++ | + | √ | ++ | + | 非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长 | +2 | +1 | +3 | +5 | +3 | +
客户需求风险 | ++ | + | √ | ++ | + | 客户没有或不能参与规划、原型和规格阶段的审核,导致需求不稳定和产品生产周期的变更 | +4 | +4 | +4 | +3 | +5 | +
客户依赖风险 | ++ | + | √ | ++ | + | 客户对于最后交付的产品不满意,要求重新设计和重做 | +5 | +5 | +5 | +1 | +5 | +
产品功能风险 | ++ | + | + | √ | ++ | 开发额外的不需要的功能(镀金),延长了计划进度 | +2 | +4 | +4 | +4 | +4 | +
产品兼容风险 | ++ | + | + | √ | ++ | 严格要求与现有系统兼容,需要进行比预期更多的测试、设计和实现工作 | +3 | +4 | +4 | +4 | +3 | +
产品设计风险 | ++ | + | + | √ | ++ | 一些必要的功能无法使用现有的代码和库实现,开发人员必须使用新的库或者自行开发新的功能 | +3 | +4 | +4 | +4 | +4 | +
代码集成风险 | ++ | + | + | √ | ++ | 分别开发的模块无法有效集成,需要重新设计或制作 | +4 | +5 | +4 | +3 | +4 | +
过程正规程度风险 | ++ | + | + | + | √ | +太不正规(缺乏对软件开发策略和标准的遵循),导致沟通不足,质量欠佳,甚至需重新开发 | +5 | +5 | +5 | +1 | +5 | +
过程沟通风险 | ++ | + | + | + | √ | +大量的纸面工作导致进程比预期的慢 | +3 | +2 | +4 | +6 | +3 | +