从 QA 到 EP （二）

EP 是什么

说到这里，EP这个词才第一次出现，这个词的内涵之丰富，可能需要仔细说说。
我最早看到EP这个词，是在当时还是Google EP团队成员的James Wittaker写的那一个有名的「How Google Test」的系列博客中，内容我就不转述了，很多人都读过。
EP是Engineering Productivity的缩写，工程生产力的意思，这个团队，就是给整个大技术团队，甚至整个公司提高工作效率的。通俗直白的说，就是一个工具团队。因为工欲善其事、必先利其器，不要小看工具团队，某些程度上来讲，一个产品随着市场的变化可能很快凋亡，而一个好的工程工具，生命力要强得多，比如，开发语言其实就是最基本的工程工具了。那么，对一个公司，或者说交付团队来讲，怎么衡量工程生产力的高低呢？这个衡量方式其实就决定了「EP团队」的工作方向。

我们自己定义的工程生产力从低到高的定义是这样的：

1）质量，这是最基础的指标，什么都不行，也要保证质量过关，否则一个产品连生存的可能都没有。

2）同等质量水平下，追求速度。质量过关了，就要看迭代速度了，你比竞争对手快，你就能活下来。

3）同等质量和速度下，工程师的幸福感。如果质量也过关了，速度也快，但是大家过得很苦，天天加班，重复劳动，看不到未来，这也不行。幸福是什么？对我们来说，就是不被反复的简单问题所困扰，该自动的都自动，自动不是说一定快，但是一定省心，这里的幸福就是省心，有精力去关注更多的有意义的事情，而不是每天处理简单重复的问题。

4）同等质量和速度，也有幸福感，再看成长。工程师们有没有感受到成长？不断的解决问题或开发产品，感受到的是重复劳动还是成长？其实前三点都做到了，第四点一定是有的。

EP 做什么

我们回头说EP团队，EP团队也有自己的人生理想，那就是一个三部曲：替、教、独立。
第一个是替的阶段，其实就是比较老式的开发过程，我替你测试、替你上线、替你运维。
这个阶段，完全不符合我们「吃狗食」那一条价值观，按照狗食法则，一个人自己设计开发编码，当然要自己测试，自己写的代码bug多要一遍遍回归，这个苦果自己不吃谁来吃？但没办法，大多数程序员在如何测试自己的程序方面没有受过什么训练，为了尽快发布产品，只能替，但这个替的时间要越短越好，尽快进入下一个阶段，教。
第二个是教，就是教技术团队的其他成员，如何测试自己的程序，如何构造环境、构造数据，如何部署和运维自己的产品。这里的自己做，并不是回到蛮荒时期，例如创业初期只有一个程序员的时候，他当然是自己开发自己测试自己部署，但我们到了第二阶段的自己做，是自己规范的做，通过我们提供的相对完善和规范的工具做。我们就处于这个阶段的初期。
第三个阶段是独立，独立是说EP团队从一个替人做事的下游团队，到一个教人做事的教练团队，真正进化为一个提供技术服务的产品团队。这个产品团队的产品，大多数应该是以一个标准化的、健壮的服务的形式，而不是人力资源的形式，提供给其他团队的。当然这是我们的理想，能否达到或者是否切合实际，还需要时间来观察。

（未完待续）