阅读 3390

第二届搞基建|Scott - 如何在人单力薄时立项推动基建

下期预告

前端早早聊大会目标成为用得上、听得懂、抄得走的技术大会,计划 2020 年办 >= 15 期,由前端早早聊与掘金联合举办,前端早早聊大会行程动态、录播视频/PPT/讲稿资料下载请关注 「前端早早聊」 公众号跟进。

你的支持,是早早聊办下去的唯一动力!

还想听哪方面的分享,直接加 Scott 微信: codingdreamer 提需求吧!


第十三届|前端搞构建专场,8-15 即将直播,9 位讲师(宋小菜|百度|政采云|腾讯|天猫精灵|蚂蚁|淘宝),👉报名地址


本文是第三场讲师 - Scott 的讲稿文字版,来听听他的观点,视频及 PPT 未来在公众号放出。

大家下午好,听完前面讲师的分享,相信大家结合自己的团队情况,一定会发现,其实在我的团队,也是有蛮多基建机会的,但是我每天都在做业务啊,腾不出人手做基建怎么办呢,特别是我的老板也不认同我拿出业务的时间做基建怎么办呢,那我们接下来就聊聊这个话题。

自我介绍

首先做个自我介绍,我早年在阿里巴巴做前端,当时团队已经在做基建的事情,无论是单页的 SPA 框架,还是组件化的初始化与上传工具,之后联合创立 Moveha|CR 并担任 CTO,这时候基建几乎都停滞了,一切都向业务低头,团队同学的成长也放缓了,之后到了宋小菜这家公司,负责大前端团队,从 6 到 20 人搭建团队,遇到了极大的研发压力,为了充分释放生产力,我们开始专注供应链大前端的跨端工具工程化,同时重视年轻工程师的潜力发掘与成长辅导,这三年下来在基建方面算是小有斩获,这就是我这三段职业生涯的情况。

除了这三段职业历程,其实我从 2012 年就开始接触编程教育领域了,兼职参与加拿大编程教育平台 UULearn  创业孵化,那时候开始用 Node.js 做页面的批量的生成,也是在这时候发现了 Node.js 对于前端工程师提效的重要性,后面也就在 2013 年入驻慕课网,推出 10 多门 Node.js 相关的课程,观看用户超过 50 万人次,从这些同学中得到了大量的提问,大部分都关于技术探索与成长,今年也正式成立了早早聊职业辅导社群,接触的前端工程师大家普遍反映做基建的面临的困难,这些都是从个人视角能感受到的。

另外对于团队的部分,特别是从横向的视角看的时候,有没有更系统化的思考和方法论呢,我觉得应该请更多讲师来参与讨论,于是这也导致了我发起第二届前端早早聊大会,也就有了今天下午的场子。

团队的基建成果

小菜的前端应用,目前有 60 个上下,既有 APP,也有 H5 和 PC,还有小程序,团队成立至今有 5 年,开始做基建到现在有 3 年,而团队的前端从初级、到高级和资深,进而到专家,他们的能力成长也都是在这三年的基建过程中完成的,有 3/4 的专家都是一路做基建起来的,或者说是大比重的参与了基建,无论是脚手架、报表工具、表单工具、监控全链路等等。

截至目前,我们也沉淀了大大小小 20 个基建的工具、系统或者平台,比如组件化就沉淀了将近 70 个,应用到 APP 和 H5 里面,这一路走完了基建的 0 到 1,这个过程中最难的部分往往不是具体的代码实现,而是问题定位和立项推动,那今天就从我的视角,跟大家把基建立项这件事有哪些经验性方法做个分享。

分享大纲

今天跟大家分享主要从人和项目这两个维度切进去,关于人和项目的关系,我一项秉持的态度是:无论当前的项目多难多糟糕,下一次项目都可以重新开始。

我们假设一个同学进入了一家新公司,或者转岗到一个新团队,切换到一个新业务线,接手了一个新项目,这都是一次全新的开始,无论是从技术、从基建、还是从个人的综合成长,都是一个新起点。 而按照上图的 A ~ F 的过程中,我们把它想象成为一个理想的模型,最开始你做项目是学习入门的阶段,是很难具备基建的前瞻性和实力的,可以专心做项目直到可以熟练的编程,一直到能单挑同类型的项目,这时候就可以独当一面的独立跟进项目了,基于这个基础,对于不同团队之间的配合关系,对于业务的理解,对于技术和项目关系的认知都比较深了,也就是业务上驾轻就熟的时候,就可以来考虑做提效降本的事情了,所谓提效降本,主要的抓手就是基建,从这个起点开始做基建是站在同类型业务和项目的视角,再往后就是站在团队的视角,解决团队普遍存在的共性问题,再往后就是解决跨部门跨事业部的问题,这时候基建就上升到了公司甚至是行业的视角,通过这样的路径,基建的功力才会逐年递增。

