“鹅厂网事”由深圳市腾讯计算机系统有限公司技术工程事业群网络平台部运营，我们希望与业界各位志同道合的伙伴交流切磋最新的网络、服务器行业动态信息，同时分享腾讯在网络与服务器领域，规划、运营、研发、服务等层面的实战干货，期待与您的共同成长。
网络平台部以构建敏捷、弹性、低成本的业界领先海量互联网云计算服务平台，为支撑腾讯公司业务持续发展，为业务建立竞争优势、构建行业健康生态而持续贡献价值！
作者简介：lindaxu(徐玲)，高级工程师，网络平台部，服务器平台中心，研发管理组组长。
小编：上篇《定义和控制》介绍质量管理中，要先确定质量目标，要遵循的必要过程和相关资源，然后QA在现有流程体系框架指导下，对项目执行过程中的关键点和薄弱环节进行审核和检查，提前发现不合规问题和操作风险。
本次《度量和改进》请徐玲同学继续为大家解答如下问题。
规范操作和流程化是否能带来质量和效能上的提升？研发和运营结果是否达成项目目标和要求？如何衡量这些效果？有什么机制去保证衡量的完备性和有效性？
【度量】 —— If you can’t measure it, you can neither control nor manage it. H.詹姆斯•哈林顿(H.James Harrington)认为，“量化管理是第一步，它导致控制，最终实现改进。如果你不能量化某些事情，你就不能理解它;如果你不能理解它，你就不能控制它;如果你不能控制它，你就不能改进它。”
想要有效的控制和管理网平的项目，认知能力，识别目标、推动问题持续改进，就必须建立适用自己产品和项目特点的度量模型， 2013年启动软件度量体系建设前，我们提出了产品必须关注的几点问题： 1. 我们产品的产出质量如何？是否足够稳定，能否支撑部门的业务建设和业务运营， 可以在哪些方面提高？ 2. 我们的产出速度如何？是否能快速满足公司海量运营不断提升的需求，提高的关键点在哪里？ 3. 产出耗资多少人力物力？怎样以最小的成本，提供最大的服务价值 4. 我们建设的平台能否满足用户需求，网平提供的服务用户是否满意？
要回答这些问题，我们就要从质量、效率、成本、服务四个维度建模，并通过目标驱动的方法，梳理出网平项目当前最必要的度量项和指标，以帮助项目团队发现主要矛盾并推动解决。再从各项目度量项中提炼共性度量指标，形成部门的软件度量模型。下图是网平2013年初建立的软件度量模型。
度量模型中各维度的度量项，是根据当时关注的重点或核心矛盾设置的，前文已经介绍过，在12年中网平运营质量问题突出，为有效的分析运营故障高起的原因并解决它，可以看到，当时的度量重点集中在软件运营层面。
案例： 数据统计2013年1月时，仅uWork.process项目就有135单现网问题没有及时解决关闭，严重影响了产品口碑和满意度。
于是在【效率】维度引入 问题及时解决率，制定问题及时解决率的达成标准是：一级问题一周内关闭解决，二级问题一个月内关闭解决。要求对于一级问题没有及时解决的每周跟进分析原因，并推动改进提升。通过效率度量和QA的持续推动改进，项目的问题及时解决率三个月后全部达到100%。
当某个度量指标持续一段时间达标并稳定后，可能会从度量模型中移出，抽取其他问题的数据进行分析和度量，持续推动项目核心矛盾的改进。
这个度量模型运作到2013年底的时候，度量量化的各项目评估得分，均达到90分以上，已经相当理想和稳定，是不是说明我们的系统已经做得足够好，没有需要挖掘的问题和提升的短板了？实际上系统的高可用并不能全面客观的反映实际能力水平，包括系统的软件性能、可扩展性以及容灾备分能力等，也无法提前发现并有效规避项目风险和隐患。这就需要进一步完善现有的度量模型，健全量化评估机制。
2014年部门引入能力度量维度，包括：软件能力成熟度、流程成熟度和人力能力评估等， 使得度量评估更具系统化。
2014年1月，研发管理组发起网平第一期软件能力成熟度评估，从架构能力、运营能力共8个维度对所有项目进行自评、陈述和评审，得出的能力成熟度雷达图如下：
通过一系列检查、化验、诊断，终于找到了身体的疾病和病因。当前的短板集中在监控能力方面，找到了差距，接下来就是牵引团队去解决和改善问题。
通过度量、比对，找出项目不足和短板，给出解决方案，并实现持续改进和能力提升，这才是度量工作最终的目的和价值 。接下来进入下一个改进的工作环节。
【改进】 诊断出疾病，就必须要医治，让身体恢复健康。度量本身不会改进过程，但它为我们提供了对计划、控制、管理和改进的可视性。根据度量工作得到的量化信息，可以明确潜在的改进机会，通过确定的改进目标，制定改进方案并按计划落地实施，再通过一系列的度量手段验证改进效果，这个过程就是持续改进。
还是继续上面的案例，通过2014年初实施的第一次能力成熟度评估，明确了网平软件监控能力的短板，从部门AMB（架构管理委员会）给出的能力弱项评审意见来看，问题主要集中在以下几点：
• 各平台自监控，大多由问题或故障趋动，缺乏标准规范和系统化建设； • 基础监控都有做，但业务监控方面不够完善，对接口性能及可用性监控不全; • 没有统一的运营监控视图，缺乏异常告警闭环化处理以及原因统计分析机制。
明确了问题和改进机会，研发管理团队立即启动了部门监控能力提升项目，提升项目分三步走：第一阶段统一部门监控模型和标准，历时一个月，QA牵头组各项目监控负责人，共同收集和梳理监控模型和监控项。第二阶段各项目自建监控功能，6月底前实现监控数据统一上报。第三阶段建设部门监控平台，集中、客观展现各业务运营状态，为项目管理提供客观数据支撑（建设中）。
到14年年中第二次能力成熟度评估期间，我们的监控能力提升项目还未结束，仅实现标准建立和监控建设两阶段目标，但就评估结果看，监控能力已有了明显提升，由原有的72分提升至81分。接下来按既定的方向和计划推进，可达成持续改进的目标。
部门监控能力提升，是部门层面的持续改进活动。大多数情况下，QA所发现和推进提升的矛盾或问题会更聚焦，更贴近具体项目，有针对性。比如：严重缺陷率高，问题及时解决率低等。同样的，对于这些问题的改进遵循量化→分析→找出不足→实施解决，通过持续性的闭环化推进，实现项目的持续改进和能力提升。
【结语】 从以上介绍中可以看到，网络平台部的质量管理活动贯穿软件生命周期全过程，QA就是这个项目的专属医生，通过诊断（审计）、检查确诊（度量）、治疗（持续改进），发现并医治好这个项目一个个毛病和问题，形成质量管控的闭环管理，协助团队不断提升研发效能，让项目保持良性运转。
