研发团队的角色和构成

以下都来自我的经历，带有主观评价，但是尽量保持平直的论述。

在我工作的第一家公司的时候，一个典型的研发团队是这样组成的。我的经验也只是到 4 年前，现在也许早就不一样了呢。

项目经理，这个角色是不断在换的。项目经理当然是只跟着项目走，这和团队经理（Team Leader）是不一样的。当然，Team Leader 也往往在不同的项目里面兼任项目经理。基层的项目经理也可能会编码，但是不管参与不参与编码，工作压力都不小。

SE（System Engineer，相当于现在大多数公司的产品经理）负责从市场部门等地方承接需求，然后做 “系统性设计”，这个系统多数指的是业务系统，也指有时候软件系统。之前我在一篇文章里面介绍过，同在基层，不同的公司会有不同的角色当老大。 比如在腾讯，产品经理是老大；而在我所在的公司，市场部门是老大，研发体系要弱不少。一个项目一般只有 1~2 个 SE。虽然负责业务设计和软件设计，但是 SE 的出身可以说是鱼龙混杂，有工程师，有测试，甚至有一线维护人员。

测试，对于这个角色的争议有不少。早些年测试和开发是分开的，不像后来合作那么紧密。但即便如此，我记得我工作的那段时间，软件版本从开发手里转交到测试手里（所谓版本发布），也算是一件大事，需要过 checklist 确保没有严重问题，而且是经常需要通宵的。测试人员和开发人员的比例一般说是 1:2 ~ 1:3，而且基本上测试的角色在公司相对受轻视，很多测试活动也没有什么技术含量。有不少工作都包给合作方完成。

QA，这个质量保证的工程师有点奇怪，他们其实是很多公司的 SQA，专门管流程的，算是一份闲差，通常也不受欢迎。因为他们要检查各种软件指标，比如什么测试覆盖率、圈复杂度、代码重复率等等。有个性个工程师一般都不喜欢这些束手束脚的东西。但是我知道有些公司搞这个东西搞得很恐怖，比如我老婆以前在三星工作，干的就是 SQA 这个角色，居然还要给别的不熟悉的项目代码挑毛病，这个活儿可不好干。

架构师，这个角色一般不出现。只是在一些非常重大的项目上，最先跳出来挥毫泼墨，带领一帮子 SE，负责架构设计，但是后期大量时间的架构维护就消失了。

UCD 工程师，他们通常和美工一起出没，基本上从产品设计到界面设计的活儿都主导了，甚至到一线去和客户谈判都有 UCD 工程师的身影。

开发，就是程序员。这也是整个研发体系的大军。基本上需求是从 SE 那里下的，但是对于项目内部的改进需求，也是由开发内部出文稿，然后汇总到 SE 的需求文档里。开发流程上面，从一开始的超越项目，到后来的敏捷，但是这些东西大部分都没有很好地搞起来，实际上还是在搞瀑布流程。敏捷实践确确实实高了一大堆，至于敏捷最核心的人，则是无从谈起。

现在我接触的团队，角色和职责发生了一些变化，依然是有利有弊。

先说项目经理。首先分清楚产品和项目，产品一般都有不同的团队来负责，没有个产品都可以找到某个 team 作为 owner，如果不能，那就是这个产品可以继续划分，小的产品一定可以找到这 owner。如果项目是在这样的 team 内部，通常 team leader 就兼任了项目经理，但是如果项目是跨团队了，那么有 TPM（Technical Project Manager）来负责在团队之间的协调。负责设计项目的，一般都是 senior 的工程师，不再设置专门的架构师或者上面说的 SE 来负责架构设计。因为可以自己做主了，工程师的自由度相对来说就大很多，这点很让我喜欢。当然这种方式下，对工程是要求其实是增加的，有时候一些管理相对松散的团队，我们就比较容易看到一些很差的设计。

