【第1607期】我在 Airbnb 4 年不同时期的 4 个不同职责
前言
大家也可以试着用下方的框架来给自己的职业生涯画一下。今日早读文章由Airbnb@Luca Luo投稿分享。
正文从这开始～～
前些时间跟一个在考虑跳槽的码农朋友聊天，他感慨道换工作的时候对新公司研究得再清楚，还是不能确定新工作是不是自己喜欢的。很多人都发表过同样的观点，不管换公司还是换组，新的工作虽然还都叫码农，除了公司、老板、同事上的变化，工作内容本身也可以千差万别。而这种差别很难在 JD 里写清楚，更别说用一个职位的名称来区分了。前端和前端，后端和后端，工作内容上也可以很不一样。
最近读到墙外一篇 Google PM 写的文章，给了一个很好的思路。她阐述了一个类似于游戏中人物能力图的框架来描述产品经理的不同职责。比如说做创业公司的时候主要靠自己干，而做一个 300 人游戏公司 PM 的时候很多任务则是去影响不同的团队。
受到她的启发，我试着用一个类似的框架对码农工作画像，来回答不同码农职位之间的差异。 我会先用过去 4 年我在 Airbnb 不同时期的职责为例解释这一框架，然后探讨这个框架对码农职业选择和发展的指导。
职责归类
在分析码农工作是怎么构成的之前，首先要把所有不同职责归类。我粗略地分成了以下 7 类，分别是：
开发：包括写代码，写测试样例，做代码审查，写相关的文档等。
运维：包括部署，发版，监控，处理预警和线上突发情况等。
数据：包括日志埋点，维护数据流，做数据分析等。
构架：包括做系统和架构设计，拓展容灾方案，开发任务的模块化和分拆等。
业务：包括构建产品需求，路线图和里程碑（milestone），参与产品和设计的决策等。
项目：包括项目进度的管理，与不同职能同事的沟通合作，对外的合作，流程优化等。
人事：包括面试招人，辅导（mentor）或指导（coaching），培训，绩效考核等。
对于这个分类，尽管我做过从基础架构到前端产品非常多种类的工作，有相对完整的理解，但是肯定不能涵盖所有码农的日常工作，还请你能留言加以补充。
我的 4 个不同职责
接下来用我在不同时期的不同职责来具体分析一下这个框架实际应用下来是什么效果。
第 0-2 年：基础架构（infrastructure）工程师
工作的前两年，我在一个负责整个 Airbnb 线上存储的基础架构团队。更准确地说，是我和当时的 mentor 后来的老板创立了这个团队。2015 年的 Airbnb 正好处在一个业务高速成长，传统的关系型数据库难以支持它体量的时候。刚开始工作的几个月，核心数据库经常爆仓，因此除了传统的开发任务，还有很多的运维工作，而且需要通过分析数据尽可能的找到以及预警数据库负载的业务逻辑重头，因此也有一些数据分析的工作。
后来随着自身的成长，以及团队度过了被动应对爆仓的阶段，接下来的一年时间我主要负责一个全新的数据库接入层的设计和开发。这段时间做了很多架构设计的工作，并随着项目开始推进有新的同学加入，也开始辅导新同学以及管理项目进展。
综合来看，这段时间是以开发运维为主，数据分析为辅，并随着自己变得更加资深有了一些架构、项目和人事方面的任务。除了运维略多之外，总体上可以说是一个互联网公司基础架构组比较典型的码农样本了。
第 2-3 年：后端工程师 / Tech lead
工作两年左右的时间，我加入了一个业务组作为后端的 Tech lead，主要负责后端构架从单一服务向微服务转型，成功的成为了整个 Airbnb 第一个迁移到微服务架构的业务部门。换组之后运维的工作骤减，当时感觉心理特别轻松，不像做数据库的时候总是想着会不会什么时候数据库又挂了。纯粹开发的工作也比之前略少，很多时间花在新的架构设计，管理项目来确保进度，以及帮助其他同学上。除此之外，我也对部门负责的相关业务很感兴趣，尤其是算法驱动的业务，因此花了很多时间分析业务数据，参与产品的讨论，以及实现一些产品功能上。
这段时间的工作，还是一个比较典型的资深后端工程师 / Tech lead 的职责。技术架构、项目执行和团队建设三方面非常均衡。
第 3-3.5 年：产品工程师 / Tech lead
第三年初的时候回到祖国怀抱，加入了 Airbnb 在北京的团队，一开始的几个月作为一块 C 端主流程业务的产品工程师和 Tech lead。这部分工作以产品开发为主，越发远离基础架构，因此几乎没有了运维和架构方面的工作。取而代之的则是花很多时间在业务上，包括和产品经理、设计师、数据科学家等一同探索产品方向，明确产品的路线图，订里程碑等。在我之前的一篇文章【第1583期】 Airbnb 的“硅谷”产品工程师中讨论过，Airbnb 对业务团队的工程师有着比较全面的要求，包括产品和数据相关的能力，具体可以移步了解。
如果与做后端时候的职责对比，可以明显的看出来作为 Tech lead 的一些职责基本上没有变化，主要是把架构和运维变成了业务职责。在 Airbnb 这也是一个比较典型的业务团队的产品工程师 / Tech lead 的职责了。
第 3.5 - 4 年：技术经理（Engineering Manager)
过去的几个月我转岗做了技术经理，业务范围上和之前变化不大，但是具体职责上还是有相当大的调整。开发和数据分析的工作不再是重点，但是因为一开始管理的团队不大，我还是保持了一定的代码和相关的数据工作，尤其是在一些新的不确定性高的业务上，而把相对完整具有体系化的开发工作由团队成员负责。节省出来的时间花在了业务探索，项目管理，尤其是人事管理上。绩效管理，团队组建，以及对整个中国的工程团队的管理流程优化都是之前作为 Tech lead 不会直接负责的。同时，作为团队负责人在日常有很多沟通工作分散在各个职责之中。随着团队规模扩大，之后势必还要承担更多的人事工作，到时也应该会继续减少自己的开发任务。
整体看，上图非常好的显示出了作为技术经理的时间分配：业务、项目、人事和具体执行的工作各占四分之一左右。随着团队扩大，执行工作会逐渐全部授权出去，演变为业务、项目和人事各三分之一。
码农职责框架的应用
读到这里，我想你对于如何用这个框架来描述码农的不同职责有了一个比较好的理解。任何一个框架都有两个作用：对一个人来说是促使考虑问题更完整，对一群人来说是统一交流的语言。同样，这个码农职责框架一方面是帮助你我来比较完整地分析自己的工作职责，找到合理的和需要改变的点；另一方面是在与人沟通交流的时候能有一个统一的认知，避免鸡同鸭讲。接下来我们就用几个例子来具体谈谈如何应用这个框架。
先回到最开始的例子，在换工作换组的时候，最大的困难就是无法明确新工作具体的职责。比如说有些人想多花时间写代码，有些人想多做架构设计，有些人想承担更多项目管理的工作。职责框架一个显著的好处就是可以帮助自己明确理想的职责，同时对潜在的新工作有一个完整的分析。换句话说，明确自己现在有什么，想要什么，以及新的职位能提供什么。对自己的分析就不多说了，在跟潜在公司团队交流的时候，就可以目的性很强的来调查新职位对于的具体职责是怎么分配的。甚至作为招聘方，如果能在 JD 中附上这样一个职责的图片，就可以从一个侧面传递职位的需求了。
职责的变更不只发生在职位变化的时候。随着团队责任、业务需求以及自身的成长，职责都可能会改变。用这个框架也可以比较好的来明确这个变化。比如随着一个码农变成资深码农，就应该需要逐渐承担起构架、人事和项目管理的工作。
再扩大一点来说，大家热衷讨论的走技术还是走管理，中美码农的差别等等，都可以用这套框架来分析。技术线就会以开发、架构为主，走管理线则会是以人事、项目为主；而美国码农更重业务，国内码农更重开发。
结语
这篇文章阐述了一个框架来描述同为”码农“这个职位下实际上不同的工作职责，用我四年来的四个不同职责作为例子来解释这个框架，最后探讨了这个框架的实际意义。这是一个开放的讨论：我对码农职责的总体分类还局限在自身的经历，势必会随着参与讨论人数的增多做进一步的修正。但是框架本身的意义很大程度就在于驱动你去思考，而非一定要有一个正确答案。那么你的职责分配又是什么样的呢？
关于本文
作者：@Luca Luo
原文：https://mp.weixin.qq.com/s/dl4nt0emVbSigFN74mU3Pg
他曾分享过
为你推荐