MgtPro_5

发表于 | 分类于 | | 次阅读

MgtPro_5

1. risk identification

1.1 Diagramming

Equipment

  1. 设备未到位（缺失、不足
  2. 设备因不可坑因素损坏

Process

People

Materials

Environment

  1. 新的开发工具学习期比预期长
  2. 开发工具不如期望的那样有效，开发人员需要时间创建工作环境或者切换新的工具；

Management

Type Possible risk
Technology
People
Organizational
Tools
Requirements
Estimation

1.2 type-based

Technology

  1. 系统架构不合理
  2. 可复用组件不适用
  3. 数据库
    1. 对于并发性的支持
    2. 事件的四大特性（一致性、持久性、原子性、隔离性）
    3. 数据库数据丢失（
    4. 数据库数据安全（恶意攻击，恶意入侵数据库，备份数据的保护
  4. 服务器
    1. 设备失效，宕机
  5. 设计质量低下，导致重复设计；
  6. 一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发新的功能；
  7. 代码和库质量低下，导致需要进行额外的测试，修正错误，或重新制作；
  8. 过高估计了增强型工具对计划进度的节省量；
  9. 分别开发的模块无法有效集成，需要重新设计或制作。

People

  1. 人员的变更：人员辞职（底层程序员、管理层人员），关键人员因不可抗因素没办法工作，新的人员的加入
  2. 人员技术水平不够
  3. 人员培训效果不足
  4. 人员消极怠工
  5. 人员之间沟通不足引发冲突，导致工作因沟通不够出现错误或额外的重复工作

Organizational

  1. 分工不合理（工作难度分配不合理、工作种类分工不合理）
  2. 运转资金不足
  3. 仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长；
  4. 低效的项目组结构降低生产率；
  5. 管理层审查 决策的周期比预期的时间长；
  6. 预算削减，打乱项目计划；
  7. 缺乏必要的规范，导致工作失误与重复工作；
  8. 非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。

Tools

  1. 代码生成失误
  2. 工具不兼容
  3. 源码丢失

Requirements

  1. 需求已经成为项目基准，但需求还在继续变化；
  2. 需求定义欠佳，而进一步的定义会扩展项目范畴；
  3. 产品定义含混的部分比预期需要更多的时间；
  4. 在做需求中客户参与不够

Estimation

  1. 工作量工作时间工作进度预估错误
  2. 低估软件规模
  3. 低估缺陷修复率

1.3 Brainstorm

客户风险：

  1. 客户对于交付的产品不满意

scope risk：

  1. 产品跨领域

1.4 Document review

非功能需求

法律：

  1. 某些地区有特定的法律法规，系统需要根据所在地区进行调整

2. classification

RBS

2.1 External Unpredictable

  1. 设备风险
    1. Natural Hazards（设备因不可坑因素损坏
    2. 设备未到位
  2. 非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。

2.2 Externel Predictable

  1. market risk：
    1. 软件功能不符合市场需求，投入市场后反映惨淡
    2. 行业竞争
  2. 运营风险：
    1. 经营成本上升，宣传成本，人员成本上升
  3. 通货膨胀
  4. 汇率

2.3 Internal Non-technical

  1. Environment
    1. 新的开发工具学习期比预期长
    2. 开发工具不如期望的那样有效，开发人员需要时间创建工作环境或者切换新的工具；
  2. People
    1. 人员的变更：人员辞职（底层程序员、管理层人员），关键人员因不可抗因素没办法工作，新的人员的加入
    2. 人员技术水平不够
    3. 人员培训效果不足
    4. 人员消极怠工
    5. 人员之间沟通不足引发冲突，导致工作因沟通不够出现错误或额外的重复工作
  3. Organizational
    1. 分工不合理（工作难度分配不合理、工作种类分工不合理）
    2. 运转资金不足
    3. 仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长；
    4. 低效的项目组结构降低生产率；
    5. 管理层审查 决策的周期比预期的时间长；
    6. 预算削减，打乱项目计划；
    7. 缺乏必要的规范，导致工作失误与重复工作；
    8. 非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。
  4. Requirements
    1. 需求已经成为项目基准，但需求还在继续变化；
    2. 需求定义欠佳，而进一步的定义会扩展项目范畴；
    3. 产品定义含混的部分比预期需要更多的时间；
    4. 在做需求中客户参与不够
  5. Estimation
    1. 工作量工作时间工作进度预估错误
    2. 低估软件规模
    3. 低估缺陷修复率
  6. 客户风险
    1. 客户对于交付的产品不满意
  7. scope risk：
    1. 产品跨领域发展

2.4 Technical

  1. 数据库
    1. 对于并发性的支持
    2. 事件的四大特性（一致性、持久性、原子性、隔离性）
    3. 数据库数据丢失（
    4. 数据库数据安全（恶意攻击，恶意入侵数据库，备份数据的保护
  2. 服务器
    1. 设备失效，宕机
  3. design：
    1. 设计质量低下，导致重复设计；
    2. 一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发新的功能；
    3. 代码和库质量低下，导致需要进行额外的测试，修正错误，或重新制作；
    4. 过高估计了增强型工具对计划进度的节省量；
    5. 分别开发的模块无法有效集成，需要重新设计或制作。
  4. Tools：
    1. 代码生成失误
    2. 工具不兼容
    3. 源码丢失
  1. 某些地区有特定的法律法规，系统需要根据所在地区进行调整
  2. 专利问题，使用第三方库涉及的侵权问题
  3. 消费者权益受损，平台未及时处理而遭诉讼

3. risk analysis

分工：各自按照流程风险分析，register，应对措施= =自己看ppt吧

文添： 2.5+ppt

陈超： 2.1、2.2（+补充

陈润乾、罗媚、谈瑞： 2.3 3个人

梁程伟： 2.4（+补充

Pre 建议：

资源分配，依据什么将资源分配给WBS中的任务

介绍一下自己使用的风险管理工具

WBS从不同的方面进行分解？合理分解（对于WBS不同的划分

甘特图

注意所写的风险是否与软件开发是否有关

参考一些现有的技术文档

现有的技术模型

PPT流程：

  1. Risk Mgt Plan（略）
  2. Risk Identification
    1. 使用方法：brainstorm、diagramming、document review
    2. 展示RBS
  3. Risk Analysis
    1. 定性分析：probability-impact矩阵，impact分析表
    2. 定量分析：决策树、蒙特卡洛分析
  4. response
    1. 面对的态度：积极、消极
    2. strategy
  5. WBS（使用工具：甘特图、ones.ai

建议：

schedule中包含工作的分配和资源的分配

给这个分值的原因

WBS分解的依据

给咱来个🍰，啾咪