聚合国内IT技术精华文章,分享IT技术精华,帮助IT从业人士成长

研发团队的角色和构成

2016-02-12 10:45 浏览: 2686330 次 我要评论(0 条) 字号:

研发团队的角色和构成

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

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

欢迎讨论:你所经历的团队角色有什么不一样的地方?你又有什么看法呢?

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



网友评论已有0条评论, 我也要评论

发表评论

*

* (保密)

Ctrl+Enter 快捷回复