组织风险库_企业管理_经管营销_专业资料.xls

组组织织风风险险库库风风险险分分类类说说明明风风险险库库中风风险险类类型型包括：需求风险需求已经成为项目基准，但需求还在继续变化；需求定义欠佳，而进一步的定义会扩展项目范畴；添加额外的需求；产品定义含混的部分比预期需要更多的时间；在做需求中客户参与不够；缺少有效的需求变化管理过程。设计和实现风险设计质量低下，导致重复设计；一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发新的功能；代码和库质量低下，导致需要进行额外的测试，修正错误，或重新制作；过高估计了增强型工具对计划进度的节省量；分别开发的模块无法有效集成，需要重新设计或制作。开发环境风险设施未及时到位；设施虽到位，但不配套，如没有电话、网线、办公用品等；设施拥挤、杂乱或者破损；开发工具未及时到位；开发工具不如期望的那样有效，开发人员需要时间创建工作环境或者切换新的工具；新的开发工具的学习期比预期的长，内容繁多。产品风险矫正质量低下的不可接受的产品，需要比预期更多的测试、设计和实现工作；开发额外的不需要的功能(镀金)，延长了计划进度；严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作；要求与其他系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题；开发一种全新的模块将比预期花费更长的时间；依赖正在开发中的技术将延长计划进度。人员风险作为先决条件的任务(如培训及其他项目)不能按时完成；开发人员和管理层之间关系不佳，导致决策缓慢，影响全局；缺乏激励措施，士气低下，降低了生产能力；某些人员需要更多的时间适应还不熟悉的软件工具和环境；项目后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低；由于项目组成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作；不适应工作的成员没有调离项目组，影响了项目组其他成员的积极性；没有找到项目急需的具有特定技能的人。客户风险客户对于最后交付的产品不满意，要求重新设计和重做；客户的意见未被采纳，造成产品最终无法满足用户要求，因而必须重做；客户对规划、原型和规格的审核 决策周期比预期的要长；客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更；客户答复的时间(如回答或澄清与需求相关问题的时间)比预期长；客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作。过程风险大量的纸面工作导致进程比预期的慢；前期的质量保证行为不真实，导致后期的重复工作；太不正规(缺乏对软件开发策略和标准的遵循)，导致沟通不足，质量欠佳，甚至需重新开发；过于正规(教条地坚持软件开发策略和标准)，导致过多耗时于无用的工作；向管理层撰写进程报告占用开发人员的时间比预期的多；风险管理粗心，导致未能发现重大的项目风险。计划外任务风险超出项目计划外的突发任务；非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。组织和管理风险组织之间的协调工作未做好；仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长；低效的项目组结构降低生产率；管理层审查决策的周期比预期的时间长；预算削减，打乱项目计划；管理层作出了打击项目组织积极性的决定；缺乏必要的规范，导致工作失误与重复工作；一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发新的功能；代码和库质量低下，导致需要进行额外的测试，修正错误，或重新制作；开发工具不如期望的那样有效，开发人员需要时间创建工作环境或者切换新的工具；矫正质量低下的不可接受的产品，需要比预期更多的测试、设计和实现工作；严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作；要求与其他系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题；项目后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低；由于项目组成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作；不适应工作的成员没有调离项目组，影响了项目组其他成员的积极性；客户的意见未被采纳，造成产品最终无法满足用户要求，因而必须重做；客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更；客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作。太不正规(缺乏对软件开发策略和标准的遵循)，导致沟通不足，质量欠佳，甚至需重新开发；过于正规(教条地坚持软件开发策略和标准)，导致过多耗时于无用的工作；非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长；风风险险识识别别指指南南 识别风险是试图系统化地确定对项目计划（估算、进度、资源分配）的威胁。通过识别已知和可预测的风险，项目管理者就有可能避免这些风险，且当必要时控制这些风险。每一类风险可以分为两种不同的类型：一般性风险和特定产品的风险。一般性风险对每一个软件项目而言都是一个潜在地威胁。特定产品的风险只有那些对当前项目的技术、人员、及环境非常了解的人才能识别出来。为了识别特定产品的风险，必须检查项目计划及软件范围说明，从而了解本项目中有什么特殊的特性可能会威胁到项目计划。一般性风险和特定产品的风险都应该被系统化地标识出来。识别风险的一个方法是建立风险条目检查表。该检查表可以用来识别风险，并可以集中来识别下列常见子类型中已知的及可预测的风险：1)产品规模 与要建造或要修改的软件的总体规模相关的风险。2)商业影响 与管理或市场所加诸的约束相关的风险。3)客户特性 与客户的素质以及开发者和客户定期通信的能力相关的风险。4)过程定义 与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险。5)开发环境 与用以建造产品的工具的可用性及质量相关的风险。6)建造的技术 与待开发软件的复杂性以及系统所包含技术的“新奇性”相关的风险。7)人员数目及经验 与参与工作的软件工程师的总体技术水平及项目经验相关的风险。风险条目检查表能够以不同的方式来组织。与上述话题相关的问题可以由每一个软件项目来回答。这些问题的答案使得计划者能够估算风险产生的影响。下面给出一个项目做风险识别的例子：一一般般性性风风险险识识别别编编号号 产产品品规规模模风风险险具具体体风风险险描描述述现现状状分分析析值值A01没有以LOC或FP估算产品的规模，导致估算的结果缺乏客观依据；是1A02对于估算出的产品规模的不可信或可信度极底，导致规模估算的结果的偏大或者偏小；是1A03没有以程序、文件或事务处理的数目来估算产品规模，导致规模估算的结果缺乏客观依据；是1A04估算产品规模与以前产品的规模的平均值存在较大偏差，导致估算结果可信度低；不关心0A05产品创建或使用的数据库过大，导致估计的项目规模偏小；不关心0A06产品的用户数过多，远远超过预期数，导致估计的规模过小；不关心0A07产品的需求改变太多，导致估计的规模不准确；不关心0A08没有考虑可重用构件的设计开发，导致估计的规模偏大；不关心03编编号号 商商业业影影响响风风险险现现状状分分析析值值B01开发一个没有人真正需要的优秀产品或系统（市场风险）；是1B02开发的产品不再符合公司的整体商业策略（策略风险）；不关心0B03 建造了一个销售部门不知道如何去卖的产品；不关心0B04由于重点的转移或人员的变动而失去了高级管理层的支持（管理风险）；不关心0B05 没有得到预算或人力上的保证（预算风险）。不关心0B06 交付期限不合理，导致不合理的开发计划；不关心0B07 政府对本产品开发的约束；不关心0B08 延迟交付所造成的成本消耗是多少；不关心0B09本产品对公司的收入影响甚小；导致市场推广缺乏动力；不关心0B10本项目是否有市场部门、产品规划部门的人员的参与；不关心0B11项目是否受到了市场部门、产品规划部门的关注；不关心0B15合作方的供货期、技术支持力度等方面存在不足B161编编号号 客客户户相相关关风风险险现现状状分分析析值值C01没有和该客户合作的经历，导致在需求定义过程中与客户交流时不顺畅；是1C02客户不是很清楚需要什么、客户没有时间把需求写出来，导致无法得到客户明确的需求意图；不关心0C03客户不同意花时间召开正式的需求收集会议，以确定项目范围，导致项目范围不符合客户实际的想法；不关心0C04客户不愿意建立与开发者之间的快速通信渠道，导致在开发过程存在的需求相关的问题无法及时得到客户的帮助；不关心0C05客户不愿意参加复审工作，导致在项目早期不能发现和客户的不一致；不关心0C06客户不具有该产品领域的技术素养，导致提供的需求不准缺；不关心0C07客户不愿意让项目组的人来做他们的工作，导致项目组无法真实的体验用户的需求，对客户需求的理解不深刻；不关心0C08客户不了解软件过程，导致对项目提出不现实的期望；不关心01编编号号 过过程程风风险险现现状状分分析析值值管理过程风险D01高级管理层没有一份已经写好的政策陈述（该陈述中强调了软件开发标准过程的重要性），导致项目组对软件开发标准过程的重要性认识不够；是1D02开发组织没有拟定一份已经成文的、用于本项目开发的软件过程的说明，导致项目组对软件过程定义不清楚，导致软件过程混乱；不关心0D03开发人员不同意按照文档所写的开发过程进行开发工作，并自愿使用它，导致开发过程混乱；不关心0D04 开发过程不可以用于其它项目，导致？；不关心0D05管理者和开发人员没有接受过一系列的软件工程培训，导致项目开发过程无法得到良好理解和执行；不关心0D06没有为每一个软件开发者和管理者提供及时可查询到的工程标准，导致无法及时查阅标准；不关心0D07没有为作为软件过程一部分而定义的所有交付物建立文档概要及示例，导致开发人员无法有效和便利的使用；不关心0D08没有定期对需求分析报告、设计和编码进行正式的技术复审，导致所存在的问题没有及时发现，将问题带入到下一个阶段；不关心0D09 没有定期对测试过程和测试情况进行复审，导致；不关心0D10是否对每一次正式技术复审的结果建立了文档，其中包括发现的错误及使用的资源；不关心0D11 有什么机制来保证按照软件工程标准来指导工作；不关心0D12是否使用配置管理来维护系统/软件需求、设计、编码、测试用例之间的一致性；不关心0D13是否使用一个机制来控制用户需求的变化及其对软件的影响；不关心0D14对于每一个承包出去的子合同，是否有一份文档化的工作说明、一份软件需求规约和一份软件开发计划；不关心0D15是否有一个可遵循的规程，来跟踪及复审子合同承包商的工作；不关心01技术过程风险D50是否使用方便易用的规格说明技术来辅助客户与开发者之间的通信；是1D51 是否使用特定的方法进行软件分析；不关心0D52 是否使用特定的方法进行数据和体系结构的设计；不关心0D53是否90以上的代码都是使用高级语言编写的；不关心0D54 是否定义及使用特定的规则进行代码编写；不关心0D55 是否使用特定的方法进行测试用例的设计；不关心0D56是否使用配置管理软件工具控制和跟踪软件过程中的变化活动；不关心0D57 是否使用工具来创造软件原型；不关心0D58 是否使用软件工具来支持测试过程；不关心0D59 是否使用软件工具来支持文档的生成和管理；不关心0D60 是否收集所有软件项目的质量度量值；不关心0D61 是否收集所有软件项目的生产率度量值；不关心01编编号号 技技术术风风险险现现状状分分析析值值E01该技术对于项目组而言是新的；是1E02客户的需求是否需要创建新的算法或输入、输出技术；不关心0E03待开发的软件是否需要使用新的或未经证实的硬件接口；不关心0E04待开发的软件是否需要与开发商提供的未经证实的软件产品接口；不关心0E05待开发的软件是否需要与功能和性能均未在本领域得到证实的数据库系统接口；不关心0E06 产品的需求是否要求采用特定的用户界面；不关心0E07产品的需求中是否要求开发某些程序构件，这些构件与你的公司以前开发的构件完全不同；不关心0E08 需求中是否要求采用新的分析、设计、测试方法；不关心0E09 需求中是否要求使用非传统的软件开发方法；不关心0E10 需求中是否有过分的对产品的性能约束；不关心0E11 客户能确定所要求的功能是可行的吗？不关心01编编号号 开开发发环环境境风风险险现现状状分分析析值值F01没有可用的项目管理工具，导致项目管理工作效率低下；是1F02 是否有可用的软件过程管理工具；不关心0F03没有可用的分析及设计工具，导致分析和设计工作效率低下；不关心0F04分析和设计工具不适用于待建造产品，导致分析和设计工作无法进行；不关心0F05 是否有可用的编译器或代码生成器；不关心0F06 是否有可用的测试工具；不关心0F07 是否有可用的软件配置管理工具；不关心0F08 环境是否利用了数据库或数据仓库；不关心0F09 项目组的成员是否接受过每个所使用工具的培训；不关心0F10是否有专家能够回答有关工具的问题;不关心0F11工具的联机帮助及文档是否适当；不关心0F12 是否有可用的操作系统；不关心0F13 是否有可用的商用协议栈；不关心01编编号号 人人员员数数目目及及经经验验相相关关的的风风险险现现状状分分析析值值G01 是否有合适的人员可用；是1G02 人员在技术上是否配套；不关心0G03 是否有足够的人员可用；不关心0G04 开发人员是否能够自始至终地参加整个项目的工作；不关心0G05 项目中是否有一些人员只能部分时间工作；不关心0G06 开发人员对自己的工作是否有正确的期望；不关心0G07开发人员是否接受过必要的培训；不关心0G08 开发人员的流动是否仍能保证工作的连续性；不关心01项项目目特特定定风风险险识识别别编编号号 项项目目特特定定风风险险现现状状分分析析值值H01不关心0H02不关心0H03不关心0H04不关心0H05不关心0H06不关心0H07不关心0H08不关心0H09不关心0H10不关心00识别结果汇总累计风险个数识识别别结结果果产品规模风险3项目规模充满风险，赶快调整规模！商业影响风险1客户相关风险1过程风险1技术风险1开发环境风险1人员数目及经验相关的风险1项目特定风险0 识别风险是试图系统化地确定对项目计划（估算、进度、资源分配）的威胁。通过识别已知和可预测的风险，项目管理者就有可能避免这些风险，且当必要时控制这些风险。每一类风险可以分为两种不同的类型：一般性风险和特定产品的风险。一般性风险对每一个软件项目而言都是一个潜在地威胁。特定产品的风险只有那些对当前项目的技术、人员、及环境非常了解的人才能识别出来。为了识别特定产品的风险，必须检查项目计划及软件范围说明，从而了解本项目中有什么特殊的特性可能会威胁到项目计划。一般性风险和特定产品的风险都应该被系统化地标识出来。识别风险的一个方法是建立风险条目检查表。该检查表可以用来识别风险，并可以集中来识别下列常见子类型中已知的及可预测的风险：1)产品规模 与要建造或要修改的软件的总体规模相关的风险。2)商业影响 与管理或市场所加诸的约束相关的风险。3)客户特性 与客户的素质以及开发者和客户定期通信的能力相关的风险。4)过程定义 与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险。5)开发环境 与用以建造产品的工具的可用性及质量相关的风险。6)建造的技术 与待开发软件的复杂性以及系统所包含技术的“新奇性”相关的风险。7)人员数目及经验 与参与工作的软件工程师的总体技术水平及项目经验相关的风险。风险条目检查表能够以不同的方式来组织。与上述话题相关的问题可以由每一个软件项目来回答。这些问题的答案使得计划者能够估算风险产生的影响。下面给出一个项目做风险识别的例子：识识别别结结果果考虑考虑这些风险！不容忽视识识别别结结果果考虑考虑这些风险！不容忽视识识别别结结果果3,34%1,11%1,11%1,11%1,11%1,11%1,11%0,0%累计风险个数产品规模风险商业影响风险客户相关风险过程风险技术风险开发环境风险人员数目及经验相关的风险项目特定风险过程方面还是存在一点点问题，再看看哦！识识别别结结果果客户方面还是存在一点点问题，再看看哦！识识别别结结果果开发环境还是存在一点点问题，再看看哦！识识别别结结果果人员方面还是存在一点点问题，再看看哦！识识别别结结果果恭喜你！没有任何特定风险！风风险险分分析析指指南南风险分析活动风险分析步骤(1)评价风险可能性和影响风险发生的可能性使用极高、高、中、低、极低五级进行评估，可以参考以下概率估计表估算风险发生的可能性。其中最后一列为得分为计算风险值时使用。分级发生概率（X）极高X 90%高90%X 70%中70%X 40%低40%X 20%极低20%X 风险的影响可以从成本、进度、用户满意度几个方面来考虑，在有度量数据支持决策的情况下，可以用量化的费用和时间等指标来描述。在通常情况下，可以使用极高、高、中、低、极低五级进行综合评估。用于评价的评价表如下。最后一列得分仍然用于计算风险值使用。分级用于评价的特征极高以现有开发资源估计，完全无法预计产品交付时间高以现有开发资源估计，进度超期可能大于开发周期的50，且用户的部分核心需求可能无法实现中以现有开发资源估计，进度超期可能大于开发周期的50，但可以通过增加资源来缩短超期时间，且用户的核心需求均可以实现低以现有开发资源估计，进度超期大约在50到20之间，可以通过增加资源来减少部分超期时间，且用户的核心需求均可以实现极低以现有开发资源估计，进度超期小于开发周期的20，可以通过增加资源来缩短超期时间，且用户的核心需求均可以实现(2)计算风险值和分类风险风险值是上述风险可能性和风险影响的乘积：风险值风险可能性X风险影响 对每一个风险都要计算风险值。风险分类可以按照前面风险识别的分类进行，这样容易看出在开发过程中的哪个开发区域存在高风险的情况，为制定风险缓解计划提供了有效的指导。(3)确定风险优先级 由于每个项目的资源都是有限的，所以风险管理(处理、减缓、监视和控制)必须把精力集中在最重要的风险子集上。风险优先级分为两级：需管理的、仅跟踪的。使用以下方法确定需管理的风险项。Top 10 Risks选择 直接对风险值排序，选择风险值最高的前10位。评价Top 10 Risks是否覆盖了大多数的风险情况 计算Top 10 Risks的风险值之和占全部风险的风险值之和的比例，如果超过50，可以将这些风险可作为初始阶段的风险处理和缓解计划的输入；否则，应考虑在初始阶段的风险处理和缓解计划中覆盖更多的风险项，直到初始阶段的风险处理和缓解计划中可以涵盖超过50风险值的风险为止。在项目风险列表中，将纳入到风险处理计划的风险项的“优先级”中标记为M，表示此风险项为需要管理的风险。其他风险项不做标记，表明为仅跟踪的。得分54321得分54321风险发生的可能性使用极高、高、中、低、极低五级进行评估，可以参考以下概率估计表估算风险发生的可能性。其中最后一列为得分为计算风险值时使用。风险的影响可以从成本、进度、用户满意度几个方面来考虑，在有度量数据支持决策的情况下，可以用量化的费用和时间等指标来描述。在通常情况下，可以使用极高、高、中、低、极低五级进行综合评估。用于评价的评价表如下。最后一列得分仍然用于计算风险值使用。风险值是上述风险可能性和风险影响的乘积：风险值风险可能性X风险影响 对每一个风险都要计算风险值。风险分类可以按照前面风险识别的分类进行，这样容易看出在开发过程中的哪个开发区域存在高风险的情况，为制定风险缓解计划提供了有效的指导。由于每个项目的资源都是有限的，所以风险管理(处理、减缓、监视和控制)必须把精力集中在最重要的风险子集上。风险优先级分为两级：需管理的、仅跟踪的。使用以下方法确定需管理的风险项。Top 10 Risks选择 直接对风险值排序，选择风险值最高的前10位。评价Top 10 Risks是否覆盖了大多数的风险情况 计算Top 10 Risks的风险值之和占全部风险的风险值之和的比例，如果超过50，可以将这些风险可作为初始阶段的风险处理和缓解计划的输入；否则，应考虑在初始阶段的风险处理和缓解计划中覆盖更多的风险项，直到初始阶段的风险处理和缓解计划中可以涵盖超过50风险值的风险为止。在项目风险列表中，将纳入到风险处理计划的风险项的“优先级”中标记为M，表示此风险项为需要管理的风险。其他风险项不做标记，表明为仅跟踪的。风风险险处处理理和和减减缓缓指指南南 风险处理和缓解方法通常是通过协商制定出合适的行动计划，下表中为一些常见的风险处理方法。系统参与者参考以下列表进行协商，决定合适的风险处理和缓解方法，并在项目风险列表中作出准确的记录，用以统一开发过程中风险管理的行动。风险处理方法(1)避免风险(2)转移风险(3)接受风险(4)减缓风险具体步骤 避免风险是在项目早期的计划阶段经常使用的一种有效手段。风险有可能通过下列行动被消除：缩小项目目标或功能的范围，或者采用一种进化的开发方法以利用其临时解决该风险问题所具备的初步能力。避免风险就是把风险置于项目范围之外。如果项目需要这么做，要详细地报告给高层，并且得到批准，如果有必要，通知客户，达成一致。与避免风险一样，风险转移也是项目开始阶段所用的一种有效途径。举例说明：把一个具有高风险的功能转移到一个能够成功实现它的相关项目或系统中。如果项目需要这么做，要详细地报告给高层，并且得到批准，如果有必要，通知客户，达成一致。有时由于政策、市场、或客户的需求，必须接受风险的事实以处理风险。对该风险以及它对项目的影响必须进行持续地监视和报告。这种情况下，管理层要接受所涉及的风险，并且承认结果发生的可能性。这时，风险事实会给项目计划或预算带来影响，所以需要估计出这一部分的成本和工作量，把它作为管理储备估计的一部分，以留有足够的资金，在风险发生时可以使用这一部分储备。风险减缓是指建立一种行动计划以阻止风险的发生、或者是当风险发生时减少它对项目的影响。风险减缓为创造性的利用项目管理技能提供了机会。所采取的行动可能会是一些简单的任务，也可能会是涉及很大范围的活动。风风险险处处理理和和减减缓缓指指南南 风险处理和缓解方法通常是通过协商制定出合适的行动计划，下表中为一些常见的风险处理方法。系统参与者参考以下列表进行协商，决定合适的风险处理和缓解方法，并在项目风险列表中作出准确的记录，用以统一开发过程中风险管理的行动。风风险险跟跟踪踪指指南南 在项目跟踪过程中，风险需要被定期跟踪，对已识别的风险进行处理。并识别新的风险及对应的减缓活动。具体步骤1.项目经理应根据风险处理和缓解计划，采取适当的处理方式来避免、转移或减缓风险。必要时采取新的预防或纠正措施来改善风险缓解计划执行的不理想情况。2.项目经理应根据项目进展的实际情况，及时识别可能的新的风险及对应的减缓活动。3.项目经理定期（每周工作结束或每阶段工作结束）跟踪风险状态、处理的结果和效果，维护项目风险列表中各风险项的情况。风风险险跟跟踪踪指指南南 在项目跟踪过程中，风险需要被定期跟踪，对已识别的风险进行处理。并识别新的风险及对应的减缓活动。具体步骤1.项目经理应根据风险处理和缓解计划，采取适当的处理方式来避免、转移或减缓风险。必要时采取新的预防或纠正措施来改善风险缓解计划执行的不理想情况。2.项目经理应根据项目进展的实际情况，及时识别可能的新的风险及对应的减缓活动。3.项目经理定期（每周工作结束或每阶段工作结束）跟踪风险状态、处理的结果和效果，维护项目风险列表中各风险项的情况。管理和过程风险人员风险解决办法1项目组成员新人较多，开发经验欠缺或者对项目所需技术背景欠缺自主学习定期讨论、建设知识共享，交流平台2项目组成员个人素质不能达到要求定期检查和核实小组成员工作情况，督促小组成员自主学习，并通过相互交流学习和提供技术讲座等方式共同提高。3核心人员的流动以及项目组人员变动加强沟通，采取一些激励士气的有效措施，做好人才储备，同时定期组内讨论工作，让大家对彼此的工作熟悉，在发生人员调动时，及时调配人手填补空白4项目组人力不足激励士气、提高工作效率，尽快招人，做好人才储备5开发人员士气和工作状态不佳增加一些集体活动，如定时聚餐，外出活动等活跃气氛，提高工作效率客户风险解决办法1产品交付客户不顺利，项目无法正式结项确定与客户沟通的策略，加强与客户及开发组的沟通，及时反馈问题，沟通问题的解决方案，避免因准备工作不充分影响合同验收进程2客户单方面改变主意，放弃合作加强与客户的沟通，及时将沟通情况上报高层；3合体未签订，客户存在变数加强这些客户的重点跟进工作，及时反馈其客户意见、试用中发生的问题给开发人员，及时给出处理，加强客户关系的管理4项目的结束时间、客户验收方式、系统最早提交方式等都未知尽快签订合同，明确各方面的合作内容和日期等5客户反馈不能及时得到处理加强市场部和开发部之间的沟通，简化中间程序，随时将沟通结果通报给相关人，必要时上报高层过程风险解决办法1项目经理的工程经验较少，对软件工程和公司过程规范了解较少加强项目经理的过程规范性相关知识培训，QA需要辅助项目经理执行相关过程的规程，提高过程规范性2计划外任务风险解决办法1非项目任务书内的任务，或者其它非项目范围任务的影响（如出差、技术支持，临时性任务安排等）在项目策划阶段应该为这些突发事件预留一定的管理工作量储备，加强计划，明确和相关组的接口关系，尽量排除其它事情对项目范围内工作的影响组织和管理风险解决办法1相关组之间的组间协调，对工作效率有影响明确各人职责范围，明晰工作接口关系；明确工作目标，协调各种计划，保证计划的有效实施；高层的有效协调和支持2项目组成员对任务的理解存在偏差，使得任务不能完成或质量难以保证。及时开周例会，了解任务执行情况，及时纠正偏差。其他风险解决办法1几乎无国内国际交流，相关资料和技术缺乏，项目组需要长时间调研和学习希望多一些外部的交流和培训，项目所需技术在国内尚属空白，技术交流有助于避免方向误差技术类风险需求相关风险解决办法1需求不确定，导致开发组需求实现不到位或存在确认陷阱尽早确定需求，落实需求相关文档，加强沟通，同时让开发成员,测试成员对需求理解达成一致2需求变更频繁严格执行需求管理过程，用户的需求变更需经过质控部、开发部、测试部的评审，通用的原则是对于提高产品质量的需求可以考虑修改，对于用户定制的需求尽量不采用。3需求较复杂，实现难度大，导致开发工作周期比计划的长尽可能早的确定需求和解决方案，尽量细化需求，做好需求分析和设计工作设计和实现风险解决办法1部分模块的修改引起系统的改动安排得力资源，加强分析设计和数据库设计环节的评审2技术实现可能有难点，存在一定的不确定性及时了解是否存在技术不熟悉阻碍了项目进展，发现时及时安排人员学习，加深、加宽技术调研范围3系统需要做数据移植或者代码重构等工作加强这些工作任务的评审，适当权衡数据移植或者代码重构的代价与价值4开发人员对于客户的反馈实现不到位或单方面变更需求市场部对于开发部交付给客户的版本，必须首先自行验证，验证无误后交付给客户，如存在问题，及时与开发部负责人沟通5部分模块需要长期工作才能见成效，短期内难以实现确定工作重点及主要模块，获取明确急需的需求；分阶段/版本实现开发环境风险解决办法1移植过程中，由于系统之间的差别，导致基础框架不支持某些功能参与社区交流和讨论，确定是否有必要对移植系统的某些框架等进行修改完善2项目采用的软件或者硬件自身的本身稳定性和可开发性存在问题加强技术调研，对可能出现的问题可联系厂商进行技术交流和解决产品风险解决办法1上一版本中，存在没有测试出来的隐藏的缺陷对在开发期间发现出来的问题，需要认真评审，看是否有修改的必要，同时修改这些问题要慎重2产品的质量要求比较高，对编码的质量控制要求高加强测试和编码质量管理3产品质量和市场竞争问题从市场角度，提出完善产品的合理化建议；代表客户参与产品升级开发策略的制订，需求实现优先级的评审等过程；促使推出能够尽量满足市场需求的产品测试相关风险解决办法1用例规约的维护和更新没有落实到位开发人员负责全程跟踪用例规约,并保证开发的界面与用例规约统一2某些功能的具体操作规则未明确.给前期编写测试用例带来困难开发人员提供原型系统辅助编写测试用例3系统集成集成时容易出现冲突的情况建议及早的进行分支合并，尽早发现问题4开发部不能如期交付目标产品,以及目标产品的质量不高合理分工,提高效率,加强组内测试5覆盖两个版本的同时测试,造成带来管理上的混乱从过程的角度,需要严格按照规程进行管理,QA加大对开发组开发过程,测试组测试过程的过程审计,包括对基线的审计