标签：style http 使用 io strong ar 数据 问题 cti
两三年以前，和友人谈到 QA（软件质量保证） 这个行业，还有 QA 这个团队的未来，就有了一丝忧虑。而现在，终于有机会实践一下自己之前的想法，在这里分享给大家。
从我有限的从业经验到现在，经历了很多次软件开发模式的变化，这些变化，或因为跟风，或因为有切实的问题要解决，总之始终处于各种不同的尝试的路上。QA 团队从最早的强调流程，到后来强调开发技术，搞自动化测试，再后来又开始做敏捷和持续集成，这条发展的路上，对自己的要求不断变高的同时，也伴随着一个组织和团队发展的魔咒。
这个发展的魔咒更像是一个循环，可能开始于任何一个环节。
例如，公司负责技术的高层，没来由的认为，测试和质量保证并不重要。这个判断会慢慢渗透到技术团队的各个角落，导致测试工程师，乃至测试团队的其他角色，例如SQA，未来发展的空间会被压缩，而压缩发展空间的结果就是留不住人、招不到人。一方面相关工作的经验技能要求越来越高，一方面可见的天花板又摆在那里。于是整个 QA 团队都成了别人眼中的 「低技术」团队，不论真的低技术还是别人以为的低技术，这种印象都很要命，为了摆脱这种印象，大家需要做点东西来证明自己，于是各种自动化测试框架、平台、系统，纷纷出现，殊不知此时，QA 团队和整个公司的价值已经慢慢的不一致了，自己关起门跟自己玩，成了普遍现象之后，在公司高层看来，他会觉得自己的 「QA 团队并不重要」的判断被证明了，因为没有任何明确的证据表明，QA 团队与公司愿景和计划之间的直接联系。
可怕么？在很多软件研发组织中，这是现实存在的循环。
说起来我们的实践，确实打破了这个循环，说起来好笑，我们解救 QA 团队的方式，就是彻底取消这个团队。但是反过来讲，只有杀死「QA 团队」，才能真正的解放「QA 工程师们」，真正解放整个软件研发过程。
这个事情，就要从一些最基本的价值观说起。
比如，人总要对自己做的事负责。当然做了漂亮的事情，谁都希望头上有光环，但是做了丑事，也要能忍受得了羞辱。之为 「吃自己的狗食」，而老式的软件开发分段流程，等于鼓励上游做的错事，下游来擦屁股，于是上游颐指气使，下游低三下四，这种颐指气使和低三下四还能传导，于是的于是，最下游的一个环节，就是公认的受气包了。暂不说效率和质量，从最基本的做事方法的角度，似乎也有些欠妥。我们这一条怎么落地呢，就是改组研发团队，建立 Owner 制度。一个项目的 Owner，就像一个项目的 CEO，大事小情都要关注，从产品到开发，从测试到运维，总之一个项目的成败，都需要 Owner 来操心，项目外的人，都是他的资源。相应的，项目也变得和平台无关，而与特性有关，每个项目组都会涉及到几个平台的设计、开发工作。
还比如，给质量一个明确的标准。做质量工作或者测试的人，都会有强迫症，总觉得哪里不对劲，还得狠狠的回归一遍，又一遍。可其实大家都知道质量是没有个确定的标准说好还是坏的，那怎么确定质量呢？我们称作 「质量体现在造成实际的影响上」，也就是说，一个严重的问题，如果没造成影响，或很轻微，那就不严重。而一个轻微问题，如果影响面很广，例如有 1000 万用户都看见了，那就不轻微。
又比如，交付一个完美产品还是建立一个快速召回的机制？我们确实真的想每时每刻都能交付一个完美无暇的产品，但那不可能。特别是在互联网行业，跟传统的电信、医疗、航空航天的产品迭代有天壤之别，一个完美产品用一年做出来，市场可能早就变了天了。但不完美就有质量风险和代价，为了平衡这一点，我们必须建立一个快速召回缺陷产品的机制，甚至能让用户在发现缺陷之前，就用上了新版本。
有了这几条价值观，我们就大概知道开发过程改进的方向，以及做事情的原则了。那我们做了什么呢？我们组建了 EP 团队。
说到这里，EP 这个词才第一次出现，这个词的内涵之丰富，可能需要仔细说说。
我最早看到 EP 这个词，是在当时还是 Google EP 团队成员的 James Wittaker 写的那一个有名的 「How Google Test」的系列博客中，内容我就不转述了，很多人都读过。
EP 是 Engineering Productivity 的缩写，工程生产力的意思，这个团队，就是给整个大技术团队，甚至整个公司提高工作效率的。通俗直白的说，就是一个工具团队。因为工欲善其事、必先利其器，不要小看工具团队，某些程度上来讲，一个产品随着市场的变化可能很快凋亡，而一个好的工程工具，生命力要强得多，比如，开发语言其实就是最基本的工程工具了。那么，对一个公司，或者说交付团队来讲，怎么衡量工程生产力的高低呢？这个衡量方式其实就决定了「EP团队」的工作方向。我们自己定义的工程生产力从低到高的定义是这样的：1）质量，这是最基础的指标，什么都不行，也要保证质量过关，否则一个产品连生存的可能都没有。2）同等质量水平下，追求速度。质量过关了，就要看迭代速度了，你比竞争对手快，你就能活下来。3）同等质量和速度下，工程师的幸福感。如果质量也过关了，速度也快，但是大家过得很苦，天天加班，重复劳动，看不到未来，这也不行。幸福是什么？对我们来说，就是不被反复的简单问题所困扰，该自动的都自动，自动不是说一定快，但是一定省心，这里的幸福就是省心，有精力去关注更多的有意义的事情，而不是每天处理简单重复的问题。4）同等质量和速度，也有幸福感，再看成长。工程师们有没有感受到成长？不断的解决问题或开发产品，感受到的是重复劳动还是成长？其实前三点都做到了，第四点一定是有的。
我们回头说 EP 团队，EP 团队也有自己的人生理想，那就是一个三部曲：替、教、独立。
第一个是替的阶段，其实就是比较老式的开发过程，我替你测试、替你上线、替你运维。
这个阶段，完全不符合我们「吃狗食」那一条价值观，按照狗食法则，一个人自己设计开发编码，当然要自己测试，自己写的代码 bug 多要一遍遍回归，这个苦果自己不吃谁来吃？但没办法，大多数程序员在如何测试自己的程序方面没有受过什么训练，为了尽快发布产品，只能替，但这个替的时间要越短越好，尽快进入下一个阶段，教。
第二个是教，就是教技术团队的其他成员，如何测试自己的程序，如何构造环境、构造数据，如何部署和运维自己的产品。这里的自己做，并不是回到蛮荒时期，例如创业初期只有一个程序员的时候，他当然是自己开发自己测试自己部署，但我们到了第二阶段的自己做，是自己规范的做，通过我们提供的相对完善和规范的工具做。我们就处于这个阶段的初期。
第三个阶段是独立，独立是说 EP 团队从一个替人做事的下游团队，到一个教人做事的教练团队，真正进化为一个提供技术服务的产品团队。这个产品团队的产品，大多数应该是以一个标准化的、健壮的服务的形式，而不是人力资源的形式，提供给其他团队的。当然这是我们的理想，能否达到或者是否切合实际，还需要时间来观察。
从这三个阶段的描述中，多多少少都提到一些 EP 团队和整个技术团队或整个公司的关系，那这个关系是什么呢？
前面提过，我们不希望是个下游替人收尾的团队，我们也有「吃狗食」这样的原则，所以我想到一个比喻，来说明 EP 团队和其他技术团队的关系。
我们都知道有一个行业叫做汽车制造业，他们遵循一定的规范和标准，还能巧妙的将创意和标准结合在一起，制造出一些工业奇迹，这些汽车被卖给各式各样的人，汽车企业并不关心他们的产品用在什么地方，不过他们又发明了一种叫做 4S 店的东西，用来给那些工业奇迹定期维护、修理、还可以收集市场反馈以便改进产品。
还有另一个行业叫做物流业，他们的目的就是将货物从一个地方运到另一个地方，这种空间的转移，就是他们为客户创造的价值。在这过程中，他们会利用到汽车制造业产出的汽车，但他们不太关心汽车本身的标准、设计细节，他们只是使用，他们关心的是使用成本、维修方便。出问题，他们会找 4S 店。
这两个行业之间的交集是汽车，汽车制造业的价值是制造出好的汽车，物流业的价值是货物的到达，汽车制造业不关心你的货物的目的地，物流业不关心他的汽车的制造工艺。但汽车制造业会很关心你怎么用这个汽车，以及积极的帮助你保养，而物流业也会很关心这个车费不费油，好不好开。
说到这里，你可能已经看明白 EP 团队和其他技术团队的关系了：EP 团队就像汽车制造业，提供高效、低耗的工具；产品技术团队就像物流业，使用工具，快速前进，创造用户价值。他们之间互相依赖，却又彼此独立。
了解了 EP 和周围团队的关系之后，来看看我们的 EP 团队的角色和成员。
我们的 EP 团队，大致分成如下几个角色（而实际上的工作是混合的，之所以要分开成角色，主要是从招聘的角度出发）：
SED，Software Engineer in DevOps。顾名思义，这个角色首先是个软件开发工程师，其次，面向的领域是 DevOps，DevOps 的概念我们就不必多讲了，在实际工作中，SED 工程师是个真正的多面手，他们可能今天在开发一个 Linux server 的自动化上线和回滚的工具，明天就要设计或优化 CDN 的部署，后天又要解决一个 Windows 平台编译加速问题，还有还有一个自动性能 benchmark 工具等着他来开发。这个角色目前我们只有两位，而且这个角色的工程师是最难招聘的，因为新人，或者很小的公司出来的人，很少有受过系统的训练或有比较先进的软件工程思想，而从大公司出来的人，已经被大公司条块分割的工作方式同化，一般只擅长一个领域，而对跨界的或者不懂，或者没兴趣。所以这个岗位的工程师，都是有成熟公司工作经验的 Geek 型的人。
SA，System Admin。系统工程师，和很多公司的运维工程师很想像，实际上我们现在的状态，做的事情也和大多数公司的运维工程师一样，处理监控，优化服务部署等等，但不一样的是我们的目标是将绝大多数应用层面的运维工作交还给开发团队，所以我们在不断的将监控系统改造为友好的，自助的，也不断的将各位上线部署类的工作做成自动的，现在已经有了很多成果，我们的 SA 主要精力可以放在系统以及更底层的部分了。
TE，Testing Engineer。测试工程师，其实这个称呼有点名不符实，我们的唯一一位测试工程师，主要的工作其实是发布和迭代控制，要保证整个交付团队的迭代节奏，例如在代码上拉发布分支、触发发布事件、监控数据等等工作，这个工作要求非常精确，又很繁琐，因此和 SED 工程师有非常多的交互，他们负责将这个过程自动化。这里插入介绍一下我们的发布过程，可能大家会更理解为什么还有个「发布工程师」：
我们有三个发布 Channel：Beta、RC、Release，作用各有不同。例如 Beta Channel，主要用于一些新特性的提前发布，这里面可能会多少有点缺陷，所以一定要控制人数，并且是那些喜欢尝鲜的用户，他们会用的比较彻底。而 Beta Channel，可能每天都有版本更新，会有一些用户喜欢跟着 Beta 版。而这些新的特性如果用户反馈不错，并且没有什么严重的问题，就会进入最近一次 RC（Release Candidate），这个量就很大了，大概能占到我们每日活跃用户的十分之一到五分之一，这里面的功能在没有意外的话，就是正式发布的功能了，需要注意的是，不是每个 Beta 都会变成 RC。而 RC 在发布几天之后，如果一切正常，就会切换为 Release，Release Channel 一般会在一天之内，让绝大多数活跃用户升级完毕，这个时候，如果程序有 bug，影响就非常大了。
Venders，外包测试团队。我们有大约六七个人的外包测试团队（on-site），主要负责我们主要产品的人工验收测试。我们对外包测试团队的工作方式也有一个设想，就是一个项目刚开始的时候，外包测试团队应当是先上很多人，然后随着 SED 的介入，让自动化程度加强，慢慢人少下来，直到下一个新项目开始。但这个设想在国内想实现，却没那么容易，主要有几个原因：1）国内的外包测试的工程师，通常是技术和经验都比较初级的人来做，外包测试成了一个门槛低天花板也低的行业，技术和经验缺乏，导致进入新项目以后没办法非常快的上手，而有经验有能力的人，很快就会脱离外包行业；2）外包测试的公司，人才储备不足，很少有人力资源池，都是有需求，现从市场上招，或从竞争对手那里挖，有的人都没见过，就派到客户那边来面试，这也导致了没办法几个月就撤下来，因为他没办法跟候选人签合同。这两个客观原因，我们也比较无奈，所以我们的外包测试团队基本上还是长期 on-site。
UOE，user operation engineer。用户运营工程师，这个岗位很多人不太容易理解，一般用户运营人员都是跟内容啊、用户打交道的，就像贴吧管理员就是典型的用户运营人员，那为什么要有个运营工程师呢？这个我们是跟硅谷的 Dropbox 学习的。因为在日常工作中，我们发现有想当一部分用户的反馈，不论是新功能的需求还是缺陷，都是技术性很强的，如果你能做到第一时间和用户做深入的，技术含量较高的沟通，从解决问题的成功率上会高很多，而如果你反馈一个技术问题，总是过了几天才有技术人员跟你联系的话，你可能配合排查问题的愿望会小很多。基于这个思路，我们增加了这个角色，同时他们还负责一些运营过程中使用的工具和平台类的研发。可能会有人问这个角色为什么会在 EP 团队？其实仔细分析一下用户运营的工作，会发现他们处理的对象是一个个用户提交的 ticket，这非常像 test case，不同之处是一个是用户事后提交，一个是事先设计，分别保证了优先级和完备性，因此结合起来，对提高质量是非常有益的事情。
上面这几个角色，就组成了我们的 EP 团队，这样的一个团队，这样的一个能力构成，就有了一些鲜明的特点，例如：
1）没人管的事情我们管，支持所有团队。公司内部虽然分成了很多个团队，但是很多技术问题是找不到人负责的，例如，一个简单的内部数据统计脚本，或者一个发布内容到 CDN 的 CMS，等等。这些事情基本都会由 EP 团队接过来。
2）做事情没有计划。这个特点可能很多人会觉得匪夷所思，甚至不能接受，但实际上这跟 EP 团队的工作有关系，比如汽车 4S 店，有多少车祸的汽车要修理，多少人为损坏的车要修理，怎么做计划？实际上是遇山开道、遇水搭桥。外部的市场的变化、内部的技术人员的变化，都会有不断的瓶颈出现，而 EP 就要快速发现并解决这些瓶颈，直到发现下一个瓶颈，这个过程没办法有详尽的长期的计划。而替代的是使用目标管理的方式，我们公司内部所有团队都会用一种叫做 OKR（Objective and Key Result）的方式来做管理，简单的说，就是设定目标，然后评估完成度。EP 团队的目标大致有两个方向，一个我们叫做 「Smoothly & Fast」，就是让一切跑通做顺的能力，还有一个就是「实现自助」，能让其他团队的成员，不管是技术还是非技术背景，都能自己通过我们的工具完成任务。
这些特点看起来很不错，但是实际上带来的问题也非常多，例如：
没有成就感。因为所有人都是你的需求方，这个感觉实在是不太好，另一个角度讲，很多研发工程师会觉得开发一个对外的产品比较有成就感，对内的总觉得没意思。这个问题要解决，其实就要靠所谓的「工程师文化」来解决，国内长期以来在职业化上有一些不好的习惯，其实能发明工具的人都是大师，开发语言就是工具，操作系统也是工具，真正的牛人，都在做各式各样的工具。能帮助别人成功的人，是最成功的。
还有，就是脱离实际。很多人做工具，怎么炫怎么做，流行什么做什么，要么就大而全，这还是好的，更多的时候是想的大而全，半年做不出来。整个公司的价值取向是一致的，特别是小公司，容不得这种炫技一般的工作方式。所以我有一句话，叫做「自 high 无价值」，什么叫「自 high」？就是自己跟自己玩，玩的很高兴。
还有一个问题，就是招聘困难。这个在 SED 的工作职责部分提过，就不展开了。因为招聘困难，我们就要考虑怎么培养这样的人才，所以我们有一个方法论，叫做「要改进，先体验」，因为很多 EP 的成员是要改进工作过程的，但是怎么改，不是所有人都能搞定，这依赖于大量的经验积累，对经验不足的人，很简单，就是让他去做。要提高研发效率，找到痛点，那就先去做一个月研发；要去改进测试过程，提高效率，就去做一个月测试。一个技术和思维方式都很不错，只是经验少的人，经过一个月的体验，能提出非常多的、而其他人已经麻木了的改进点，并推动实施。
再有，依赖整个团队的成熟度。不是说有了 EP 这样一个团队，整个公司的效率和工作模式就会有大幅度提升，因为一个汽车再好，你开的方向不对，也到不了目的地。现实中存在着非常多缺乏责任感的 Owner，很多人觉得，我写完代码编译通过了，丢给测试组就行了，没我的事了，这样的想法大有人在，所以从成立 EP 团队，到整个公司的生产力真正被提高，中间不只是提供工具这么简单，还有一系列的指导和训练的工作。
最后，关于我们为什么能做这个事情，我们也有一些总结：
1）创业团队。创业团队就是短小精悍，精力集中，没有太多无谓的纷扰，快速交付产品快速迭代是主要的工作方式。
2）从第一天开始坚持自由和责任的工程文化。从创始人开始，很坚持这种工程文化，有什么样的 leader 就有什么样的团队，所以大家接收和拥抱 EP 的工作模式，也非常快。
虽然上述这两条很多公司没有，但不代表做不成这个事情，在我看来，只要具备下面几条，想做成 EP 的工作，就并不难。
1）互联网行业。互联网行业有一个非常好的，区别于以往其他行业的特点，就是你的产品在物理上是自己控制的，提供的只是服务，这非常有利于快速迭代，因为传统行业不可能做到。
2）快速变化的业务模式。这不是说我们自己要快速变化，而是业务模式和市场不断变化，来推着我们前进。只有业务模式的快速发展，才对生产力有不断更高的要求。
3）有改变的决心。这个说起来有点虚了，但也很重要，因为 EP 这样的工作模式会有阵痛，例如团队的重组、转型，都会影响到一部分人的利益，特别是团队的管理者，而这些中高层管理者，也确实有能力阻止变革。但坦白的说，很多时候你不主动改变，到了客观环境推动你不得不变的时候，到最后就成了被淘汰的人了。我还有一句话，叫做「组织结构决定工作模式」，意思是说，很多工作模式的出现，是因为组织结构的需要。反过来说，在你的组织里很多很好的工作模式推动不下去，或者效果很差，你就要看看你的组织结构是不是有问题。比如两个本来应该紧密合作的团队，一直合作不好，互相鄙视，你想简化流程，最后流程越做越多，大家都在垒墙，那你就要看看两个团队共同的老板，是不是级别太高了。
4）对团队成员的高标准。前面我提过，我们 EP 团队的大部分是 Geek 型的人，Geek 这个词在英语里是一种很高的评价。只有一个技术和经验都非常丰富的人，才能胜任 EP 这样的工作，所以要坚持不懈的雇佣一流的人才，人不够，可以抓大放小，但绝不能有二流、三流的人在团队里。
标签：style http 使用 io strong ar 数据 问题 cti
原文地址：http://www.cnblogs.com/yanghj010/p/3947696.html
