从 QA 到 EP

两三年以前，和友人谈到QA（软件质量保证）这个行业，还有QA这个团队的未来，就有了一丝忧虑。而现在，终于有机会实践一下自己之前的想法，在这里分享给大家。

从我有限的从业经验到现在，经历了很多次软件开发模式的变化，这些变化，或因为跟风，或因为有切实的问题要解决，总之始终处于各种不同的尝试的路上。QA团队从最早的强调流程，到后来强调开发技术，搞自动化测试，再后来又开始做敏捷和持续集成，这条发展的路上，对自己的要求不断变高的同时，也伴随着一个组织和团队发展的魔咒。

组织发展魔咒

这个发展的魔咒更像是一个循环，可能开始于任何一个环节。

例如，公司负责技术的高层，没来由的认为，测试和质量保证并不重要。这个判断会慢慢渗透到技术团队的各个角落，导致测试工程师，乃至测试团队的其他角色，例如SQA，未来发展的空间会被压缩，而压缩发展空间的结果就是留不住人、招不到人。一方面相关工作的经验技能要求越来越高，一方面可见的天花板又摆在那里。于是整个QA团队都成了别人眼中的「低技术」团队，不论真的低技术还是别人以为的低技术，这种印象都很要命，为了摆脱这种印象，大家需要做点东西来证明自己，于是各种自动化测试框架、平台、系统，纷纷出现，殊不知此时，QA团队和整个公司的价值已经慢慢的不一致了，自己关起门跟自己玩，成了普遍现象之后，在公司高层看来，他会觉得自己的「QA团队并不重要」的判断被证明了，因为没有任何明确的证据表明，QA团队与公司愿景和计划之间的直接联系。

可怕么？在很多软件研发组织中，这是现实存在的循环。

说起来我们的实践，确实打破了这个循环，说起来好笑，我们解救QA团队的方式，就是彻底取消这个团队。但是反过来讲，只有杀死「QA团队」，才能真正的解放「QA工程师们」，真正解放整个软件研发过程。

一些基本的价值观

这个事情，就要从一些最基本的价值观说起。

比如，人总要对自己做的事负责。当然做了漂亮的事情，谁都希望头上有光环，但是做了丑事，也要能忍受得了羞辱。之为「吃自己的狗食」，而老式的软件开发分段流程，等于鼓励上游做的错事，下游来擦屁股，于是上游颐指气使，下游低三下四，这种颐指气使和低三下四还能传导，于是的于是，最下游的一个环节，就是公认的受气包了。暂不说效率和质量，从最基本的做事方法的角度，似乎也有些欠妥。我们这一条怎么落地呢，就是改组研发团队，建立Owner制度。一个项目的Owner，就像一个项目的CEO，大事小情都要关注，从产品到开发，从测试到运维，总之一个项目的成败，都需要Owner来操心，项目外的人，都是他的资源。相应的，项目也变得和平台无关，而与特性有关，每个项目组都会涉及到几个平台的设计、开发工作。

还比如，给质量一个明确的标准。做质量工作或者测试的人，都会有强迫症，总觉得哪里不对劲，还得狠狠的回归一遍，又一遍。可其实大家都知道质量是没有个确定的标准说好还是坏的，那怎么确定质量呢？我们称作「质量体现在造成实际的影响上」，也就是说，一个严重的问题，如果没造成影响，或很轻微，那就不严重。而一个轻微问题，如果影响面很广，例如有1000万用户都看见了，那就不轻微。

又比如，交付一个完美产品还是建立一个快速召回的机制？我们确实真的想每时每刻都能交付一个完美无暇的产品，但那不可能。特别是在互联网行业，跟传统的电信、医疗、航空航天的产品迭代有天壤之别，一个完美产品用一年做出来，市场可能早就变了天了。但不完美就有质量风险和代价，为了平衡这一点，我们必须建立一个快速召回缺陷产品的机制，甚至能让用户在发现缺陷之前，就用上了新版本。

有了这几条价值观，我们就大概知道开发过程改进的方向，以及做事情的原则了。那我们做了什么呢？我们组建了EP团队。

EP 是什么

说到这里，EP这个词才第一次出现，这个词的内涵之丰富，可能需要仔细说说。

我最早看到EP这个词，是在当时还是Google EP团队成员的James Wittaker写的那一个有名的「How Google Test」的系列博客中，内容我就不转述了，很多人都读过。

EP是Engineering Productivity的缩写，工程生产力的意思，这个团队，就是给整个大技术团队，甚至整个公司提高工作效率的。

（未完待续）