Y公司软件需求变更风险管理

周之顺

（上海理工大学，上海 200093）

1 项目介绍

风险管理是对风险进行识别、评价、规避的过程。风险管理可以在具体的项目过程中将优势最大化，同时减小劣势的影响。以Y公司为例，Y公司为国内行业领先的支付软件公司，风险管理在项目的管理非常重要，风险的管理往往决定了项目的成败，进而决定了企业的发展。有效的风险管理能够能够根据软件项目特点，在不同的阶段识别不同的风险因素，同时能够预测风险因素发生的概率，将项目风险提前预警并根据风险措施进行合理规避调整，增强软件项目的成功率，为企业创造价值。本文综合采用了情景分析法、层次分析法对Y公司软件需求变更风险管理的现状进行评价。

2 需求变更风险识别

2.1 需求变更简介

在软件行业，软件项目需求变更是无法避免的。有报道表明需求变更是软件项目成功幵发的主要挑战之一。[1]在软件需求分析、系统设计、编码、上线运营阶段都会出现软件需求变更，需求变更紧跟软件的生命周期，特别是在行业内流行的迭代式开发中，需求变更是不可避免。在Y公司内，软件需求变更同样不可避免，在所有的软件项目中均出现不同程度的需求变更情况，也有因为需求变更导致产品无法按时交付的事情。

2.2 需求变更风险识别

2.2.1 需求变更风险识别方法

采用情景分析法对引起软件需求变更的风险因素进行识别分析。将情景分析法和动态风险识别相结合为全面地识别风险因素提供了保障，为后面的风险估计与评价及风险控制打下了坚实的铺垫。

2.2.2 需求变更风险识别步骤

（1）需求变更管理因素。在Y公司，需求变更存在产品经理对需求把控不足，也存在需求边界不清晰，没有完整的需求基准。需求文档不规范或者过于简单导致理解歧义，同时由于需求变更，导致涉及相关方不能同步了解到最新的变化，也会引起需求变更。（2）需求变更研发设计因素。在需求完成宣讲后，研发会进入需求的分析、设计阶段，如果需求评审时没有识别出潜在的需求，或者对产品的需求沟通或者理解上存在偏差，或者系统设计出现疏忽或者错误，或者性能不满足业务发展导致变更。（3）需求变更合规因素。由于需求从提出到上线，需要一定的时间，但是这个期间合规可能会发生变化，特别是支付行业，安全和国家政策都会影响公司产品的发展，因此，合规也会导致需求的变更。

2.2.3 需求变更风险识别结果

通过上面的风险识别，较为全面的识别出该项目实施阶段的风险包括：需求变更管理、需求变更研发设计、需求变更合规共3大类风险。

3 需求变更风险评价

3.1 需求变更风险评价指标构建

3.1.1 风险评价指标的选取原则

（1）目标性。选取指标是为了更好的表现评估对象的风险情况，所有指标都是风险评价目标的体现，科学合理的风险指标应该能够客观描述风险构成要素及其本质特征结构。（2）实用性。项目产生影响较大、经济实惠、内容清晰简洁，并且与实际情况相吻合的指标。（3）科学性。选择既客观、合理又符合中国国情的指标，此外，选取的指标要含义清晰、概念正确，尽量出现突出的包含关系，弱化隐含的相关关系。（4）代表性。要抓住最能反映评估对象水平的重点因素，使风险评价指标具有代表性。（5）定性与定量指标相结合。风险评估与评价目前具有开放性和前沿性的特点，单一的定性分析不能为其提供坚实的支撑，唯有运用现代统计理论的基础，将定性分析和定量分析相结合，才能使评价结果更具有客观真实性。

3.1.2 风险评价指标的构建

按照目标性、实用性、科学性、代表性、定性和定量指标相结合的基本原则，结合风险识别的结果，构建出需求变更的风险评价指标体系如下：

图1 需求变更风险指标体系层次结构图

3.2 需求变更风险评价

3.2.1 需求变更风险评价步骤

（1）确定判断矩阵的比例标度。组织公司内专家对项目状况和风险识别结果进行讨论，然后依据风险程度进行进行打分。（2）构建判断矩阵。将专家给出的各风险因素之间的比较标度构建相应的判断矩阵。（3）计算最大特征值对应特征向量。（4）归一化处理求特征向量 W=（W1，W2…Wn）。（5）计算判断矩阵的最大矩阵值。（6）计算最大特征值。（7）一致性校验。（8）计算CI。（9）查表得出RI的值。（10）计算Cr的值，并进行一致性判断。

