质量保障工作的核心Roadmap

之前写过不少关于质量保障体系建设的文章，围绕质量保障这个话题，也分享了很多落地实践案例。

公众号后台又同学留言问了这样一个问题：如何在繁琐的工作中抓住质量保障工作的重点，有条不紊的开展工作？

这篇文章，分享一下我自己总结的开展质量保障工作，希望能帮到大家。

下图是我结合自己的实践经验和学习所总结的质量保障工作Roadmap大图：

大家都知道，软件从需求到交付，大致要经过四个阶段：需求+研发+测试+发布。

其中每个阶段都有各自的核心因素和具体的实施动作，以及一些注意事项，同时要开展质量保障工作，离不开一些基础的流程和工具设施。

只有抓住这些重点因素，才能保证质量保障的最终结果保持在下限之上。

首先，从软件生命周期的角度来说，四大阶段的核心因素总结起来可以归结为这几个关键字：

需求描述和定义：软件的最初起点来源于需求，需求的描述是否清晰，目标定义是否明确，在很大程度上影响软件的质量上限。技术同学都很痛很一句话需求，最根本的原因还是一句话需求的不确定性太强，让人抓狂。

技术的实现方案：如果说需求决定了一个软件产品的质量上限，那么技术就决定了质量的下限。

系统架构是否合理，技术实现方案难易程度，流程是否规范，技术指标是否明确，都会影响实现软件的过程，进而影响最重的软件交付质量。

风险和项目管理：如果问研发同学最痛恨什么，那大概率是需求变更或者临时插入需求，因为变更在很大程度上影响技术设计和实现。

从项目管理的角度来说，无论是需求的变更插入还是开始结束时间的改变，都会影响软件的质量。人人都痛很变更和风险，但变更和风险总是伴随着软件产品的从无到有，这也是项目管理和质量保障要解决的问题。

成本投入和指标：影响软件质量有三大要素：需求+成本+时间。除了需求无法用特别明确的指标定义，成本和时间都可以有明确的指标。

软件最终交付后的目标是实现业务目标，为公司带来直接或间接的收益，这也是为什么在很多项目中，管理者更关注资源的投入和deadline的原因。

其次，相比于需求这个很难控制的变量，技术同学更热衷于关注技术实现方面，毕竟技术，咱们是专业的。但技术的本质其实都是实现目标的手段，应用技术解决问题是实现目标的过程。

很多技术同学在工作中很容易遇到的一个问题就是，我用了很多的技术手段来优化性能，通过自动化测试来提升效率，但最终的交付质量和过程效率却没有明显的变化，这其实就是陷入了技术的桎梏中。

技术岗位追求技术的卓越没什么问题，但一定要明白一点：技术为产品服务，产品是实现业务目标的载体，最终的目的是带来商业收益和价值。

技术是手段和工具，本质上没有高低优劣之分，能支撑需求更快迭代，产品更快更好交付的技术，才是最受领导喜欢的技术。技术没有好坏，只有性价比只说。

再次，无论是软件工程，还是各种研发测试流程规范，甚至是业内的各种最佳实践和经验教训，都在提醒我们：软件研发和交付是很复杂的系统性工程，存在很多已知和未知的风险。

我们定流程，设计实现方案，优化代码实现，各种各样的测试手段，都是为了应对软件实现这个复杂系统工程中的各种风险。

这也是为什么很多公司在招聘软件测试工程师的JD中，要求候选人具备项目管理经验或者项目Owner能力的原因。

优秀的技术只是技术岗位的基本面，而良好的沟通协调能力以及项目管理和推动落地能力，才是一名软件工程师最核心的能力。

最后，要保障软件产品的快速高质量交付，离不开优秀的基础设施建设和团队支撑。

为什么公司规模越大业务越复杂，就越重视各种流程和管理方法？根本原因在于好的管理和完善的基础设施才是支撑达成最终业务目标的基座。

比如持续交付流水线的目的是打通软件从需求到上线发布的各种壁垒，提高迭代速率。比如项目管理是为了解决资源、时间、风险的不可控问题。比如监控是为了更快的发现和协助工程师快速的解决各种突发问题。

要做好质量保障工作，优秀的技术必不可少，这是手段。项目管理和沟通协调能力可以更好的促进这个过程，而流程机制的建立和基础设施建设，更可以促进团队更好的完成交付，保障最终的业务目标达成。

技术是60分万岁的底气，良好的沟通协调和项目管理能力是80分的锦上添花，基础设施建设是90分的长期价值和追求卓越，而优秀的工程师以及团队协作，才是保障满分交付的最大功臣。