而到了意识层面和执行层面,我把今天分享的内容分为 4 部分:

  • 做不做基建,做多少基建跟团队是什么关系,我们来定位下基建的价值
  • 如何寻找基建的机会,如何识别问题和场景,来基于摸底归纳问题
  • 站在人的角度,看选什么人来参与基建,从而提升基建氛围
  • 在方法论这一侧,有哪些方式可以有助于我推动基建这件事情发生

最后是答疑,通过这样的几部分,来打消掉大家团队弱小时候如何做基建的疑虑。

做基建要知道的三件事

在正式分析前端与团队的关系前,先跟大家掏心窝说下我对于基建的看法:

基建的真正价值 提效降本与成长

第一个看法是:当我们提到基建,就要想到三个词:

  • 提效
  • 降本
  • 成长

提效降本的对象可以是人、业务、产品体验甚至是业务,成长则是我们所有从基建中受到的启发。落实到技术团队中,团队研发实力的强弱主要跟研发模式和工程师个人能力相关,而第三个最大的因素就是历年储备至今的基础设施完备程度,越强的基础设施,就带来越强的团队研发实力。

基建难点皆为现状 重点皆为管理

第二个看法是:基建的起点虽然是技术,但他的重点都是管理,要去管理人,管理钱和优先级,那么综合到行业、公司、组织、团队、小组和业务运营产品等所有内在外在的现实条件,有时候即便看到了基建价值,也未必有机会来实现,这就是基建的难,它就像一架架飞机一样,从起飞到降落不仅要满足很多条件,也要接受全程的监管。

基建再高大上 也要有目标与节奏

第三个看法是:无论基建是解决开发体验的问题、研发效率问题,产品质量和稳定性的问题,无论它是小而美还是大而全的,项目都需要有它确定性的目标和推进的节奏,如果缺少这些度量单位,就很难形成共识,如果缺少共识,就势必会遭遇阻力。

做基建最头疼的三大难

听我讲完前面的三件事,相信大家脑海中就感受了基建的难,事实是这样的,基建有很多方面的难,其中最难的这三部分:

判断与决策难

无论是作为前端 Leader,还是前端同学个人,要在表象的问题中定义价值,来决定做什么基建,为什么做,当下要不要做,应该用什么方式做,以及需要谁来配合做,这件事是困难的。

共识与授权难

每天加班都做不完业务,时间被占用的满满的,也招不到人甚至根本不给招人,想要升级电脑配置、购买地方服务和换高性能服务器都很难实现,我想好的想法提给老板,老板也不认同,更不愿意授权给我,想要跟这个组织体达成共识是困难的。

实现与推广难

团队根本没几个前端,大部分刚毕业不久,每天切切页面、调调接口、改改 Bug,没有利害的前端大佬带队,找不到未来团队基建规划的方向,不清楚技术上如何架构实现,缺少可以参考甚至抄来即用的技术方案,做出一些成果却很难推广,这件事也难。

之所以有这么难,有我们主观的原因,也有客观的原因,最重要的是,我们需要回到原点来看这些困难,重新认知它们。

一、定位 - 基建与前端团队的关系

越是人少的团队,也要深刻认识基建的价值和能力,以及它与团队的关系,

定义 - 什么是基建

在你的团队里面,如果沉淀了几十个 UI 的组件可以复用,这件事是不是基建呢,显然它是的,如果是基于组件搭建个业务模板市场呢,显然也是的,做个脚手架也是,做一个跨平台的小程序生成框架也是,甚至小到约定好我们 10 个前端的工程代码文件夹的大小写和变量的命名方式、不同分支之间合并的规范和写一份上线的自测文档,显然这也是技术设施和能力建设,我们就发现如图上的这些监控啊、插件啊、图表啊等等都算是基建。

结合上述内容,我对基建的定义:

  • 一切有利于研发效能提升的,直接或者间接助力于业务开展的的能力建设皆为基建

这就是我理解的广义的基建,它可能是一个技术方案,可能是几篇文档,可能是一场内部的项目培训,最终都是为了促成我们研发实力的提升和业务上的达成,而在研发实力部分就如我们前文提到的是研发方式、工程师能力和基础设施完备程度的综合体。