3.2.2 需求变更风险评价结果

需求变更风险评估与评价阶段，首先由风险评价专家根据项目具体情况确定风险因素的标度，本项目共有12位专家（记为ai=1，2…，12）参与风险评价，12位专家对风险因素标度的打分值记为aij，为了提升风险评价的准确性降低专家打分的主观性和自由裁量，本项目采用细化评分办法、细分专家类别的方式降低风险评价打分的主观性：

细化评分办法。将风险评价建立在对成本、进度和质量影响3个方面进行打分，并且细化每个部分的打分细则，压缩专家主观打分的空间，此外，在统计分数时去掉最高分和最低分，降低最高分和最低分对最终分值的影响；风险小组计算风险因素的最终标度（bij）。

3.2.3 需求变更风险评价结果分析

为了增加打分专家的科学合理性，经专家会议讨论得出：

在专家职务方面，产品总监10分，架构师、技术经理8分，项目经理5分，高级工程师2分：

构建判断矩阵并进行一致性检验

根据上个环节确定的风险因素的最终标度，构建风险判断矩阵，然后按照风险评价步骤进行风险评价，风险评价结果如表所示。

编号 专家 专家职务（10分）从业年限（10分）类似项目（10分） 专家比重 综合权重A，B 产品总监（10分）5-10年（9分）1 6个（8分） 27分 0.31 2 C，D 架构师（8分）5-10年（9分）4个（5分） 22分 0.25 3 E，F 技术经理（8分）5-10年（9分）3个（4分） 21分 0.24 4 G，H 项目经理（5分）3-5年（5分）1个（1分） 11分 0.12 5 M，N，P，Q高级工程师（2分）2-4年（4分）1个（1分） 7分 0.08

（1）判断矩阵A-B及风险评价结果

λmax=3.07，C.I.=0.035，R.I.=0.58，CR=0.0603＜0.1，通过一致性检验

（2）构建判断矩阵B1-C1及风险评价结果

λmax=3.05，C.I.=0.025，R.I.=0.58，CR=0.0431＜0.1， 通 过 一 致性检验

（3）构建判断矩阵B2-C2及风险评价结果

λmax=4.12，C.I.=0.12，R.I.=0.58，CR=0.0689＜0.1，通过一致性检验

（4）构建判断矩阵B3-C3及风险评价结果

λmax=3.02，C.I.=0.01，R.I.=0.58，CR=0.0172＜0.1，通过一致性检验

（5）计算风险因素综合权重

综合上述分析，Y公司软件需求变更，主要体现在原始需求及系统设计时对需求理解偏差上。

4 需求变更风险控制策略

4.1 控制需求变更

在项目管理过程中，制定一个明确的需求变更流程，并严格执行。同时加入需求变更准入机制，只有达到了一定的条件，才能走软件变更流程。如果提交需求变更请求与准入条件不符，则不考虑。这样规范软件变更流程，让产品经理尽可能的挖掘内在需求，减少源头变更。需求变更总是有风险且要付出代价的。只是认识到项目所面临的风险是远远不够的，还必须以某种方式对风险进行管理，以便在整个项目幵发过程中可以将风险问题和状态传达给项目的涉众。

4.2 减少设计缺陷

软件研发人员应该擅长寻找可能的风险，准确地分析风险。[3]在系统规划设计时，要考虑到需求的变更可能，做到模块化、可扩展，这样即使有需求变更不会影响整体的架构设计，局部调整即可，对整个项目的风险可控。做到系统设计进行评审，将设计缺陷风险降至最小，同时系统实现过程严格按照设计标准来实施。

4.3 预警合规风险

在项目立项时需要增加合规检查流程，只有通过了合规的检查才能立项，并且合规也需要尽量预测考虑到后续的信用、政策、法律合规风险。提供产品安全的发展环境，同时不能遏制产品的创新的活力。

5 结论与展望

结合上述研究，可以看到，软件需求变更因素很多，同时变更的阶段贯穿整个项目周期。对于Y公司而言，在重点关注产品需求和潜在需求变更的情况下，对系统设计及政策风险都需要及时关注。通过持续的需求变更因素分析，合理的风险规避，建立风险管理流程，达到项目风险控制的目标，为企业项目成功奠定坚实的基础。