阅读 1128

前端早早聊|芋头 - 如何带领前端架构团队突破价值困局

image.png

前端早早聊大会目标成为用得上,听得懂,抄得走的前端大会,计划 2020 年办 12 期,第一期 2020 年 1 月 11 日在杭州梦想小镇举办,报名 450 人,到场 230 人,话题聚焦在 「前端转管理」,来探讨大家常遇到的问题:

三五年后我大概率走上管理,之前该做什么准备呢?
老板提拔我带前端小组,我内心慌慌该怎么应对?
真有 35 岁天花板么,我要不要坚持走前端这条路?
技术编码做好多年,现在转型管理是对的选择么?
公司业务发展太快,我怎么才能带好 3 人到 50 人?
我老板懂不懂管理,我想看看别人公司怎么做的?
...

会议的五位讲师工作经验从 5 到 15 年不等,带的团队从 5 到 50 人不等,这些问题他们是如何处理的呢,一路怎么走来的呢?这 5 场干货的分享一定会带给大家完全不同的观察视角:

本文是第四场讲师 - 芋头的讲稿文字版,来看看他是如何讲的,观看视频请扫码文末二维码,回复 “早早聊第一期” 即可获得其他 4 篇文章、录播视频及 PPT 地址

本分享分为三部分:

  • 第一部分是讲三个团队价值突破的具体事例和思路;
  • 第二部分是回顾下团队不同阶段一些核心的问题;
  • 第三部分是回顾下过去团队遇到的一些核心困惑;

价值突破的具体事例和思路

管理三瞬 - 芋头.004.jpeg

首先是介绍下从前端到跨端到移动端的发展,跨端开发其实是前端打破固有边界的一个很好的突破口,也是降本增效的非常有效的手段,不过从前端到客户端的边界的跨越也不是一蹴而就的,虽然 RN 属于前端技术栈的领域,但是如何能够给出一个适合客户端平滑迁移的方案,考虑实际的演进场景是非常重要的,所以,我们当时做了很多为实现大范围迁移做的考虑。

管理三瞬 - 芋头.005.jpeg

所以,实际做事情的时候,我们的出发点一定要准确,不是一味的想着扩展前端开发职能,所有人都兴奋异常,跃跃欲试,结果当你把方案放在客户端面前的时候,人家一脸不情愿,即使公司层面强推,你也会成为客户端眼里抱怨的对象,“他们不光推翻我们的技术栈,还改变我们的工作方式,带来了非常高的学习成本,有没有真正提效都值得怀疑”。所以,需要考虑当时的场景,实际问题是什么?这个也决定了我们的方案需要做成什么样,例如我们的问题是需要解决业务大量投入客户端的问题,所以,我们的整个方案需要不断考虑开发对象是 native 开发的场景,从开发框架,到组件抹平,到发布集成的方式,有了这个思路,才为跨端开发的最终落地提供了好的基础。

管理三瞬 - 芋头.006.jpeg

团队通过跨端领域之后,我们来到了一个全新的时代,前端在移动端开发中发挥出来更大的价值,之后,我们开始涉足移动端架构的开发,这时候,我们遇到的挑战是扩展移动端开发的边界,在移动端架构方面,我们可以做些什么事情呢?之前我们主要是开发一些通用的模块和组件,这些更多是在服务开发,做一些开发方面的提效。后来我们开始思考,如果要扩展价值边界,可能不止是开发提效就够的,我们能不能做产品方面的赋能,甚至是业务方面的赋能,
事实是,可以。我们可以把 app 周边的一些基础设施产品化,把整个服务下沉,之后其他 app 就不需要再关注这部分的产品逻辑了,直接使用即可,例如 推送、闪屏、问题反馈、聊天、升级等,我们通过产品角度的通用化和下沉,可以赋能业务在产品方面快速组件自己的 app 业务。另外就是业务层面的赋能,当我们的整个移动端基础设施成熟之后,我们不光可以赋能自己的产品开发提效,还可以赋能行业公司,极少投入即可开发高性能、高可靠、高效的 app 业务。

管理三瞬 - 芋头.007.jpeg

这个是我们目前的一些基础能力沉淀,事实上,我们已经在尝试走最后一步,向行业公司输出整套解决方案,在内部新的业务构建方面,也有很好的快速构建的案例。

管理三瞬 - 芋头.008.jpeg

接下去,想分享的是我们在“端”的角色边界上更为激进的尝试,一个从底层机会做边界突破的尝试,那就是物联网方向的探索,事实上我们这块也是从业务出发慢慢孵化的,首先,是一些多媒体方面的沉淀,服务于一些营销、销售的创新场景,后来,发现这些场景需要更强的想象力,我们又尝试做了一些设备方面的事情,设备群控等新媒体业务,孵化了一些线下场馆的新型玩法业务,后来基于这些业务的沉淀,我们对底层的一些设备能力和在线能力做了强化,孵化出更底层的 SoucheOS 和 IoT 平台,为我们新业务的开展提供了更丰富的想象力。

管理三瞬 - 芋头.011.jpeg

