意图：确定选定问题或现象的原因，并采取行动防止不良现象或问题的重复发生或确保积极现象的重复发生。
价值： 解决根本原因直接提高质量和生产力。
2 适用范围本程序适用于所有研发管理活动中发生的问题或现象，并进行相应的原因分析，以及采取相应的措施防止不良现象或问题的重复发生或确保积极现象的重复发生。
3 定义直接原因：直接导致问题或现象的浅层次的原因，能直观判断。对直接原因要采取纠正措施。
根本原因：导致问题或现象的最深层次的原因，需要通过穷究的方法才能识别。，对根本原因要采取预防措施。
随机原因偏差(Chance Cause)：也称偶然原因偏差，指由于过程分量（人员、机器、原料、环境、方法－4M1E）之间正常的，或内在的交互作用造成的过程性能偏差。有以下特点：
1)形成一个较稳定的状态；
2)对质量波动的影响不大；
3)不易识别；
4)难以避免。
特殊原因偏差(Special Cause/Assignable Cause)：也称可归属原因偏差，指过程的一个或多个分量发生了突然或永久的异常改变导致的性能偏差。这些变化可能是过程的输入、环境、过程步骤执行的方式。有以下特点：
1)具有特别的条件
2)引起质量的较大变化
3)易于识别
4)易于消除
5)可预防
例如:缺乏培训人员、环境改变、方法改变、没有按过程执行等。
4 职责4.1 EPG组长1 负责组织公司级改进措施的推进；
2 负责指派人员实施措施与验证措施；
3 负责指定人员对缺陷预防库进行管理。
4.2 项目经理1 负责组织项目组内缺陷与问题数据的收集；
2 负责组织编制项目的原因分析报告；
3 负责缺陷与问题分析后改进措施的制定并指派人员进行措施实施、跟踪及验证。
4.3 QA1 参与项目组的阶段完成报告评审；
2 参与项目组的原因分析会；
3 跟踪缺陷与问题分析后改进措施的实施状况。
5 输入1 项目问题管理一览表、测试报告等；
2 QA action-list或报告、内审或外审报告、公司顾客满意度调查资料；
3 经过培训的原因分析人员；
4 其它发生的偏差的现象或问题。
6 工作程序6.1 流程图
流程图
6.2 原因分析与解决流程6.2.1 缺陷数据的收集项目经理或EPG以及其他人员在工作过程中，定期或不定期的或事件触发时对以下几类缺陷或问题进行收集：
1 项目测试时发现的缺陷或问题；
2 项目核查时发现的缺陷或问题；
3 项目管理方面存在的缺陷或问题；
4 用户反馈的项目问题；
5 其它缺陷或问题。
以上缺陷或问题数据可通过各种问题管理一览表、核查报告、测试报告、会议报告等途径收集。
以下是需要进行根因分析的常见事件：
根因分析
6.2.2 分析缺陷或问题的根本原因相关人员对收集的问题或缺陷或好事进行根因分析，分析原因的方法有多种：鱼骨图、5-whys 法、检查表、头脑风暴等等。
考虑观察单个结果以及将结果分组。负面结果可能受到以下因素的影响：
培训和技能不足
•沟通障碍
•不考虑任务的所有细节
•在手动过程中出错(例如，键盘输入)
•过程缺乏
•资源配置不足
•合同不完整、含糊或不明确需求
•对供应商变更的无效管理协议
积极的结果可能受到以下因素的影响:
•工作的新方法
•过程自动化
•系统或工具升级
•试点
•过程改进
•性能改进
如果可能的话，以多种方式查看结果，以确保调查了所有潜在的根本原因。在适当的地方，跨功能查找根本原因的模式。
6.2.3 措施制定相关人员根据根本原因分析结果，针对主要原因制定相应的纠正和预防措施。项目实施过程中的鱼骨分析记录于完成报告中，项目结束后进行的鱼骨分析记录于原因分析报告中。针对主要原因制定的纠正措施应记录于原因分析报告的措施计划中。
6.2.4 措施的实施与验证项目经理或EPG应指定人员进行措施的实施及跟踪与验证，跟踪人员应每周对措施实施的情况进行跟踪，并对措施实施的效果进行分析，分析的结果可包含措施实施后相应的问题是否减少，减少的幅度如何等内容。验证与分析结果记录于项目原因分析报告中。
6.2.5 记录和归档相关人员应记录原因分析及解决过程中的相关数据，项目组、EPG的缺陷分析报告、执行计划等应提交至组织的缺陷预防库中进行保存。
6.2.6 提交改进建议并推广当采取的措施被验证成功后，相关人员提交改进建议给EGP，EPG修改组织级体系流程或推广到其他项目组。
7 输出1 原因分析记录及跟踪报告。
【软件开发过程所有文档获取可以-关注-私信】