事实上,今天的我们能发现,基建早就无处不在了,只不过有些基建未必是我们亲手做的罢了,比如我们做了一个可视化搭建表单页面的平台,它底下可能组件部分的基建,这部分可能是蚂蚁金服帮我们做好的 Ant Design,或者是我们自己动手实现的组件,而我们自己做的组件,从初始化到测试到上线到托管,是依赖我们的 NPM 包管理工具,这个 NPM 又是社区给我们做好的基建,而 NPM 又是跑在 Node.js 上面的,那么这个 Node.js 又是 NPM 所依赖的基建设施了,如此种种,我们早已站到了整个行业大量的基建设施的肩膀上了,它可能是 Babel,可能是 Vue、React 可能是 Webpack,无论我们是否动手在做,我们早就身处整个行业的基建生态之中,我想聊到这里,大家对于什么是基建一定有了一个更明显的感受,它就在我们的身边就在我们的视野下,是无处不在的。

定位 - 团队的生命周期

左边这张图我是改造自蚂蚁金服玉伯大大的图,出处找不到了,大意就是前端团队会经历的几个重要阶段,或者叫这个团队成长的生命周期,我把它具象了一下:

  • 人肉时代

通常是在初创早期的前端团队,或者公司新业务线组建的团队,人丁稀少,缺少大牛,趁手的工具很少,协同的规范流程比较原始,以快速完成项目快速支撑业务进展为核心目标,其他很多事情都顾不上,代码也是快速的攒起来,往往一些技术债都是在这个阶段留下来的,这个时代的主要特征就是不仅缺乏基建的工具,也缺乏基建的意识,并且粗糙的研发模式导致线上的产品质量和体验是层次不齐的,也导致人员的流动性很大,很容易带着情绪做事。

同时处在这个阶段的团队负责人,通常是以点状的思维在规划团队成长,因为每天都在救火,无法脱离战场看大盘,三年前的小菜前端就是处在这个阶段,那时候我们不到 10 个人

  • 工具时代

这个阶段,团队已经储备了一定数量的很好用的基建设施,无论是文档规范、组件化,还是接口聚合,还是脚手架,大家的配合也趋于稳定,技术栈也基本统一,虽然开发资源还是很紧张,但是可以较好的支持高优先级的业务,勉强支撑并发的日常,开发体验有不少地方不够好,但整体的研发能力还算过关。

同时处在这个阶段的负责人,通常是以线状的思维来规划团队的研发节奏和资源比例,也在尝试着工程化方面的思考。现在我们的团队就处在这个阶段,差不多 20 个前端,20 个基建工具,支撑 60 个应用,平均一个人顶 2~3 个,有半只脚刚刚迈进工程化的时代。

  • 工程时代

这个阶段,前端的内部影响力已经很强了,无论是从产品交互的研究和业务驱动,还是跨部门视角的技术方案布道推广,甚至到业界的工程化经验输出,都有大量的战利品,最重要的是形成了完整的研发体系,从规范到项目开发到部署到监控整个体系是成建制的形成,大部分团队成员都具备了很强的业务意识和研发能力,整体的开发体验也很不错,业务上大部分非高复杂度的项目都能较好的支持解决。这是目前市面上我们已知的一线互联网大厂的部分团队达到的阶段,非一二线互联网大厂里面,如今达到这个阶段,据我所知是少之又少,这也是我们小菜前端未来 2 年要奋斗的方向,今天来分享的讲师,也都处在这个时代的早期或者中期,未来的路依然很长。

  • 智能时代

这个阶段,可视化搭建、智能搭建与生成都在业务中有了很深入的应用,比如阿里双十一的 Banner 生成工具,创意视频生成工具、设计稿转页面的生成工具等等,给设计和产品带来了巨大的生产力解放,也给公司节省了巨大的研发资源,整个工程化的土壤已经非常成熟,技术生态也非常丰富,很多方面都在做整个行业很少听闻的探索和尝试,据我说知,目前也只有蚂蚁体验技术部和淘系的工程化相关团队,已经有半只脚踏进来到这个阶段,其他的团队还都在工程化逼近智能化的路上,这也是我们前端行业截至目前能看到的那个最远的地方,值得我们所有人努力。

  • 小菜的几个小阶段