接下去,是最后一个事情,Nodejs 方面的边界扩展,这方面,我们团队也是做得比较扎实的,不过这也需要一个过程,从最开始,尝试使用 Nodejs 介入一个完整的业务,当时团队对异构语言的排斥性不高,对基建的要求不高,这是 Nodejs 介入业务的一个很好的背景,另外这块业务是新业务,比较独立,从此我们 Nodejs 开始以服务端开发的角色介入了异构的战场。不过后续,当公司发展到一定的规模之后,异构会是一个比较严重的问题,除了人员的招聘,还有可能造成重复的基础设施建设,这时候我们的思路是下沉,整个 Nodejs 团队从业务开发下沉到基础服务的开发,因为基础服务对于异构更为友好,另外因为基础服务在成熟之后不会出现突然的需求暴增,人员方面也比较友好,在介入基础服务开发的过程中,我们在 Nodejs 的深度挖掘和基础设施积累方面也有了更多精力,这也造就了我们后续在基础设施方面有了完整的沉淀,基本上完成了 Nodejs 和 Java 的能力的同化,有了这些能力,以后大家至少不会在基建和语言能力上质疑你,这可以保证 Nodejs 承载更多的职责和更多样性的诉求。另外对于未来,我们还是需要探索更多可能性,不管是行业里流行的 serverless,还是尝试在业务开发中发挥价值,都是可以探索的方向。

团队不同阶段一些核心的问题

接下去,介绍下我在团队不同阶段曾经遇到的一些核心的问题,这些问题不一定有明确的解决方案,但是我想说的是,有时候可能你意识到问题是什么可能更重要,解决方案都是看场景的。

管理三瞬 - 芋头.013.jpeg

管理三瞬 - 芋头.014.jpeg

这是我大概总结的每个团队阶段遇到的一些核心问题。

管理三瞬 - 芋头.015.jpeg

当团队人数偏少,能力偏弱的时候,应该还是以业务支撑为主的,这时候团队的核心问题是怎么开始在繁杂的业务支撑中寻找主动权?从哪些方面入手?业务不允许投入大量时间做基建怎么办?大概可以提供一点思路,从前端三把剑开始,性能、体验、效率方面挖掘可以解决一些什么问题,不过这里需要注意千万不要脱离业务价值去造轮子。

管理三瞬 - 芋头.016.jpeg

当团队达到 20 人左右的时候,可能团队已经有一些基础积累和技术影响力了,但是有一天你可能会感觉团队出现了一些管理上的问题,开始可能你都不知道问题的关键是什么,就是感觉乱,感觉累。在这个时期,我看了一本管理的书籍,书籍里有一个观点深深触动了我,就是说,团队里出现的所有问题,最后的责任人都指向了你自己,业务方、团队、老板,所有人都盯上了你。其实,这就是团队的责任意识出现了问题,意识到这个问题之后,做一些针对性的改进,团队才能走上正轨。

管理三瞬 - 芋头.017.jpeg

当团队到达 40 人之后,团队为什么存在,为什么需要 40 个人,你的规划是什么,你的战略和队形是什么,这些就显得尤为重要了,另外就是人数多了之后,定规划、做事情、能力成长,都需要一定的套路和方法,需要引入一些固定的管理模式。

管理三瞬 - 芋头.018.jpeg

团队变的更大之后,需要思考的问题可能更需要贴近业务,贴近商业价值,贴近行业。

过去团队遇到的一些核心困惑

最后,再总结几个在团队发展过程中,我遇到过的一些核心挑战,具体的解决方案,不会展开细讲,只是希望大家可以产生一些共鸣,多做一些反思。

管理三瞬 - 芋头.020.jpeg

架构的定义是什么?我认为很多架构团队做的事情不一定是真的架构,用基础设施来形容可能更为合理,那真正的架构是什么?可能还是每个人有自己的理解,可能来自于业务,也可能来自于基础设施。
管理三瞬 - 芋头.021.jpeg

做基础设施建设或者创新能力建设,有时候耐得住寂寞也是一个很重要的品质,如果只着眼于当下的利益,很难完成长远的积累,另外就是思考规划的时候,需要看的长远,看到底层机会。
管理三瞬 - 芋头.022.jpeg

这个问题可能是很多团队都经常面临的问题,我们能做的一个是给大家清晰的目标,另外就是做好 backup 的队形准备,还有就是事情上可以有优先级的编排,不得已情况下及时收缩战线,保留核心输出。

今天我的分享准备告一段落了,讲的东西比较杂,希望能够给各位带来一些思路,感谢大家,有具体问题可以加微信细聊。

管理三瞬 - 芋头.001.jpeg

近两年 Scott 观察到前端行业已经完全进入竞争的深水区,各大小公司的前端 TL 刚刚上任,初带团队,针对前端工程师这个群体,应该怎么管人理事,搭台拿结果,帮带有成长,就成立了这个全国的前端技术主管学习交流群,在人的选用育留上互相学习成长,入群的门坎是你有实线或者虚线在带团队,请加 Scott 微信: codingdreamer 邀请入群,同时,未来的前端早早聊大会行程动态、资料下载请扫码下方的公众号:

2.png

1.png

看完若有启发,就点赞关注评论再来个转发吧👇

关注下面的标签,发现更多相似文章
评论