中小互联网公司研发效能团队规模、职能划分和优劣势分析

 

这是「研发效能团队规模、职能划分和优劣势分析」系列的第二篇。上篇文章分析了研发效能团队的规模、职能划分和优劣势的意义和价值，本篇文章主要分析产研团队在200人以下的中小公司现状以及给出一些建议。说实话产研团队在200人的公司在中国已经是不小的公司了。想想每年有那么多新公司建立，每年有那么多的公司倒闭，能养活200人产研团队的公司已经是很大的企业了，尤其是今年（2022年）在疫情和国外严峻形势的影响下，国内每个企业都活得很艰难。

 

软件和信息技术服务业。从业人员300人以下或营业收入10000万元以下的为中小微型企业。其中，从业人员100人及以上，且营业收入1000万元及以上的为中型企业；从业人员10人及以上，且营业收入50万元及以上的为小型企业；从业人员10人以下或营业收入50万元以下的为微型企业。

 

我国在软件行业对中小企业的定义如上。而「从业人员」并非都是产研，300人的企业如果其中有200人的产研团队，技术人员占比已经很高。200人的软件企业，在成都人力成本每人每月2w 算，一个月人力成本400w；在北京的话人力成本就更高了。前些天问我一个接技术外包的同事，他的团队人比较少但是很资深能出活人力成本5w（人均工资3w多）

 

公司规模

• 产研团队200人以下

组织架构

• 【现状】研发效能团队组织架构不固定，相对随意。挂在某个研发团队、运维团队、PMO、QA底下都有公司实际这么做的。这个时候研发效能团队可能仅仅1-4人，甚至很多都是研发、QA、运维小伙伴兼职。

 

• 【建议】我个人觉得研发效能团队的组织架构放到研发团队下面会更好，更有利于工作的推动，目前大多数公司也是这么做的。同时建议设置一名运维小伙伴主要对接研发效能团队的工作。也就是说有一名运维小伙伴作为接口人来负责对外（研发效能）团队的支持，对内(运维团队)的协调，这样更有助于支持工作的快速响应。这个运维接口人是做实际支持工作的人，而不是运维团队的领导，这点很重要。对质量团队同样也要有这样的接口人。

职能划分

因为人少，缺少明确的职业发展规划和工作职责界定，各个公司定义未必一致，工作职责主要分三部分：

• 维护开源软件或者正版/非正版的商用软件，负责这些工具的日常维护、培训、支持；

• 规范软件研发流程，提出改进意见和方案，并积极协同其他人员在公司内部落地实施、监督执行和持续优化

• 负责各种环境的搭建和维护，需要部分系统管理、数据备份、脚本开发的工作

 

具体工作：

• [V] 项目管理工具(jira、禅道、redmine、tapd、Teambition等）

• [V] 源码管理工具(Gitlab, Subversion, TFS、Github、Gerrit等）

• [V] 编译打包构建、流水线（Maven、Gradle、npm、Jenkins等）

• [V] 制品库（Nexus、Artifactory、Docker registry）

• [V] 系统维护（Windows、Linux、Mac OS、Docker、K8s等）

• [V] 脚本语言（Shell、Python）

 

上面列的都是非常主流的工具。如果都没用到，那可能要考虑下是技术太新了还是已经过时，还是因为技术栈差别太大（比如嵌入式开发）。做事的时候也要不时抬头看看前面的路，兼顾当下和未来。

 

因为人员比较少，通常不涉及移动端效能的工作，这部分一般由研发团队自己负责；这里通常也不涉及度量的工作，主要是考虑到各个系统相对比较独立，价值在各个系统中流转脱节，可以度量价值流动的数据不全，从需求到发布上线这种端到端的度量指标容易失真且不容易自动获得；再者也很少涉及自研工具的事情，主要还停留在把已有工具搭建起来，能用，服务稳定上。如果能做到所有系统关联、账号打通那已经很不错了。难道这就是传说中的「竹匠用的漏底筐,木匠睡的缺腿床」？

团队优势

• 接触面很广，短时间内学到很多东西，有助于成长为一个多面手，对将来在某个方向深入进去有激发的作用。之前有的同事去做PMO了，有的去做咨询师了，还有的去做运维了、转QA做开发的也有。

• 满足业务发展的同时，可以折腾些自己感兴趣的东西，成长空间比较大。

团队劣势

• 做的东西很杂甚至经常变化，广度可以但深度不够，做的方向和内容的深度肯定不及大厂专业团队。想要做深做强，还需要刻意的学习和积累，有机会去大厂参观技术交流是个不错的实践。去别的公司「开天眼」学习交流的事，大厂之间也经常这样做。

• 不够专业化和规范化。有些东西真的是「见多识广」才能积累的。我觉得公司小的时候，多面手是有很大价值的，但是一旦公司发展起来就需要更加专业化和职业化的技术人员，这样效率才能最高。

• 如果公司发展慢，那么不利于长远(3年+）发展

 

针对工程师的专业化和全栈工程师多说两句。全栈这种事只能是应急不是常态，它违反社会发展规律。新石器时代你擅长种地我精于养羊，大家互相交换一下，你能吃上羊肉我也能喝上粥，各自的需求就都满足了。那个时候大家就都知道了分工合作整体效率高。现在也就是在小公司一个人当2-3个人用，美其名曰成为全栈工程师，实际是"全干"工程师。在大厂更多是专精的工程师，这样才能推动每一个细分方向上做得更好。

 

我觉得全栈更多是倡导在业务需要的时候迎难直上的学习能力与责任担当能力，并不是说精通不同方向的技术。真有这样的超级牛，也不是一般公司请得起留得住的。每个技能树都点满，既能做刺客又能当坦克，既有高输出又能自动回血。。。。这是终极大boss堕拉攻么？结合自己的性格和能力，给自己做一次SWOT 分析，确定下自己的目标，然后培养自己的“一技之长”，先有深度再有广度是一条可行之路。看看大厂的高层基本也是这个路子。

 

上面是针对国内的私营公司。对于在国内的小外企则会有很大不同，因为很可能基础设施已经由国外的团队分担了部分职责，比如搭建好了配置完成了，本地只需要日常支持一下即可，流程相对也很规范，基本上可以做到专职专岗。国外对于数据、安全、合规特别重视，这样做能尽可能地把控这些方面。总体来说国内小外企相对国内私营小企业规范、制度、管理上都好很多。比如今年这次互联网员工「毕业生」和「输送型人才」很多都去了外企。

文章总结

小公司更需要的是多面手，哪里有火救哪里，随着公司的成长会慢慢正规起来。专业化职业化是一个公司成长的重要标志。小公司存在的问题很多，但是哪一个大公司不是从小公司成长起来的。只要有眼光，机会也是大大的。「搏一搏，单车变摩托」。如果没有更好的机会，踏实下心来做事情，把路一步一步走好，多学点知识和经验，为下一份好工作做准备也未尝不可。总之，哪里都需要踏实做事的人。

 

上面主要介绍了中小公司的研发效能相关的现状，大家可以对号入座一下，看看自己的公司是否处于这个状态。下面就会介绍二三线互联网公司的现状，这才是最精彩最有意思的部分，最后一篇会介绍一线大厂的一些八卦，走过路过请不要错过。

 

感谢点赞、转发和「在看」三连。关注这个公众号，了解最新的研发效能发展动向。欢迎加我微信（xueliuan）进入「DevOps研发效能」群讨论。