我们团队发展了 5 年,从人肉时代进入到了工具时代,目前正在迈向工程化时代,中间经历了几次里程碑事件:

  • 第一次是 2016 年,把原生语言的 APP 开发全部转向 RN 开发,虽然损失了一部分的性能和体验,但直接解锁了前端的开发效率,让我们可以用极低的人力成本,同时支撑好几款 APP 的并行开发,只不过当时为了快也造成了大量的团队问题,无论是人的还是事儿的
  • 第二次是 2017 年拥抱 Node.js,鼓励大部分同学大面积的使用 Node.js 造轮子,特别是打包推包部署热更新等一条龙的建设,极大的降低了发版的出错率也极大的提高了上线发布的效率,让前端的能力从前端打到了后端,也就是具备了最基础的全栈能力
  • 第三次是 2018 年疯狂的尝试造各种提效的轮子,无论是 APP 研发一条龙,还是 PC/H5 的部署,还是工程框架和报表可视化,几乎全面开发,整个重塑了小菜前端的研发生态,我们也是从这一年才开始走出来分享的
  • 第四次是 2019 年把所有端上的技术栈统一,APP 用一套固定版本的工程框架,PC/H5/小程序都是,包括 Node.js,也放弃了从前裸写的 Koa/Thinkjs 和 Express,全面转向基于 Eggjs 封装的企业内部服务框架,同时也把所有的端做了收敛统一,这个目前还在开发中,还没有完成,至于 2020 年,我们也充满期待,希望天下一统后,就走向更丰富生态的工程化阶段。

这个话题我用了比较大的篇幅,主要是让大家感受到基建对于前端团队往前面大踏步迭代的重要性,没有基建,团队是不可能向前跃迁的,也让大家感知到基建可以助力团队成长的程度,前面是星辰大海等着我们。

定位 - 基建与团队的关系

我把上面提到的四个阶段,以及基建跟我们团队结合后所发酵的结果,提炼出来这三个观点,来形容基建和团队的关系:

基建是团队前进的车轮 要稳

前端喜欢造轮子,其实轮子就是我理解的基建,好的轮子一定会让我们更快,但还有一个很重要的考量其实是到底稳不稳,如果装了 4 个不同尺寸不同材质的轮子,项目中既有 Vue,又有 jQuery,又有 React,这就会让我们运行项目中,遇到更多的不确定性,所以我们会有监控系统,会有测试工具。

基建是团队助力的引擎 要快

快是研发实力最直观的一个体现,我们做基建就是为了让项目开发的更快,所以有自动化构建工具,会有页面搭建工具,越是到关键项目的时候,越是考验我们基建能力强弱的时候。

基建是人才的练兵场 让脱困更强

都说工程师是公司最宝贵也是最昂贵的资产,那么既然如此就要人尽其用,发挥最大的主观能动性,就应该有尽可能多的利于工程师成长的机会被创造出来,然后通过工程师个人实力的增强,来带动整个团队研发实力的增强,所以我们会有培训,会有文档的传承,会有帮带,也会有做基础架构的同学。

当然用一台赛车来形容基建还是不够严谨的,我们用武装二字或许更为合适,通过对团队的武装和再造来达到所谓又快又稳又强的目标。

二、摸底 - 问题与场景的识别方法

当我们了解到基建对于团队的必要性和重要性,以及基建对于团队不同发展阶段所能发酵出来的力量,我们就要面临下一个问题,如何在团队中找到基建的机会呢,有什么方法可以把这种基建机会定位出来呢。

从问题点归类出发

这张截图是我刚带小菜团队的头几个月,所汇总的问题,有很多问题都是极为严重的线上故障,甚至对业务造成了很大的伤害的,比如业务方在一线焦急等待我们功能上线后,他们好开始做促销,结果我们整下午整天的打不出 APP 的安装包,原因是这个同学的电脑环境不小心做了调整,然后再换一个人的电脑打包,再打不出来,再换一个人,结果打出的包代码居然有了问题,就这样一而再再而三的把时间给耗费过去了,关键是类似的问题层出不穷,隔两天来一次隔两天来一次,团队所有人的头都很大,业务方也炸了,当时面对这种问题,我的办法就是图上这种,在解决问题的时候,把问题都记录下来,并且对他们归来,主要按照 技能、合作、工具、规范、职业性、团队稳定性、业务理解等维度,跑了一段时间后,基本上问题也都经历一遍了,这个表格也就沉淀出来了,再结合当时的开发流程,就会有初步的判断:这些虽然看上去都是单点问题,但背后的原因都是有多方关联的,并不是单点,这时候必须放弃掉很多问题,挑重点问题解决。