QA（质量保证，或者测试）这样的角色基本消失了，说基本消失，是因为对于面向互联网和大众的产品，还能看到测试工程师的存在，有时候也招 contract 的测试工程师，而且高级别的测试工程师非常罕有，总而言之，看起来纯粹的测试这个角色无论在中国还是在美国，都是容易受到轻视的群体。我知道也看到有很多测试工程师跳出来为自己反驳，但是事实就是，绝大多数情况下，测试角色的设置，是有争议的；但是开发角色的设置，是没有争议的。如今我越来越习惯于软件工程师这样的头衔，无论是设计、编码还是测试，都是密不可分的部分。

SDE 和 WDE，前者叫做 Software Development Engineer，不必多介绍，是主力军，也是粘合剂，什么都干；后者叫做 Web Development Engineer，说实话这个角色设置得有些奇怪。在公司内部也是一个颇受争议的角色，争议的部分主要在于，这个角色的工程师应该怎样考察，他们应会什么，哪些方面必须比 SDE 强可能好说，但是可以允许在那些方面比 SDE 弱却不好说。我对此的看法是，偏重前端的工程师可以存在，但是这样的职位没必要存在。而且个人观察看来，往往 WDE 的发展很容易受到挤压和限制。

对于偏重数据的团队，还能见到许多 Data Analyst，人如其名，就是和数据打交道，SQL 用得滚瓜烂熟，需要扎到数据堆里调查业务问题。经常和数据打交道的还有一类角色叫做 Data Scientist，搞笑说法 “Data Scientist is Data Analyst in California” 就足见二者在难以区分。但是 Data Scientist 更多要涉足机器学习，要基于数据搞一堆模型，他们基本上都是数学相关专业的博士毕业。

Program Manager，这一角色我的观察是，他们总是和用户打交道，需要接触并且回答用户的问题，这样的职位不多，但是用户提的问题多了，就需要这样的角色来分担压力。东西做得好，逻辑清楚，或者说很容易得到（self service），这样的角色就不需要，越是做得烂的产品，或者不成熟的产品，才越是需要有人不断去回答问题。

Supporting Engineer，这几乎可以说就是个苦差事。因为不同时差和低人力成本的关系，有一些这样的角色包给印度去做。当然，也有很多团队，SDE 就在每天干这样的活儿，其实也没有差别了，只是明面上的职位名称不同而已。大量的 operation 工作，确实也能学习和成长，但是很少有设计和编码这样整块整块有趣的活动，改改代码也就是动一点点分支逻辑，大部分时间需要跳刀 ticket 的海洋里面搞问题，而且还时不时地需要写一些问题分析报告。

当然，还有其它角色，但是上面这些角色参与项目频繁，给我留下的印象比较深刻。

然后来说说其中两个相关的有争议的问题：

关于专职测试这个职位。就如同我上面说的那样，现实是测试往往受到轻视，这从某种角度说明了这个职位的尴尬性。我并不否认对于有大量用户的产品，以及对质量苛求的产品（比如某些航空航天产品，医疗产品，出问题是要出人命的），独立、专业的测试团队具备必不可少的价值，而这样的标准，一般我们所见的测试工程师，基本都是达不到的。绝大多数情况下，测试的独立角色设计，只会让整个软件设计开发流程变得冗长而低效，这也是我的经历告诉我的。工程师，就应该把测试作为最基本的素质素养来对待。这一点很像做性能优化，这件事情应该由工程师来完成，并且对于性能的考量要放到平时的设计编码中去，而不是突击指望专职的 “性能优化工程师” 来搞定。

SDE，someone does everything 好不好？正如我说，工程师什么都做，是粘合剂，全面性重要，但是也要看到，真的什么都做也是有诸多弊端的。工程师还是要把主要的心思放到设计和编码上面，放到软件和工程本身上面去。如果工程师要做太多和别的团队商讨需求和澄清业务的事情，团队经理和 TPM 应该想一想是不是自己的工作没做好；如果工程师要天天扎到数据里面去找逻辑证明业务没问题，那么要么是系统做得太烂，调查问题效率太低，要么就是该招 Data Analyst 或者一些更贴近业务职位的角色了。

关于你所经历的团队角色，和你的看法，欢迎讨论。

文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》