论文部分内容阅读
[摘 要]软件项目质量管理是一项管理工作，又是一项软件类的技术工作。软件项目质量管理不仅涉及人的管理体系，还涉及软件产品这个独特对象的流程管理以及在特定组织关系下的组织特点和要求。完善的软件项目质量管理可以提高公司效益和产品质量，具有重大的意义。文章参考国内外工程质量管理的相关文献，借助相关文献的研究成果应用到软件工程质量管理方面，针对近几年XF公司的软件质量管理遇到的一些问题进行总结，以期为相关研究人员提供借鉴和参考。
[关键词]软件;质量管理;问题
中图分类号：TP31 文献标识码：A 文章编号：1674-1722（2021）15-0009-03
一、软件项目质量管理的内涵
软件质量就是软件与用户需求相一致的程度，具体包括功能、性能、易用性和可信度。软件质量形成于软件的整个开发过程中，而不是单纯的事后检查。软件质量管理就是以保证软件产品质量为目的的一系列行为，按时间分为事前、事中和事后管理。事前管理主要是制定管理计划，事中管理主要是全过程跟踪、技术评审、软件测试、过程检查，事后管理主要是缺陷跟踪、备案、预备后续项目开发留作借鉴。
二、问题现状和质量改进发起
近年来，随着XF公司组织规模的逐步扩大，为保障对核心技术的深入研究和核心能力的持续建设以及为了有效支撑集团内各内部业务，XF公司成立并确定核心技术研发中心部门的独立运营地位，并配套相应的QA等职能小组，用于梳理和持续改进研发中心的各个算法软件项目，从而提升软件项目交付质量和效率。
核心研发中心的业务核心是从事语音、图像、医疗、教育等多方向的核心技术研究（RD）以及各方向的技术落地算法库软件输出。RD部门从2017年正式成立，短短几年时间从百人的团队规模快速增加至近千人，其系列方向的研究和算法库软件产品的研发项目数量每年都在快速递增。2020年，由于项目规模的爆炸式增长带来产出速度和质量的下降，进而引发业务部门的投诉增加，问题凸显。为改善现状，RD部门专门成立了研发质量管控和质量改进小组，用于对RD部门需求承接评审把控、对研究和研发任务进行严格项目化运作、对算法库软件产品输出的质量进行管控和质量考核、完善输入输出的闭环化迭代等全流程优化改进。
三、问题现状梳理和分析
通过对XF公司内部业务需求部门对RD部门意见的反馈搜集和RD部门对内部进行访谈和开放讨论，可以发现如下问题：
（一）需求爆炸，不分主次优先级
软件质量和软件管理等问题逐渐增多，笔者搜集得到的结论主要指向一个源头：需求太多、人力不足、无法聚焦。主要集中在：
1.需求不聚焦，无明显主次优先级，需求方无成本压力、无需求准入规则。
由于RD部门成立的初衷就是一个纯粹的技术研发中心，负责向公司内部各个业务输出算法软件产品。由于初始的框架设计粗糙，总的定位和机构设定是：RD部门无成本压力，人力等各项支出由集团主要负责，各产品业务向RD部门提出具体需求，RD部门承接并向业务输出成果，业务方只承担RD部门较小比例的研发成本。这样的设定，直接造成了各产品业务需求方无约束地向RD部门提出各种各样的产品构想和需求，没有主次优先级，没有明显的业务部门间重点保障和基本支撑区分。
2.需求方人的势能和友情关系成分高，影响需求准入和投入规划。产品业务方没有明显的成本压力，RD部门也未对需求进行有效的过略和筛选，以及对需求的准入缺乏科学性和规范性。此时就出现了如下的现象：业务方领导的势能以及业务方人员和RD部门的管理者通过友情关系等非科学因素，过多介入RD部门对需求的准入判断和对业务支撑的投入规划[1]。
3.没有重点业务保障和支撑规格评价体系，“火力”不集中。需求的分散和对需求没有进行主次优先级明显的划分，無重点业务保障和支撑规格评价体系，造成很多研发项目优先级并列，非核心任务占据大量研发人力，而关键战略性业务没有得到可靠保障，影响整个公司的市场产出。
（二）内部研发项目管理不规范，没有配备专业的质量和标准化团队
RD部门缺乏专业的项目和质量管理团队，项目管理极不规范。大量研发项目的立项和发起很多都是研发人员自提启动，过程无监管，项目结项无判断监督准则。研发项目的结项，经常是不达标和带病收尾，且没有考核奖惩机制。
（三）对软件研发和软件测试的重视程度不够
1.在RD部门存在一条这样的潜规则“等级”：研究>软件研发>测试。研究产出只是第一步，最终产物输出需要软件研发进行实现和测试人员对质量的严格把控和准出。由于存在这样的“等级”体系，RD部门对软件研发和测试的重视程度和提供的激励体系有所欠缺，软件研发和测试只是作为上一级的助手而不是按照独立的组织结构划分，且对产物结果没有足够的考核决策权，员工积极性不足，产物质量控制弱。
2.没有标准通道和流程用于内部客户对问题和结果评价。
3.流程体系的不完善，还体现在业务需求对输出产物的结果评价规范标准不统一和流程通道不畅。产生了一些不合理的评价体系方法和引导效应：业务部门势能强的领导可以顺畅地给相应支撑团队和员工好或者不好的评价，简单的容易完成的项目容易获得好的评价等情况，会引导研发人员趋利避害，给业务带来伤害。
四、针对问题的改进方法设计
（一）需求不聚焦，无明显主次优先级，需求方无成本压力、无需求
1.调整成本分配比例，将RD部门成本分配集团补贴占大头的情况调整成集团补贴战略性研发投入，其他成本全部由业务需求方自行承担，且业务方不得自建核心技术研发团队，核心技术研发统一集中到RD部门，集中最优势兵力提供通用性核心技术产品输出。 2.RD部门成立需求准入评价专家，进行项目可行性、科学性和可靠性评价，公正科学地进行项目准入评价和项目等级确定。减少伪需求、假市场需求等不合理需求的导入，确保力量都用在刀刃上。
3.基于集成产品开发IPD（Integrated Product Development）的思想，设定V、R、M版本成本分摊机制，将业务需求的满足方法分为：平台通用型、基于通用平台轻定制型和客户独立定制型。V版本代表平台通用型，成本分摊方式为各需求业务线进行平摊;R版本代表通用平台轻定制型，成本分摊方式为只承担即时的人力成本;M版本代表客户独立定制型，成本分摊方式为客户外部立项，费用全担负型。引导业务需求方尽量多使用标准化统一版本，减少不重要的成本。
（二）内部研发项目管理不规范，没有配备专业的质量和标准化团队
建设专业的項目管理团队，对项目的启动、过程和收尾进行科学管理和把控，确保项目的内容、目标、时间、质量是按照部门的规范进行执行和输出。同时，把项目的标准化操作和项目质量的评价纳入员工绩效考核，科学引导研发和交付习惯[2]。
（三）对软件研发和软件测试的重视程度不够
成立工程院和测试质量部门，将软件研发人员和测试人员从作为研究员助手的方式调整成独立运行，研究保持平级和并行。并且统一全盘管理和调动，确保信息和流程的快速准确传递，既能保证各司其职，各有权力和势能，相互约束制衡，还能在员工积极性提高和产物质量保障上进行优化。
（四）无内部客户对问题和结果评价的标准通道和流程
提供定期半年度、年度的业务线对RD部门的考核沟通以及总结，RD部门内部会参考外部反馈并结合实际情况，根据内部评定的项目的难度、贡献度等情况，综合对员工进行项目和工作绩效进行科学考核，既能保障各个业务需求方清晰表达诉求和反馈，又能科学准确地对员工进行绩效评定，建立良好的评价引导机制。
（五）改进闭环迭代
软件研发、项目、质量各个机构，组织进行半年度和年度项目质量讨论，针对项目质量的情况以及实际需求，并结合业务形势的变化进行问题分析总结，及时调整管理和流程策略，进行更加科学的螺旋式改进。
五、改进总结
笔者就RD部门近几年在软件质量管理方面的一些措施稍作总结，以供同行参考。
（一）人的控制
核心研发中心近几年扩招人员众多，但是因多方面原因导致管理混乱，无法充分调动员工积极性和协调性，经常发生各个项目相同环节出现低级雷同错误，流程冗杂，或者同一项目多人同时参与存在窝工现象。XF公司针对这些问题，努力改进，主要从以下几个方面着手：
1.人事部门方面，对用人把好第一关，负责公司职员的招聘、选聘、录用。设置完善的聘用体系，负责制定、监督及执行企业管理规章制度、行政人事管理制度以及工作流程、绩效考核制度。
2.通过人事招聘引进工作经验丰富的项目经理，实行项目经理责任制，监控项目成员的软件活动，并对软件产品与可适用的标准、过程和软件开发计划的符合性进行评价。一般项目经理要求工作年限不低于8年，近几年XF公司陆续引进了4名项目经理。他们在各自岗位上很好地履行了自己的职责[3]。
3.各部门负责人针对自己部门形成拥有自己特色的人员管理方法。比如，公司组长以上级别人员定期参加公司组织的质量控制培训，并组织他们参加相关兄弟公司之间的交流，要以华为公司的管理体系为学习榜样。组内交流，每周召开一次小组会并形成周报，每月一总结，要求总结具体，总结不雷同，做到月月有心得。
4.不断完善公司人事制度，包括激励政策，同时实行错误惩罚制度，做到奖惩分明。尝试让管理效果倒过来反推管理制度的可行性，逐渐形成不断持续螺旋上升的PDCA管理模式。
（二）方法控制
流程和方法上和产品研发管理方面，配合战略，参与到集团引入的IPD集成产品研发管理体系中。集成产品开发（Integrated Product Development，简称IPD）的思想来源于美国PRTM公司出版的《产品及生命周期优化法》（Product And Cycle-time Excellence，简称PACE）。集成产品开发（IPD）以市场需求为核心，将产品开发看成一项投资，通过公共构建模块（Common Building Block，简称CBB）和跨部门的团队准确、快速、低成本、高质量地推出产品，是世界一流企业普遍采用的一套系统工具方法和策略。
RD部门部分软件项目质量管理改进方案设计中提出的质量管理体系不够完善、要求和产出准入准出机制欠缺、工作量估算不准确、设计重视程度不够、测试技术与管理应用不足、度量分析不足以及质量保证工作7个方面问题，借鉴ISO9000质量管理体系、CMMI模型和SCRUM敏捷模式，形成自己的一套独特三者融合的质量管理工具和方法。包括但不限于以下几个方面：
1.以需求管理过程改进，以客户本位，提高客户体验在项目考核中的权重。
2.事后控制，做好产品服务跟踪，文档归档;产品缺陷记录，要求产品全过程留痕，过程记录存档。
3.时间与成本控制，直接关系着软件产品的利润，时间成本增加可以提高产品质量，同时降低利润，与产品质量是对立面，公司要想发展，就要努力寻求两者的统一。做好产品质量的同时，降低时间与成本。这需要在管理上下功夫，弹性上班时间，实行早晨半小时弹性，给予员工时间上的自由度，同时严格考核，在有限的时间里，充分发挥管理效益，提高用工的性价比[4]。
4.成立质量管控和质量改进部门。该部门独立于公司各项目部门之外，要排除干扰，做到不受任何影响，确保质量管控工作的独立性。另外，该部门要承担处理员工投诉、客户投诉和定期监督检查等职责，还要参与质量事故调查、事故处理、项目跟踪备案等工作[5]。
5.引入IPD流程的管控，在RD部门内部的IPD流程内容主要包括需求准入，立项指标设计，CBB价值评估，项目结项指标评价等，还包括对产品开发过程、不同层次人员或组织的工作绩效进行衡量的一系列指标。比如，衡量标准有投资效率、新产品投入和带来产出价值的比率、被废弃的项目数、产物产品上市时间、支撑产品盈利时间、共用基础模块的重用情况等。
六、结语
XF公司在不断成长中，一直致力于软件质量管理，近几年成果明显，并会一直进行下去，努力完善软件项目质量管理流程等细节方面，期待软件项目质量管理跟随公司一起成长，做公司成长的见证人。
参考文献：
[1]张迪.基于软件开发项目管理平台的有效沟通管理，智能城市，2016（03）：38-39
[2]张强，袁文斌.基于CMMI的软件项目管理研究与实践[J].电子技术与软件工程，2021（09）：30-31.
[3]何晶.Scrum敏捷方法在软件项目管理中的应用[J].数字技术与应用，2021，39（03）：87-89.
[4]鲁若峰.计算机软件工程项目管理策略研究[J].网络安全技术与应用，2021（02）：55-57.
[5]田勇.计算机软件工程项目管理方法探究[J].中小企业管理与科技（中旬刊），2021（01）：23-24.
[关键词]软件;质量管理;问题
中图分类号：TP31 文献标识码：A 文章编号：1674-1722（2021）15-0009-03
一、软件项目质量管理的内涵
软件质量就是软件与用户需求相一致的程度，具体包括功能、性能、易用性和可信度。软件质量形成于软件的整个开发过程中，而不是单纯的事后检查。软件质量管理就是以保证软件产品质量为目的的一系列行为，按时间分为事前、事中和事后管理。事前管理主要是制定管理计划，事中管理主要是全过程跟踪、技术评审、软件测试、过程检查，事后管理主要是缺陷跟踪、备案、预备后续项目开发留作借鉴。
二、问题现状和质量改进发起
近年来，随着XF公司组织规模的逐步扩大，为保障对核心技术的深入研究和核心能力的持续建设以及为了有效支撑集团内各内部业务，XF公司成立并确定核心技术研发中心部门的独立运营地位，并配套相应的QA等职能小组，用于梳理和持续改进研发中心的各个算法软件项目，从而提升软件项目交付质量和效率。
核心研发中心的业务核心是从事语音、图像、医疗、教育等多方向的核心技术研究（RD）以及各方向的技术落地算法库软件输出。RD部门从2017年正式成立，短短几年时间从百人的团队规模快速增加至近千人，其系列方向的研究和算法库软件产品的研发项目数量每年都在快速递增。2020年，由于项目规模的爆炸式增长带来产出速度和质量的下降，进而引发业务部门的投诉增加，问题凸显。为改善现状，RD部门专门成立了研发质量管控和质量改进小组，用于对RD部门需求承接评审把控、对研究和研发任务进行严格项目化运作、对算法库软件产品输出的质量进行管控和质量考核、完善输入输出的闭环化迭代等全流程优化改进。
三、问题现状梳理和分析
通过对XF公司内部业务需求部门对RD部门意见的反馈搜集和RD部门对内部进行访谈和开放讨论，可以发现如下问题：
（一）需求爆炸，不分主次优先级
软件质量和软件管理等问题逐渐增多，笔者搜集得到的结论主要指向一个源头：需求太多、人力不足、无法聚焦。主要集中在：
1.需求不聚焦，无明显主次优先级，需求方无成本压力、无需求准入规则。
由于RD部门成立的初衷就是一个纯粹的技术研发中心，负责向公司内部各个业务输出算法软件产品。由于初始的框架设计粗糙，总的定位和机构设定是：RD部门无成本压力，人力等各项支出由集团主要负责，各产品业务向RD部门提出具体需求，RD部门承接并向业务输出成果，业务方只承担RD部门较小比例的研发成本。这样的设定，直接造成了各产品业务需求方无约束地向RD部门提出各种各样的产品构想和需求，没有主次优先级，没有明显的业务部门间重点保障和基本支撑区分。
2.需求方人的势能和友情关系成分高，影响需求准入和投入规划。产品业务方没有明显的成本压力，RD部门也未对需求进行有效的过略和筛选，以及对需求的准入缺乏科学性和规范性。此时就出现了如下的现象：业务方领导的势能以及业务方人员和RD部门的管理者通过友情关系等非科学因素，过多介入RD部门对需求的准入判断和对业务支撑的投入规划[1]。
3.没有重点业务保障和支撑规格评价体系，“火力”不集中。需求的分散和对需求没有进行主次优先级明显的划分，無重点业务保障和支撑规格评价体系，造成很多研发项目优先级并列，非核心任务占据大量研发人力，而关键战略性业务没有得到可靠保障，影响整个公司的市场产出。
（二）内部研发项目管理不规范，没有配备专业的质量和标准化团队
RD部门缺乏专业的项目和质量管理团队，项目管理极不规范。大量研发项目的立项和发起很多都是研发人员自提启动，过程无监管，项目结项无判断监督准则。研发项目的结项，经常是不达标和带病收尾，且没有考核奖惩机制。
（三）对软件研发和软件测试的重视程度不够
1.在RD部门存在一条这样的潜规则“等级”：研究>软件研发>测试。研究产出只是第一步，最终产物输出需要软件研发进行实现和测试人员对质量的严格把控和准出。由于存在这样的“等级”体系，RD部门对软件研发和测试的重视程度和提供的激励体系有所欠缺，软件研发和测试只是作为上一级的助手而不是按照独立的组织结构划分，且对产物结果没有足够的考核决策权，员工积极性不足，产物质量控制弱。
2.没有标准通道和流程用于内部客户对问题和结果评价。
3.流程体系的不完善，还体现在业务需求对输出产物的结果评价规范标准不统一和流程通道不畅。产生了一些不合理的评价体系方法和引导效应：业务部门势能强的领导可以顺畅地给相应支撑团队和员工好或者不好的评价，简单的容易完成的项目容易获得好的评价等情况，会引导研发人员趋利避害，给业务带来伤害。
四、针对问题的改进方法设计
（一）需求不聚焦，无明显主次优先级，需求方无成本压力、无需求
1.调整成本分配比例，将RD部门成本分配集团补贴占大头的情况调整成集团补贴战略性研发投入，其他成本全部由业务需求方自行承担，且业务方不得自建核心技术研发团队，核心技术研发统一集中到RD部门，集中最优势兵力提供通用性核心技术产品输出。 2.RD部门成立需求准入评价专家，进行项目可行性、科学性和可靠性评价，公正科学地进行项目准入评价和项目等级确定。减少伪需求、假市场需求等不合理需求的导入，确保力量都用在刀刃上。
3.基于集成产品开发IPD（Integrated Product Development）的思想，设定V、R、M版本成本分摊机制，将业务需求的满足方法分为：平台通用型、基于通用平台轻定制型和客户独立定制型。V版本代表平台通用型，成本分摊方式为各需求业务线进行平摊;R版本代表通用平台轻定制型，成本分摊方式为只承担即时的人力成本;M版本代表客户独立定制型，成本分摊方式为客户外部立项，费用全担负型。引导业务需求方尽量多使用标准化统一版本，减少不重要的成本。
（二）内部研发项目管理不规范，没有配备专业的质量和标准化团队
建设专业的項目管理团队，对项目的启动、过程和收尾进行科学管理和把控，确保项目的内容、目标、时间、质量是按照部门的规范进行执行和输出。同时，把项目的标准化操作和项目质量的评价纳入员工绩效考核，科学引导研发和交付习惯[2]。
（三）对软件研发和软件测试的重视程度不够
成立工程院和测试质量部门，将软件研发人员和测试人员从作为研究员助手的方式调整成独立运行，研究保持平级和并行。并且统一全盘管理和调动，确保信息和流程的快速准确传递，既能保证各司其职，各有权力和势能，相互约束制衡，还能在员工积极性提高和产物质量保障上进行优化。
（四）无内部客户对问题和结果评价的标准通道和流程
提供定期半年度、年度的业务线对RD部门的考核沟通以及总结，RD部门内部会参考外部反馈并结合实际情况，根据内部评定的项目的难度、贡献度等情况，综合对员工进行项目和工作绩效进行科学考核，既能保障各个业务需求方清晰表达诉求和反馈，又能科学准确地对员工进行绩效评定，建立良好的评价引导机制。
（五）改进闭环迭代
软件研发、项目、质量各个机构，组织进行半年度和年度项目质量讨论，针对项目质量的情况以及实际需求，并结合业务形势的变化进行问题分析总结，及时调整管理和流程策略，进行更加科学的螺旋式改进。
五、改进总结
笔者就RD部门近几年在软件质量管理方面的一些措施稍作总结，以供同行参考。
（一）人的控制
核心研发中心近几年扩招人员众多，但是因多方面原因导致管理混乱，无法充分调动员工积极性和协调性，经常发生各个项目相同环节出现低级雷同错误，流程冗杂，或者同一项目多人同时参与存在窝工现象。XF公司针对这些问题，努力改进，主要从以下几个方面着手：
1.人事部门方面，对用人把好第一关，负责公司职员的招聘、选聘、录用。设置完善的聘用体系，负责制定、监督及执行企业管理规章制度、行政人事管理制度以及工作流程、绩效考核制度。
2.通过人事招聘引进工作经验丰富的项目经理，实行项目经理责任制，监控项目成员的软件活动，并对软件产品与可适用的标准、过程和软件开发计划的符合性进行评价。一般项目经理要求工作年限不低于8年，近几年XF公司陆续引进了4名项目经理。他们在各自岗位上很好地履行了自己的职责[3]。
3.各部门负责人针对自己部门形成拥有自己特色的人员管理方法。比如，公司组长以上级别人员定期参加公司组织的质量控制培训，并组织他们参加相关兄弟公司之间的交流，要以华为公司的管理体系为学习榜样。组内交流，每周召开一次小组会并形成周报，每月一总结，要求总结具体，总结不雷同，做到月月有心得。
4.不断完善公司人事制度，包括激励政策，同时实行错误惩罚制度，做到奖惩分明。尝试让管理效果倒过来反推管理制度的可行性，逐渐形成不断持续螺旋上升的PDCA管理模式。
（二）方法控制
流程和方法上和产品研发管理方面，配合战略，参与到集团引入的IPD集成产品研发管理体系中。集成产品开发（Integrated Product Development，简称IPD）的思想来源于美国PRTM公司出版的《产品及生命周期优化法》（Product And Cycle-time Excellence，简称PACE）。集成产品开发（IPD）以市场需求为核心，将产品开发看成一项投资，通过公共构建模块（Common Building Block，简称CBB）和跨部门的团队准确、快速、低成本、高质量地推出产品，是世界一流企业普遍采用的一套系统工具方法和策略。
RD部门部分软件项目质量管理改进方案设计中提出的质量管理体系不够完善、要求和产出准入准出机制欠缺、工作量估算不准确、设计重视程度不够、测试技术与管理应用不足、度量分析不足以及质量保证工作7个方面问题，借鉴ISO9000质量管理体系、CMMI模型和SCRUM敏捷模式，形成自己的一套独特三者融合的质量管理工具和方法。包括但不限于以下几个方面：
1.以需求管理过程改进，以客户本位，提高客户体验在项目考核中的权重。
2.事后控制，做好产品服务跟踪，文档归档;产品缺陷记录，要求产品全过程留痕，过程记录存档。
3.时间与成本控制，直接关系着软件产品的利润，时间成本增加可以提高产品质量，同时降低利润，与产品质量是对立面，公司要想发展，就要努力寻求两者的统一。做好产品质量的同时，降低时间与成本。这需要在管理上下功夫，弹性上班时间，实行早晨半小时弹性，给予员工时间上的自由度，同时严格考核，在有限的时间里，充分发挥管理效益，提高用工的性价比[4]。
4.成立质量管控和质量改进部门。该部门独立于公司各项目部门之外，要排除干扰，做到不受任何影响，确保质量管控工作的独立性。另外，该部门要承担处理员工投诉、客户投诉和定期监督检查等职责，还要参与质量事故调查、事故处理、项目跟踪备案等工作[5]。
5.引入IPD流程的管控，在RD部门内部的IPD流程内容主要包括需求准入，立项指标设计，CBB价值评估，项目结项指标评价等，还包括对产品开发过程、不同层次人员或组织的工作绩效进行衡量的一系列指标。比如，衡量标准有投资效率、新产品投入和带来产出价值的比率、被废弃的项目数、产物产品上市时间、支撑产品盈利时间、共用基础模块的重用情况等。
六、结语
XF公司在不断成长中，一直致力于软件质量管理，近几年成果明显，并会一直进行下去，努力完善软件项目质量管理流程等细节方面，期待软件项目质量管理跟随公司一起成长，做公司成长的见证人。
参考文献：
[1]张迪.基于软件开发项目管理平台的有效沟通管理，智能城市，2016（03）：38-39
[2]张强，袁文斌.基于CMMI的软件项目管理研究与实践[J].电子技术与软件工程，2021（09）：30-31.
[3]何晶.Scrum敏捷方法在软件项目管理中的应用[J].数字技术与应用，2021，39（03）：87-89.
[4]鲁若峰.计算机软件工程项目管理策略研究[J].网络安全技术与应用，2021（02）：55-57.
[5]田勇.计算机软件工程项目管理方法探究[J].中小企业管理与科技（中旬刊），2021（01）：23-24.