摸底 - 问题现场的还原

要形成主要问题的判断,就必须回到当时的现场,回到现场的方式就是对问题做复盘,在复盘中总结规律,比如我们为什么打包出问题呢,就把这个流程整理出来,比如宋小福这个内部 CRM APP 要打一个 iOS 的链接测试环境的,不进行热更新功能的带 Debug 功能的安装包,如果这个包是 B 同学打出来的,那么它可能就是一个独一无二的包,又因为每个同学本地的 Node 版本和 NPM 版本不同,会导致包所依赖的语义化的其它包版本会有出入,比如有的是 Yarn,有的是旧的 NPM,有的是新的 NPM,那么在工程的 node_modules 中,代码就有了差异性,这再叠加上 XCode/Gradle/本地证书/配置文件/热更新开关等诸多变量,加上仓库分支的合并甚至是人肉上传包的方式等可能出错的环节,会导致用户所收到的安装包都是独一无二的。

如果再把平台、环境、热更新都考虑起来,就这一个宋小福 APP 就能打出 8 个不同的包,如果带上 Debug 开关,那就是 16 个包,如果加上每个同学自己本地环境的差异性,就变成了 64 个包,如果把 5 个 APP 都算是,那就是超过 300 个包要管理,当然实际情况并不会真打出来这么多包,只是这么多的可能性就指数倍的放大了打包发包出错的概率,所以还原了这个场景,问题的严重性就出来了,这就是当下我们首先要解决的问题,并且一定不是靠人肉解决,因为三令五申的人肉约束已经证实没有效果。

路径 - 从现场回到方案终局

定位到了问题,还原了现场,就要有一个理想的终局方案,这个图是我们当初所达成的共识,针对不同类型的 APP 制定不同的发布策略,这是我们理想中的方案,或者叫做是我们脑子中的想法,它能不能实现,还要有一个很重要的东西保障,那就是制度面,或者叫做流程面和权限面,也就是具体到人。

路径 - 从方案回到人头流程

有了问题、原因和期望的终局,我们就要把人这个因素加进去,来在流程上做一些节点的把控,通过动作隔离,无论它是物理的还是软件系统的还是口头流程的,来形成权限的收敛和责任到人的指派,这样整个团队所有人都在这一层达成了共识,将来权限放开不放开是另外一回事,当下我们就要有这样的流程来解决问题,从而达到我们脑子中想要的那个方案终局,具体到打包这件事,就是有了分支拉包、推包、初审、二审、驳回、发布和安装同步等关键的节点切割,同时也把这件事收敛到了唯一的一台公共服务器上去做,不再有任何导致环境变化的人为因素切入,所有人都在这个中心化的系统上协作,这个问题就得到了极大的解决。

路径 - 从流程到团队基本面

虽然我们做了一个打包、推包和发包的系统,问题都得到了解决,但这只是线状的把问题解决了,还有更多其他的问题要考虑进来,比如开发阶段的组件化、代码规范和仓库规范,比如运维阶段的异常收集、分析、指派和产品使用数据的看板,而这里看上去是问题,恰恰也是基建可以发力的机会。

摸底:点线面到体系化诊断

刚才我们从打包问题一路引申到了团队这个层面,是想给大家引出这句话:从点状的问题,摸到线状的流程,再来到团队的基本问题面,最终给出你的更立体的诊断结果,到了这一步,我们就能发现团队中隐藏的诸多问题,这些诸多问题就意味着诸多机会,这些机会或许就可以用基建的手段来解决,所以我们回到刚才提出的问题:如何在团队中找到基建的机会呢?这就是我推荐使用的方法,当你表述问题的时候,其实你也能表述出来更有高度的决策因子,而有时候打动别人的都是这些相关因素,是因为让别人从这样的思考方式上就对你建立了信任感,至少是相信。

这张图是当时团队诊断出来的基本面问题,其中在团队规范和工具基建这两个方向上是最制约团队的根本病灶,那就从这两个地方下手,其他地方也在选择时机用不同力度来下手。

基于点线面体来定夺做事节奏

下手的方式就是有节奏的解决问题,这个节奏就是基于这个点线面体的方法而顶多出来的,比如职业宣导是长期的一直在做的,架构调整和打包则是花大把时间重点做的,同时还给业务方做了一些提效工具给他们当点心,获得他们的好感和认同感,这张图也是 3 年前的截图,是当时的真实写照,如果换到今天,我依然会用这种方式来做,只不过内容上可能会再微调罢了,如果把如何找机会做基建翻译一下,其实就是如何在团队中找痛点,找到痛点后,一路拔高最后识别哪些领域值得投入。

