Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

研发团队的角色和构成

Posted on 02/11/201601/24/2020 by 四火

software engineer

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

在我工作的第一家公司的时候,一个典型的研发团队是这样组成的。我的经验也只是到 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 或者一些更贴近业务职位的角色了。

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

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

×Scan to share with WeChat

你可能也喜欢看:

  1. Algorithm In Interview
  2. Singletons are Evil?
  3. We overestimate the value of coding
  4. 不同团队的困惑
  5. Java 多线程程序的测试

3 thoughts on “研发团队的角色和构成”

  1. 极分享 says:
    03/01/2016 at 11:34 AM

    受教啦!创业公司前期什么都要做

    Reply
  2. gml says:
    02/14/2016 at 7:19 PM

    开发什么都干,那是不是说开发就是打杂的?

    Reply
    1. 四火 says:
      02/15/2016 at 2:00 PM

      我觉得开发在某些团队里确实可以称作 “打杂的”。比如我见过某些偏重数据分析的团队,有一票数据分析人员,他们是懂业务懂数据的核心,开发负责维护机器维护环境来给他们数据分析,这样的角色简直变成了高级网管。

      Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Python Spark 互联网 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 程序员 管理 系统设计 缓存 编码 编程范型 英语 西雅图 设计 评审 问题 面试 项目

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Big Data and Machine Learning (5)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • + 1.943624 BTC.NEXT - https://graph.org/Ticket--58146-05-02?hs=9a9c6f8dfe3cdbe0074006e3e640b19b& on 所有文章
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
  • Anonymous on 我裸辞了
  • Dylan on 我裸辞了
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme