EP 是什么
说到这里,EP这个词才第一次出现,这个词的内涵之丰富,可能需要仔细说说。
我最早看到EP这个词,是在当时还是Google EP团队成员的James Wittaker写的那一个有名的「How Google Test」的系列博客中,内容我就不转述了,很多人都读过。
EP是Engineering Productivity的缩写,工程生产力的意思,这个团队,就是给整个大技术团队,甚至整个公司提高工作效率的。通俗直白的说,就是一个工具团队。因为工欲善其事、必先利其器,不要小看工具团队,某些程度上来讲,一个产品随着市场的变化可能很快凋亡,而一个好的工程工具,生命力要强得多,比如,开发语言其实就是最基本的工程工具了。那么,对一个公司,或者说交付团队来讲,怎么衡量工程生产力的高低呢?这个衡量方式其实就决定了「EP团队」的工作方向。
我们自己定义的工程生产力从低到高的定义是这样的:
1)质量,这是最基础的指标,什么都不行,也要保证质量过关,否则一个产品连生存的可能都没有。
2)同等质量水平下,追求速度。质量过关了,就要看迭代速度了,你比竞争对手快,你就能活下来。
3)同等质量和速度下,工程师的幸福感。如果质量也过关了,速度也快,但是大家过得很苦,天天加班,重复劳动,看不到未来,这也不行。幸福是什么?对我们来说,就是不被反复的简单问题所困扰,该自动的都自动,自动不是说一定快,但是一定省心,这里的幸福就是省心,有精力去关注更多的有意义的事情,而不是每天处理简单重复的问题。
4)同等质量和速度,也有幸福感,再看成长。工程师们有没有感受到成长?不断的解决问题或开发产品,感受到的是重复劳动还是成长?其实前三点都做到了,第四点一定是有的。
EP 做什么
我们回头说EP团队,EP团队也有自己的人生理想,那就是一个三部曲:替、教、独立。
第一个是替的阶段,其实就是比较老式的开发过程,我替你测试、替你上线、替你运维。
这个阶段,完全不符合我们「吃狗食」那一条价值观,按照狗食法则,一个人自己设计开发编码,当然要自己测试,自己写的代码bug多要一遍遍回归,这个苦果自己不吃谁来吃?但没办法,大多数程序员在如何测试自己的程序方面没有受过什么训练,为了尽快发布产品,只能替,但这个替的时间要越短越好,尽快进入下一个阶段,教。
第二个是教,就是教技术团队的其他成员,如何测试自己的程序,如何构造环境、构造数据,如何部署和运维自己的产品。这里的自己做,并不是回到蛮荒时期,例如创业初期只有一个程序员的时候,他当然是自己开发自己测试自己部署,但我们到了第二阶段的自己做,是自己规范的做,通过我们提供的相对完善和规范的工具做。我们就处于这个阶段的初期。
第三个阶段是独立,独立是说EP团队从一个替人做事的下游团队,到一个教人做事的教练团队,真正进化为一个提供技术服务的产品团队。这个产品团队的产品,大多数应该是以一个标准化的、健壮的服务的形式,而不是人力资源的形式,提供给其他团队的。当然这是我们的理想,能否达到或者是否切合实际,还需要时间来观察。
(未完待续)