三、选人 - 如何提升团队基建氛围

刚才把团队问题的识别回顾后,相信大家脑海中已经记住了基建是迈面向的问题的,而问题是有不同的思考视角的,这个方法套到我的团队中,能成立么,我们首先要回答这样一个问题,我团队中有这样的人或者这样的气氛么,如果这个想法对业务没帮助对成长没帮助,那跟不做又有什么区别呢,所以我们得先聊下你的团队中,如果没有适合做基建的氛围,该怎么做呢?

提升基建氛围的方法

并不是每一个工程师都充满基建热情的,也有同学长期做业务并擅长做业务,反而会造就对基建缺少热情,这种时候如何改善团队中的基建氛围呢,说是技术氛围也是合适的,我总结下来,最简单有效的就这三个:

第一种,是以周为维度的代码 Review,相对高频,有三个原则、最长最多和最小,最长的 Review 间隔不能超过 1 周,不要长时间停止这件事,最多则是鼓励尽可能多的人参与,让大家在代码这个层面,从规范、设计和实现侧有更多的输入,尽可能多的达成共识,至于最小,则是 Review 的对象颗粒度保持最小原则,可以是一个一个函数接口入参的设计,可以是一个列表优化的小算法,可以是一个已发生的代码 Bug,细化到点,尽可能的聚焦。

第二种,是以月为维度的技术分享,相对中频,每个月都要发生一次技术分享的行为,内容不必局限,但一定要有关于基建部分的共创和分享,这里除了达成大家的充分共识,也是极好的技术布道的机会和技术学习交流的机会,也是体现基建价值的机会,有没有价值,也要让真正的用户也就是你的队友来评判,避免成为自己 YY 的作品。

第三种,是以季度为维度的职责调整,相对低频,每个季度内要对做业务的同学,做基建的同学,无论是人员安排,还是手上业务/技术基建的比例关系上,都做一些微调,让技术成长慢的同学可以多参与一些基建工作,让基建方面做很久的同学来一线再体验体验业务,带回去业务上新的思考,甚至可以成立虚拟的基建小组,来设定负责人和参与人,以项目的形式来推动,而如何把最值得重度培养的同学放到关键位置上,一定要有选拔标准,这个选拔标准就是能力和意愿,再具体点,就是技术潜力、兴趣度和做事的执行力。

选拔基建的合适人选

前文提到的代码 RV、技术分享和职责调整,背后都是一个个同学的参与,而有难度有价值部分的基建工作交给谁来做,这是一个很值得思考的问题,并不是所有同学都适合来做基建的,拔苗助长的方式也可能大大打击同学自信心,甚至也根本做不出一个被团队认可的基建工具的,到底谁是最符合的,在我们团队,选拔的门槛有这三个,缺一不可:

  • 第一个,技术嗅觉灵敏,对行业技术有感知,对技术对业务的价值有感知,并且在特定领域有一定的造诣
  • 第二个,有较强的问题解决能力和创新能力,最关键的是执行力是爆棚的,是团队中最拼最能拿结果的人
  • 第三个,责任心和胸怀,能站在团队视角思考问题,对其他工程师有同理心,除了自我提升还能他人提升

基于这样的前提,我们跑了一段时间后,也就专门成立了基建小组,对基建小组做了如下这些职责的定义,可以给大家参考一下:

  • 首先,基建小组就是团队的救火队长,别人搞不定的问题,到了基建小组这里,都要能补位和攻坚
  • 其次,基建小组就是团队的排雷先锋,无论多超前的技术栈,他们可以最快的消化掉核心的理念,并在小领域尝试后,把经验和能力输出给团队,形式不限,可能是闲聊沟通,可能是技术分享,可能是一份文档或者一段代码
  • 再次,基建小组就是团队的兵工科长,要为团队的整个基础设施的大头负责,每一季度每一年,都能不断的升级装备,并武装到团队
  • 最后,基建小组也是团队的布道使徒,这一点看似简单实则很难,目前小菜我们做的也不是特别好,很多同学比较谦虚和腼腆,不太好意思上台来讲,所以大家看到社区里面,反而是我出来的次数多,这种状态是不太健康的

有了这样的选拔标准和职责划分,做业务的同学也能理解做基建的同学他的价值,反过来亦然,再加上高频的代码 Review 和稳定的技术分享,以及团队主管对人员的动态调整,整个团队的基建氛围就能逐步逐步起来了。

