标签:组织 效率 调整 学习 开发环境 width 不清晰 评估 针对
一、 存在风险
此处罗列出了我们开发小组可能遇到8种的风险。
编号 |
风险名称 |
内容 |
发生概率 |
损失(人周) |
危险度(周) |
1 |
计划编制风险 |
对所要使用技术不熟悉,可能导致无法交付; 每个模块的实现一定程度上依赖于其他模块的完成,可能导致长延期交付。 |
50% |
3 |
1.5 |
2 |
组织与管理风险 |
计划制定与实际操作脱节; PM无法有效的调动成员积极性; PM任务分配不合理; |
20% |
3 |
1.5 |
3 |
开发环境风险 |
小组成员擅长的开发环境不同,统一成相同的开发环境,需要重新学习; |
15% |
1 |
0.5 |
4 |
最终用户风险 |
交付的产品与用户预期差距较大,无法满足目标人群的实际需求。 |
15% |
3 |
1.5 |
5 |
人员风险 |
小组成员交流不畅,或者产生矛盾; 某一重要环节成员遇到突发情况,无法完成所负责任务; 小组成员懈怠,交付的产品质量过差; |
5% |
1 |
0.5 |
6 |
需求风险 |
对目标人群的使用习惯和需求概括不清晰 |
10% |
2 |
1 |
7 |
产品风险 |
对不同移动端的兼容性差; 测试时间短,可能会出现未测试到的异常情况; 在不需要的功能上花费太多时间;
|
5% |
2 |
1 |
8 |
设计与实现风险 |
设计文档不清晰,实现起来困难; 技术难度超出预期; 开发的各个模块无法有效集成。 |
50% |
5 |
2.5 |
二、 风险优先级
对风险的优先级进行排序,集中精力解决最“危险”的风险,达到效率最大化。
编号 |
危险度 |
8 |
2.5 |
2 |
1.5 |
1 |
1.5 |
4 |
1.5 |
三、 风险的化解
在此,针对“刺头”们,我们小组提供了相应的控制方法。
编号 |
控制方法 |
8 |
重视设计文档的设计,统一建模语言; 对各模块实现难度进行评估,对实现难度较大的方法及性能更改; 模块以便于集成为前提进行划分; |
2 |
对各项任务进行评估,采用自主选择兼以PM分配的形式分配任务,尽量使任务符合各成员技能点; |
1 |
任务分配后,预留一周学习时间; 理清每个模块的相互依赖关系,设置中期验收时间和最迟交付时间; |
4 |
持续的进行用户调研; 以迭代的方式进行开发,每一轮产生的原型都交付用户使用,收取反馈意见,进行下一轮的调整; |
标签:组织 效率 调整 学习 开发环境 width 不清晰 评估 针对
原文地址:https://www.cnblogs.com/blackDuck/p/10747836.html