EP 团队的工作方式与面临的挑战
1）没人管的事情我们管，支持所有团队。公司内部虽然分成了很多个团队，但是很多技术问题是找不到人负责的，例如，一个简单的内部数据统计脚本，或者一个发布内容到CDN的CMS，等等。这些事情基本都会由EP团队接过来。
2）做事情没有计划。这个特点可能很多人会觉得匪夷所思，甚至不能接受，但实际上这跟EP团队的工作有关系，比如汽车4S店，有多少车祸的汽车要修理，多少人为损坏的车要修理，怎么做计划？实际上是遇山开道、遇水搭桥。外部的市场的变化、内部的技术人员的变化，都会有不断的瓶颈出现，而EP就要快速发现并解决这些瓶颈，直到发现下一个瓶颈，这个过程没办法有详尽的长期的计划。而替代的是使用目标管理的方式，我们公司内部所有团队都会用一种叫做OKR（Objective and Key Result）的方式来做管理，简单的说，就是设定目标，然后评估完成度。EP团队的目标大致有两个方向，一个我们叫做「Smoothly&Fast」，就是让一切跑通做顺的能力，还有一个就是「实现自助」，能让其他团队的成员，不管是技术还是非技术背景，都能自己通过我们的工具完成任务。
这些特点看起来很不错，但是实际上带来的问题也非常多，例如：
没有成就感。因为所有人都是你的需求方，这个感觉实在是不太好，另一个角度讲，很多研发工程师会觉得开发一个对外的产品比较有成就感，对内的总觉得没意思。这个问题要解决，其实就要靠所谓的「工程师文化」来解决，国内长期以来在职业化上有一些不好的习惯，其实能发明工具的人都是大师，开发语言就是工具，操作系统也是工具，真正的牛人，都在做各式各样的工具。能帮助别人成功的人，是最成功的。
还有，就是脱离实际。很多人做工具，怎么炫怎么做，流行什么做什么，要么就大而全，这还是好的，更多的时候是想的大而全，半年做不出来。整个公司的价值取向是一致的，特别是小公司，容不得这种炫技一般的工作方式。所以我有一句话，叫做「自high无价值」，什么叫「自high」？就是自己跟自己玩，玩的很高兴。
还有一个问题，就是招聘困难。这个在SED的工作职责部分提过，就不展开了。因为招聘困难，我们就要考虑怎么培养这样的人才，所以我们有一个方法论，叫做「要改进，先体验」，因为很多EP的成员是要改进工作过程的，但是怎么改，不是所有人都能搞定，这依赖于大量的经验积累，对经验不足的人，很简单，就是让他去做。要提高研发效率，找到痛点，那就先去做一个月研发；要去改进测试过程，提高效率，就去做一个月测试。一个技术和思维方式都很不错，只是经验少的人，经过一个月的体验，能提出非常多的、而其他人已经麻木了的改进点，并推动实施。
1）创业团队。创业团队就是短小精悍，精力集中，没有太多无谓的纷扰，快速交付产品快速迭代是主要的工作方式。
2）从第一天开始坚持自由和责任的工程文化。从创始人开始，很坚持这种工程文化，有什么样的leader就有什么样的团队，所以大家接收和拥抱EP的工作模式，也非常快。
虽然上述这两条很多公司没有，但不代表做不成这个事情，在我看来，只要具备下面几条，想做成EP的工作，就并不难。
1）互联网行业。互联网行业有一个非常好的，区别于以往其他行业的特点，就是你的产品在物理上是自己控制的，提供的只是服务，这非常有利于快速迭代，因为传统行业不可能做到。
2）快速变化的业务模式。这不是说我们自己要快速变化，而是业务模式和市场不断变化，来推着我们前进。只有业务模式的快速发展，才对生产力有不断更高的要求。
3）有改变的决心。这个说起来有点虚了，但也很重要，因为EP这样的工作模式会有阵痛，例如团队的重组、转型，都会影响到一部分人的利益，特别是团队的管理者，而这些中高层管理者，也确实有能力阻止变革。但坦白的说，很多时候你不主动改变，到了客观环境推动你不得不变的时候，到最后就成了被淘汰的人了。我还有一句话，叫做「组织结构决定工作模式」，意思是说，很多工作模式的出现，是因为组织结构的需要。反过来说，在你的组织里很多很好的工作模式推动不下去，或者效果很差，你就要看看你的组织结构是不是有问题。比如两个本来应该紧密合作的团队，一直合作不好，互相鄙视，你想简化流程，最后流程越做越多，大家都在垒墙，那你就要看看两个团队共同的老板，是不是级别太高了。
4）对团队成员的高标准。前面我提过，我们EP团队的大部分是Geek型的人，Geek这个词在英语里是一种很高的评价。只有一个技术和经验都非常丰富的人，才能胜任EP这样的工作，所以要坚持不懈的雇佣一流的人才，人不够，可以抓大放小，但绝不能有二流、三流的人在团队里。
1）没人管的事情我们管，支持所有团队。公司内部虽然分成了很多个团队，但是很多技术问题是找不到人负责的，例如，一个简单的内部数据统计脚本，或者一个发布内容到CDN的CMS，等等。这些事情基本都会由EP团队接过来。
2）做事情没有计划。这个特点可能很多人会觉得匪夷所思，甚至不能接受，但实际上这跟EP团队的工作有关系，比如汽车4S店，有多少车祸的汽车要修理，多少人为损坏的车要修理，怎么做计划？实际上是遇山开道、遇水搭桥。外部的市场的变化、内部的技术人员的变化，都会有不断的瓶颈出现，而EP就要快速发现并解决这些瓶颈，直到发现下一个瓶颈，这个过程没办法有详尽的长期的计划。而替代的是使用目标管理的方式，我们公司内部所有团队都会用一种叫做OKR（Objective and Key Result）的方式来做管理，简单的说，就是设定目标，然后评估完成度。EP团队的目标大致有两个方向，一个我们叫做「Smoothly&Fast」，就是让一切跑通做顺的能力，还有一个就是「实现自助」，能让其他团队的成员，不管是技术还是非技术背景，都能自己通过我们的工具完成任务。
这些特点看起来很不错，但是实际上带来的问题也非常多，例如：
没有成就感。因为所有人都是你的需求方，这个感觉实在是不太好，另一个角度讲，很多研发工程师会觉得开发一个对外的产品比较有成就感，对内的总觉得没意思。这个问题要解决，其实就要靠所谓的「工程师文化」来解决，国内长期以来在职业化上有一些不好的习惯，其实能发明工具的人都是大师，开发语言就是工具，操作系统也是工具，真正的牛人，都在做各式各样的工具。能帮助别人成功的人，是最成功的。
还有，就是脱离实际。很多人做工具，怎么炫怎么做，流行什么做什么，要么就大而全，这还是好的，更多的时候是想的大而全，半年做不出来。整个公司的价值取向是一致的，特别是小公司，容不得这种炫技一般的工作方式。所以我有一句话，叫做「自high无价值」，什么叫「自high」？就是自己跟自己玩，玩的很高兴。
还有一个问题，就是招聘困难。这个在SED的工作职责部分提过，就不展开了。因为招聘困难，我们就要考虑怎么培养这样的人才，所以我们有一个方法论，叫做「要改进，先体验」，因为很多EP的成员是要改进工作过程的，但是怎么改，不是所有人都能搞定，这依赖于大量的经验积累，对经验不足的人，很简单，就是让他去做。要提高研发效率，找到痛点，那就先去做一个月研发；要去改进测试过程，提高效率，就去做一个月测试。一个技术和思维方式都很不错，只是经验少的人，经过一个月的体验，能提出非常多的、而其他人已经麻木了的改进点，并推动实施。
再有，依赖整个团队的成熟度。不是说有了EP这样一个团队，整个公司的效率和工作模式就会有大幅度提升，因为一个汽车再好，你开的方向不对，也到不了目的地。现实中存在着非常多缺乏责任感的Owner，很多人觉得，我写完代码编译通过了，丢给测试组就行了，没我的事了，这样的想法大有人在，所以从成立EP团队，到整个公司的生产力真正被提高，中间不只是提供工具这么简单，还有一系列的指导和训练的工作。
Why we can & why you can
1）创业团队。创业团队就是短小精悍，精力集中，没有太多无谓的纷扰，快速交付产品快速迭代是主要的工作方式。
2）从第一天开始坚持自由和责任的工程文化。从创始人开始，很坚持这种工程文化，有什么样的leader就有什么样的团队，所以大家接收和拥抱EP的工作模式，也非常快。
虽然上述这两条很多公司没有，但不代表做不成这个事情，在我看来，只要具备下面几条，想做成EP的工作，就并不难。
1）互联网行业。互联网行业有一个非常好的，区别于以往其他行业的特点，就是你的产品在物理上是自己控制的，提供的只是服务，这非常有利于快速迭代，因为传统行业不可能做到。
2）快速变化的业务模式。这不是说我们自己要快速变化，而是业务模式和市场不断变化，来推着我们前进。只有业务模式的快速发展，才对生产力有不断更高的要求。
3）有改变的决心。这个说起来有点虚了，但也很重要，因为EP这样的工作模式会有阵痛，例如团队的重组、转型，都会影响到一部分人的利益，特别是团队的管理者，而这些中高层管理者，也确实有能力阻止变革。但坦白的说，很多时候你不主动改变，到了客观环境推动你不得不变的时候，到最后就成了被淘汰的人了。我还有一句话，叫做「组织结构决定工作模式」，意思是说，很多工作模式的出现，是因为组织结构的需要。反过来说，在你的组织里很多很好的工作模式推动不下去，或者效果很差，你就要看看你的组织结构是不是有问题。比如两个本来应该紧密合作的团队，一直合作不好，互相鄙视，你想简化流程，最后流程越做越多，大家都在垒墙，那你就要看看两个团队共同的老板，是不是级别太高了。
4）对团队成员的高标准。前面我提过，我们EP团队的大部分是Geek型的人，Geek这个词在英语里是一种很高的评价。只有一个技术和经验都非常丰富的人，才能胜任EP这样的工作，所以要坚持不懈的雇佣一流的人才，人不够，可以抓大放小，但绝不能有二流、三流的人在团队里。
（完）
扫一扫
795
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