image.png

四、推动 - 基建到底如何立项开发

前面我们把基建的价值弄清楚了,团队痛点和基建机会点寻找的方法也了解,以及整个团队的基建氛围改善方式我们也了解了,那就剩下最后一个问题了,如果具体到某个基建项目上,如何促成这件事在团队中正式立项开发呢,有什么简单的规律,可以帮助我说服老板,说服产品业务,包括我身边的同学,来认同我的想法最终划出来专门的人力,哪怕是加班加点,至少是有一个机会来实践开发呢?那我把前年和去年我自己尝试过的方法论,分享给大家。

image.png

有效的判断是授权的前提

其实当你跟老板说,我们的脚手架很旧了需要升级,我们的 APP 版本很老了需要重构,虽然你提供了解决方案,但这些听到老板的耳朵里,都是想法,而不是可执行的方案,因为处在不同的团队层级,所看到问题的象限和影响点是有很大不同的,如果要启动比如一个 APP 的重构优化,那这里有一些准备工作要做的:

  • 首先,团队这几年下来的技术现状你要摸底清楚,整个团队有多少厉害的人,整体大家负责了哪些项目,这些项目中有哪些是技术债没还的,如果对某方向某领域招人,难度高不高,会不会要做某件个基建,发现连续半年都招不到合适的人
  • 其次,是要摸底这个行业中同类型公司团队和技术栈,别人的实践经验,走过哪些弯路,有没有可以花钱买过来或者半自研拎过来的方案先用起来,有没有这方面的成功案例可以吸取经验,避免自己从 0 摸索造轮子
  • 再次,是根据我前面分享的问题识别方法,列出来完整的问题清单归纳总结,看到底对团队当下和未来一段时间,最痛的痛点是什么,制约了我们哪些方面,对业务是否有影响
  • 最后,要对团队的组织架构,分工方式,考核制度都有一个理解,公司眼下是生死存亡之刻,还是全面规模化的时刻,是已盈利还是在小心的烧钱,有没有可能让我们具备基建的业务土壤、窗口期包括物质条件

基于这 4 个摸底,我们再来做这个基建价值和做事节奏,所谓判断与规划,判断在当下的现状中,当前的场景中,重构这个 APP 的性价比高不高,最终谁是最大受益者,受益多大,能不能通过数字反应出来,或者不重构带来的问题有哪些,影响有多大,为什么会影响,有没有数字和案例可以反应出来,如果认为这件事费做不可了,那么就要有一个规划,做这件事什么时候启动,如何启动,需要谁配合做,分几期来做,每一期可量化的结果是什么,所谓做事章法。

只有这些判断你这里都想透了,当你在跟你老板说的时候,才不会仅仅是一个想法,这些都是基本的储备工作,可以写到 PPT 上,可以存到脑子里。

image.png

到底有哪些参考的立项指标

就算是心中有轮廓了,但还是没有信心说服老板对不对,还是得有一些更具体的看得到的东西出来,跟大家分享 7 个我认为有效的立项指标,这几个你不要遗漏,统统做一遍,我相信老板是很难否认掉你的方案了,除非是有其他关键因素,特别是不可抗力因素的影响,这几个立项指标你认真做的话,其实不难做的,做这个基建要有这七个,分别是数字、分析、优先级、里程碑、对比、大盘和到人头的职责,也是也就是大家所熟悉的 Smart 原则的扩展版。

数字 - 基建规划的灵魂

首先我们要有数字,无论是你拿一个业务的结果,或者线上异常量的结果,还是调研 5 个前端后的调查分析结果,里面一定要有数字,这是我在 1 年前做的一次反应用户转化率变低原因的分析,想要启动一个用户登录过程的基建工作,来前后端配合降低用户访问小程序的时长,并最大程度让用户完成注册动作,可以看到我把每一周数据背后,产品上技术上有什么发布也都标注上来了,有了这个数字指标,所有人都能意识到这里出问题了。

分析 - 基建规划的内核

规划成立不成立,要看背后的逻辑是不是成立的,这是我针对刚才的问题,所提出的解决方案,里面有技术的,有交互的也有基建的,比如首页数据静态化的服务,在这个里面,要把问题再拆分成点,每一个点都要有它完全成立的推导逻辑和解决后的目标,通过这个,所有人都能理解为什么要做这些些事情,这些事情背后的意义是什么。

优先级 - 基建规划的紧迫性

