|
|
# 20 | 特别放送：全栈团队的角色构成
|
|
|
|
|
|
你好，我是四火。又到了一个章节的末尾，相对轻松的特别放送时间。
|
|
|
|
|
|
从技术的角度上看，和相对偏“硬”的常规内容不同，特别放送部分，我一般倾向于介绍一些较“软”的其他内容。第一章的 [\[特别放送\]](https://time.geekbang.org/column/article/139370) 我介绍了北美大厂工程师的面试流程，第二章的 [\[特别放送\]](https://time.geekbang.org/column/article/145851) 我们讨论了学习的方法。那第三章的特别放送，也就是你正在阅读的这一讲，我想结合我自己的经历，谈一谈全栈团队的角色构成。
|
|
|
|
|
|
这些团队的角色构成可以说各有春秋，但是和以往直接进行优劣比较的方式不同，**今天我想换个形式，在这一讲的分享中，我将尽量保持中立和平和，而将有态度和有观点的思考留给你。**
|
|
|
|
|
|
我们整个专栏都在讲基于 Web 的全栈工程师，相应的，这里我提到的角色构成是针对“全栈团队”的。但它并非指一群全栈工程师所组成的团队，而是说，一个团队具备较多方面、较多层次的技能，联合协作去解决某一个具体领域的问题。
|
|
|
|
|
|
就我的工作经历而言，我其实在不少团队中待过，团队有大有小，既有国内的公司，也有北美的公司。而其中的几个大的项目，呆过的几个大的团队都可以认为是全栈团队。
|
|
|
|
|
|
## 华为
|
|
|
|
|
|
在华为的时候，我曾经作为某大型门户网站产品的初创团队成员，在其基线团队中呆了几年。你可能听说过，像华为这样的公司做产品，具备的最大优势就是“全面”，一般的公司可能着重于从某一个用户痛点，聚焦于某一个较窄范围内的问题解决办法，而华为具备足够的人力和财力去打造一个全渠道的完整体系的解决方案。
|
|
|
|
|
|
整个产品团队后来分为基线团队和定制团队两部分，前者着重于打造具备基础功能的产品，是产品交付的基础；而定制团队有多个，将基线版本根据不同的业务需求定制化，包括功能的裁剪和添加，以及针对业务的专项优化，卖到不同的国家和不同的市场中去。
|
|
|
|
|
|
当时，我们的基线产品研发团队中，有这样几个核心角色。
|
|
|
|
|
|
**项目经理**，项目总负责人，这个角色是不断在换的。项目经理当然是跟着项目走的，我们交付一个版本的时间在一个多月左右，那么每个版本都可以指定不同的项目经理。这个角色和**团队经理**（Team Leader）是不一样的，当然，理论上可以兼任。有时，团队经理也往往在不同的项目里面兼任项目经理。基层的项目经理一般都是程序员出身，也可能参与编码，但是不管参不参与编码，往往都会在产品的技术决策上有相当大的影响力。要说一个团队中最累的角色，可能就是项目经理了。我记得当时项目到了最紧张疯狂的时候，如今的 996 看起来根本就是不必言说的浮云，我的项目经理一周七天有三天是睡在公司的。
|
|
|
|
|
|
**SE**（System Engineer，系统工程师），实际角色相当于现在大多数公司的产品经理。这个角色负责从市场部门承接需求，然后做“系统性设计”。当然，这个系统多数指的是业务系统，也就是说，他们多数时候不关心技术层面的实现，但是业务流程精通得很。SE 的出身可以说是鱼龙混杂，有工程师，有测试，甚至有一线运维人员，毕业生是不能担任 SE 这个角色的，这个职位要求有一定的工作经验，因此他们大多是工作一定年头后转过来的。一个项目一般只有一个 SE，但是一些重点项目，或者规模较大的项目，可以有多个，比如我们当时的项目，一开始安排了 3 个 SE，在数周的“封闭会议”后，整个解决方案大的业务和技术框架就定下来了。同在基层，不同的公司中不同角色的“地位”是有差异的。比如在腾讯，产品经理相对话语权更大；在 Google，工程师更占主导；而在华为，市场部门是老大，研发体系相对要弱势一些，SE 则是二者沟通的桥梁。
|
|
|
|
|
|
**测试**，早些年华为的测试和开发是从组织架构上完全分开的，后来开发和测试也在逐渐融合，但也远不像互联网公司那样两个角色合一，而每天开发和测试之间的沟通协调，甚至争辩斗嘴就是我们的“日常”，团队氛围可以说颇为融洽。软件版本从开发手里转交到测试手里（所谓“转测试”），这个过程对于基线版本的工程师来说，其实就相当于版本发布了，是整个研发过程中的一件大事。流程上它需要经过测试团队提供的 checklist 来验证并确保没有严重问题，否则版本将被打回。但事实上要保证这个并不是一件容易的事，因此为了反复修复和验证 checklist 上面的检查项，转测试当天一般要拖很久，多半都需要通宵。当时，作为门户网站，测试人员和开发人员的比例一般说是 1:2 到 1:3，而且基本上测试的角色在这个体系中相对受轻视，测试活动一般都是黑盒的，多数也没有太多的技术含量。
|
|
|
|
|
|
**架构师**，大致可分为平台架构师和解决方案架构师，我们当时合作的是后者。这个角色就像是幕后高手一样，一般不出现。只是在一些非常重大的项目上，最先跳出来挥斥方遒，带领一帮 SE 搞定架构设计。架构师的经验阅历和技术功底都是相当靠谱的，但是几个月之后，包括架构维护的时间他就消失了。
|
|
|
|
|
|
用户体验，特别是界面设计方面，有这样几个角色协同合作：**UCD 工程师**，和用户沟通相对紧密，主导产品的界面设计和使用设计，然后把设计方案（多数是 PPT 一类的文档）交给**负责设计的美工**；而负责设计的美工，将方案落实到 Photoshop 的 psd 设计文件中，再交给另一波**负责快速原型的美工**；而这一波美工会将设计落实成一个 HTML 的快速原型，交到最终负责开发的工程师手里。
|
|
|
|
|
|
**QA**，这个质量保证的角色命名上其实有点奇怪，因为他们不做测试，而是专门监管流程质量，既包括研发流程，也做一些代码静态分析的工作，总的来说算是一份闲差。他们平时不出现，出现也不检查架构，不检查设计，而是要检查项目的各种工具指标，比如什么测试覆盖率、圈复杂度、代码重复率等等。显然，很多工程师都不喜欢这些束手束脚的东西。
|
|
|
|
|
|
最后，也是人数最多的，那就是**开发**，也就是程序员，这是整个研发体系的大军。前面已经提到了，需求总是从 SE 那里来的，如果是项目内部改进的需求，也需要开发出文档，再汇总到 SE 的需求列表里面去。绝大部分时间里，大家的任务都是按功能特性划分，而不是按照软件层次划分的，也就是说从工作应用的 Web 技术栈上看，确实是真正的“全栈”。作为基线版本的开发，我们不需要管上线之后的事情，因为有专门的运维人员第一时间来处理，而那些解决不了的问题和软件上的 bug 到了定制版本的研发团队那里，也多半被消化掉了，只有少数的具备共性的问题，才会送到基线版本的研发团队手里。
|
|
|
|
|
|
## Amazon
|
|
|
|
|
|
在亚马逊，我经历了两个比较大的全栈团队，一个是销量预测团队，一个是成本和利润计算的团队。
|
|
|
|
|
|
这两个团队中，前者的核心就是为亚马逊所有的商品预测销量，后者则是计算成本和利润，二者的实时性都比较高，数据量也都比较大，它们的技术栈类似，涉及机器学习、大数据处理、分布式任务管理、数据可视化等等，从整体看明显也是一个全栈团队，且角色构成也是较为丰富的。
|
|
|
|
|
|
团队经理的角色依然存在，对于每一个小团队来说，经理就是 **Dev Manager**，多数是软件工程师出身。只要不是跨团队的大项目，一般规模的项目都由 Dev Manager 牵头负责，小项目则由资深的工程师自己牵头负责。因此，项目经理这个角色，其实并不经常提起。
|
|
|
|
|
|
**TPM**（Technical Project Manager）担任起了产品经理的角色，负责业务需求的分析、设计和跟踪。如果项目是跨团队的，那么项目会有专职 TPM 来负责团队之间的协调。这个角色需要对业务非常熟悉，而技术层面要求不高。因为大团队是偏向于数据处理的，因此 TPM 如果有技术背景更好，但是那样的人才会非常难找。我知道某些公司要求这样的角色也有软件工程师背景，但是就我所经历的公司和我所了解的绝大多数公司的情况，并不是这样的。
|
|
|
|
|
|
值得一提的是，这两个团队都没有设 QA 的职位。**QA** 其实就是专职的测试，不过这样的角色在亚马逊的大多数团队中基本消失了。说基本消失，是因为绝大多数团队中，负责开发的工程师就把自己团队的产品测试工作给承包了，因此并不设立单独的测试岗位。当然，对于直接面向互联网和大众的产品，特别是包含复杂 UI 的产品，还能看到少量专职的测试工程师的存在，来负责部分专门的测试工作，当然，这一职位，很多时候是外包出去的。
|
|
|
|
|
|
**SDE**，全称是 Software Development Engineer，是主力军，也是粘合剂，不只是在技术层面上看是全栈的，就做的工作的类型上看也是（即从需求澄清、功能分解、任务跟踪，到开发、测试、部署、维护，全部都是开发人员做的，这点和华为的经历有所不同）。当然，对于工程层面的项目设计，也是有经验的工程师主导的，这个和前面说得差不多。在亚马逊有句对 SDE 戏谑的解释叫做“Someone Does Everything”。而所有的最小的团队，每个团队一般只有几个人，“Pizza Team”的称呼就是这么来的，就是说，团队的人用两张披萨就能喂饱，如果团队规模扩张到了超过 Pizza Team 的程度，就要拆分。
|
|
|
|
|
|
有时候，当前端工作的需求量特别大，团队就会规划招一个和 SDE 类似的特殊角色——WDE。**WDE** 就是 Web Development Engineer，有点像国内的“前端工程师”的角色了。也就是说，亚马逊只有 SDE 和 WDE，没有“后端工程师”这样的角色定位。说实话，这个角色设置得有些奇怪，在公司内部也颇受争议，争议的部分主要在于，这个角色的工程师应该怎样考察，衡量的标准在哪里。哪些方面必须比一般的 SDE 要求高可能好说，比如前端的工程能力，但是可以允许在哪些方面比一般的 SDE 低却不好说。而且从高级别的工程师比例来看，和 SDE 比起来，WDE 的发展往往容易受到挤压和限制。
|
|
|
|
|
|
因为我所在的两个团队都是偏重数据的团队，因此其中还有许多 **Data Analyst**，也就是数据分析师，他们和软件工程师的比例大致是 1:3，擅长和数据打交道，SQL 用得滚瓜烂熟，需要经常扎到数据堆里调查业务问题。这里面有一个很有意思的事情是，他们使用的很多工具，都是需要 SDE 来开发维护的，有时候 SDE 工作过于繁忙，来不及处理这样的问题，他们就被迫“Dev化”，自己尝试去解决本该由 SDE 来处理的工具问题。
|
|
|
|
|
|
另外，经常和数据打交道的还有一类人数不多的角色，叫做 **Data Scientist**，有一种戏谑的说法是“Data Scientist is Data Analyst in California”，这足见二者在技术能力和工作范畴上有一定的相似度。但是 Data Scientist 更多地要涉足机器学习，要基于数据建立起合适的模型，因此他们都有相当的专业背景。在我待过的那个销量预测团队中，预测的模型最开始就是他们建立起来并逐步调优的。
|
|
|
|
|
|
接着是 **Program Manager**，这个角色定位本身比较模糊，而我的观察是，他们很擅长和用户打交道，需要接触并回答用户的问题。和 TPM 不同的是，他们很少负责用户需求。这样的职位不多，但是用户提的问题多了，沟通的活儿多了，就需要这样的角色来分担压力。在同等用户量的情况下，东西做得越好，越容易使用，这样的角色就越是不需要的；而越是做得烂的产品，或者说是不成熟的产品，才越是需要有人不断地去回答问题。
|
|
|
|
|
|
**Supporting Engineer**，这几乎可以说就是个苦差事，他们做的其实就是运维（Ops）的活儿。事实上，多数的团队中，SDE 把测试的活儿都干了，也把大部分运维的活都给干了，通过运维的痛苦来反哺开发。有句话叫做“吃自己的狗食”（Eat Your Own Dog Food），就是说，SDE 自己开发埋的坑，自己不好好测试漏掉的坑，就要自己在 oncall 的时候半夜爬起来响应，并痛苦地解决线上问题。因此让 SDE 来运维肯定是首选，但是某些团队由于业务量等等的原因，SDE 干不过来，特别是在非工作时间发生问题的时候，于是支持工程师这样的角色就应运而生了。因为不同时差和低人力成本的关系，有一些这样的角色包给印度团队去做了。当然，也有很多团队，SDE 就在轮流干这样的活儿，其实也没有差别了，只是明面上的职位名称不同而已。你可以联想一下 AWS 如今的规模，这样的运维需求其实还是非常巨大的。当然，一般来说，在同等业务规模的情况下，产品做得越好，支持工程师的需求量就应该越少。
|
|
|
|
|
|
## Oracle
|
|
|
|
|
|
如今我呆的 OCI 的团队，依然是一个全栈团队，它的主要角色类型其实也差不太多。但是由于团队普遍比较新，一些以往需要其他专职角色干的活儿，目前还是由 SDE 来完成的。
|
|
|
|
|
|
这就是今天的全部内容，你对这些角色有什么看法？在你所经历的团队中，人员的角色构成又是怎样的呢？不妨分享一下吧。
|
|
|
|