第940期关于前端团队架构的思考

Posted 2021-04-30 前端早读课

前言

前端团队人多人少，分分合合总有必然的演变。文末的建议不错，对于深耕于业务线的你应该有所激励。今日早读文章来自凹凸实验室 @LV 主唱大人的授权分享。

正文从这开始~

大厂的前端团队，一般会有专门服务于业务的小组（业务前端组），以及专注于前端技术研究的小组（研发前端组或前端架构组）。凹凸实验室自然也不例外，我们有4个业务前端组，1个研发前端组。

但实际运作过程中我们发现，即使有这样的架构分工，业务前端组也还会有自己的研发人员或具有研发特长的童鞋，业务中产生的前端研发需求往往也因此会交给这部分人做处理，在各业务组内部闭环。这种情况是情有可原的，业务前端组出现的研发需求，直接让本小组具有研发能力的人去处理，是最高效的处理办法，因为他们更懂业务，在同一个组内也更有利于沟通。

如果让几个业务组的所有前端研发需求都提给研发前端组，然后按优先级进行统筹排队处理，反倒变成是低效的了。研发前端组的同学在处理业务小组提出的研发需求的时候，还需要去了解业务，否则期望做A，交付的可能是A-，甚至是B或C。还有一种情况，当业务组的研发需求集中爆发的时候，研发前端组的童鞋不一定忙的过来。

看到这里，我们心里会有一个疑问？前端团队拆分独立的所谓的研发前端组到底有没有意义？

在回答这个问题之前，我们先要去回答另外一个问题：我们在建设一个具有一定规模的前端团队的时候，其目的是否仅仅是服务好业务？

我想绝大多数的人会回答「否」。这个就好比一个人活着不能止于「有食可进有衣可穿」这种基础的物质条件，团队也同样有「精神层面」的内涵，具体如：

• 影响力

• 创新力

• 技术视野

这些「精神层面」的东西看似很虚，但实际上会以另外一些形式正向的反馈给团队，间接影响团队服务业务的过程甚至结果。

建设团队在公司内外的影响力，可以营造团队的专业口碑，吸引优秀的专业人才主动加盟，而优秀的人才对于团队高效处理业务需求或研发需求的能力具有促进作用。

国内前端团队的技术或产品创新力（或微创新）尽管这两年有所改进，但依然是短板，至少是我们凹凸实验室团队的短板，这是一个值得深思的问题。为什么我们的团队很难产出能引领业界某个技术方向的标准，前如JQuery、Angular，后如React、VueJS。这或多或少与团队的创新能力有关联。

技术视野如同创新能力一样，我们大多数人忙于业务，往往停留在用好现有技术的阶段，难以抽出固定的时间主动去了解前端专业领域的前沿技术，思考其他领域（如日趋火爆的AI）的前沿技术对前端领域、所在业务的影响。

我们再回过头去尝试回答「前端团队拆分独立的研发前端组到底有没有意义？」，心里是不是有了一些清晰的思路呢。

既然拆分了业务与研发，而业务小组中又具备满足其前端研发需求的能力，那末寄望研发前端组服务于所有的业务组，并期望研发前端组的输出能完美落实到业务中去是不是一种乌托邦的理想？

研发小组在前端部门中的定位，是不是应当类似创意设计组在设计部门中的定位一样，可以服务于但不强绑业务，把方向聚焦于团队『精神层面』的建设：影响力、创新力与视野？

希望我可以在一年半载之后回来给一个答案。

作为老司机，最后一段话送给所有同学：

造车的与开车的具有同样的价值，不管是在业务组，还是在研发组，只要选择了适合自己的方向并为之努力，便可以成为这个行业中的佼佼者。

业务组的同学，可专注于业务处理效能和服务口碑；而研发组的同学，做的事情必然没有业务组务实，则应拒绝轻浮保持耐性，努力成为某个技术领域的先锋及布道者，在必要的时候引领业务组的技术方向，为提升个人与团队的影响力、创新能力与视野而不懈努力。

最后，@早读君心想还有一个方案，把前端基础组作为一个虚拟的组织存在，他们的成员都来自于具体业务线，在时间上做一定的抽取，这样既懂业务，又能在做基础服务。

为你推荐：

关于本文

原文：https://zhuanlan.zhihu.com/p/26962085