通常一个团队的问题,都是两位数以上的,要从这里面识别出最有价值的痛点,往往是管理者的决策视角,而作为团队成员,要说服老板认可你提出的一个新的建议,你就要设身处地的来跟老板沟通,商定出一个衡量优先级的决策标准,有些事要做,但往往不是当下来做,根据这个决策标准来决定每一个基建的紧迫程度,至于特殊的案例就特殊处理,如果每一个案例都是特殊的,那这个团队的研发模式一定是出了重大的危机。

我这里把衡量基建紧迫程度分成两种权重

  • 最高优先级的是跟业务相关,无论是伤害、制约还是影响业务,这些事情背后的基建工作都是优先级较高的,比如 APP 中框架依赖的包版本不一致会导致 APP 白屏闪退,那么这种就是直接伤害到业务,它的背后一定要尽快启动基建解决
  • 较高优先级则是关乎开发效率、体验、工程师的成长和维护成本等,越往后权重越低,同时命中的影响点越多,那么这个基建的紧迫性也越高

很多时候,就是因为这样的决策依据不同,导致同一件事,在你的眼中刻不容缓,在老板的眼中是有价值的但它是能见度更低更小一些的刻不容缓,最终没有让你动手去做。

里程碑 - 基建规划的皮囊

当你要启动一个基建的时候,寥寥几句是很难让别人感知到你到底是要做个什么东西出来,到底要做多久,到底要用到多少开发资源,到底解决的最大痛点是什么,那么这里面有个很重要的指标,就是里程碑,当有了里程碑,这个基建就有了阶段,有了阶段就有了能看见的成果距离:当下有多远,我们等不等得起?这也是我们日常工作中最熟悉的部分了,因为基建也是项目,大家要用项目的视角来看。

对比 - 基建规划合理性的校验

人天然对于对比有着更强的感知力,无论当前是规划前、规划中还是规划后,针对这个基建方案,都可以对比组,可以是业界的方案,可以是其他部门前端的方案,可以是自己团队从前的方案,通过对比来彰显当前这个基建规划的合理性和更量化的指标,就算这个指标不是足够严谨,至少它带来的价值是可感知的,这张图是我在  2018 年述职时给老板看的对比 2017 年,在基建链路上建设所拿到的结果,也正是这张图,让我进入这家公司的第一年就获得了晋升的门票。

除了对比可以让价值凸显外,更重要的是通过对比,你有一个很好的证据在手,这是你下一次启动新的基建的新起点,这个成功过的经验可以进一步削减你未来做基建的阻力。

人头  - 基建规划的保障

这张图我把人的名字拿掉了,可以把它看做是一个挑战排行榜,所有参与基建的同学,都身挑不同的挑战,不同的挑战背后有不同的价值和难度,有了这样的价值和挑战对应关系,每个人都有了更具体的目标,包括跟你配合做这件事的人,一定要落实到人头。

大盘 - 基建规划的格局

这是大家从一开始工作就可以训练的能力,所谓更有高度的技术视野,这是我去年做过的一张图,用来描述在 80 人的技术团队中,20 个前端自己的业务是什么,20 号人除了对业务负责,还对什么负责,通过整理这样的基建大盘,所有同学都放到了一盘棋中,每一个领域内的每一个建设都有它的进度,每个进度背后都有特定的同学在负责,这时候整个团队的基建就是有活力,如果你可以形成这样的大盘意识,不需要这么详细,你去说服老板、合作方和同事的阻力都将会大幅的降低了。

总结 - 基建要从长考量

到这里我的分享就告一段落了,不知道刚才所分享的案例、方法、视角对大家帮助有多大,是不是可以让大家在基建三难,也就是判断决策、共识授权 、实现推广这里感觉到其实并没有那么难了,只是缺少这样可参考的经验而已,最后再跟一个小小的总结和建议:基建往往是长周期的事情,是无止境的,任何时候要动作做之前,都要充分考虑成本和受益,要有很强的成本意识,同时要把基建的终极目标落实在两件事情上,一个是对业务的帮助,到底能解决多少业务痛点,能带来多少协同上的效率提升,另一个就是对团队有提升,能跟团队同学打成多大程度的共识,能促成团队多少比例同学参与交流分享,业务和团队就是做基建的定海神针,所有人都会从中受益。

好的,我的分享就结束了,也希望大家可以从我的分享中受益。

大家有问题可以在微信群中提问,我会选择 2 个问题进行解答,也可以加我的微信给我留言。

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

看完若有启发,就请点赞评论转发三连吧