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

前端早早聊大会，前端成长的新起点，与掘金联合举办。加微信 codingdreamer 进大会专属内推群，赢在新的起跑线。前端

第十四届|前端成长晋升专场，8-29 即将直播，9 位讲师(蚂蚁金服/税友等)，点我上车👉 (报名地址)：node

本文是第三场讲师 - 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，这个过程当中最难的部分每每不是具体的代码实现，而是问题定位和立项推进，那今天就从个人视角，跟你们把基创建项这件事有哪些经验性方法作个分享。markdown

分享大纲

今天跟你们分享主要从人和项目这两个维度切进去，关于人和项目的关系，我一项秉持的态度是：不管当前的项目多难多糟糕，下一次项目均可以从新开始。前端工程师

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

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

作不作基建，作多少基建跟团队是什么关系，咱们来定位下基建的价值
如何寻找基建的机会，如何识别问题和场景，来基于摸底概括问题
站在人的角度，看选什么人来参与基建，从而提高基建氛围
在方法论这一侧，有哪些方式能够有助于我推进基建这件事情发生

最后是答疑，经过这样的几部分，来打消掉你们团队弱小时候如何作基建的疑虑。

作基建要知道的三件事

在正式分析前端与团队的关系前，先跟你们掏心窝说下我对于基建的见解：

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

第一个见解是：当咱们提到基建，就要想到三个词：

提效
降本
成长

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

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

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

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

第三个见解是：不管基建是解决开发体验的问题、研发效率问题，产品质量和稳定性的问题，不管它是小而美仍是大而全的，项目都须要有它肯定性的目标和推动的节奏，若是缺乏这些度量单位，就很难造成共识，若是缺乏共识，就势必会遭遇阻力。

作基建最头疼的三大难

听我讲完前面的三件事，相信你们脑海中就感觉了基建的难，事实是这样的，基建有不少方面的难，其中最难的这三部分：

判断与决策难

不管是做为前端 Leader，仍是前端同窗我的，要在表象的问题中定义价值，来决定作什么基建，为何作，当下要不要作，应该用什么方式作，以及须要谁来配合作，这件事是困难的。

共识与受权难

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

实现与推广难

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

之因此有这么难，有咱们主观的缘由，也有客观的缘由，最重要的是，咱们须要回到原点来看这些困难，从新认知它们。

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

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

定义 - 什么是基建

在你的团队里面，若是沉淀了几十个 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，这就会让咱们运行项目中，遇到更多的不肯定性，因此咱们会有监控系统，会有测试工具。

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

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

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

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

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

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

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

从问题点归类出发

这张截图是我刚带小菜团队的头几个月，所汇总的问题，有不少问题都是极为严重的线上故障，甚至对业务形成了很大的伤害的，好比业务方在一线焦急等待咱们功能上线后，他们好开始作促销，结果咱们整下午成天的打不出 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 年前的截图，是当时的真实写照，若是换到今天，我依然会用这种方式来作，只不过内容上可能会再微调罢了，若是把如何找机会作基建翻译一下，其实就是如何在团队中找痛点，找到痛点后，一路拔高最后识别哪些领域值得投入。

3、选人 - 如何提高团队基建氛围

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

提高基建氛围的方法

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

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

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

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

选拔基建的合适人选

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

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

基于这样的前提，咱们跑了一段时间后，也就专门成立了基建小组，对基建小组作了以下这些职责的定义，能够给你们参考一下：

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

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

4、推进 - 基建到底如何立项开发

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

有效的判断是受权的前提

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

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

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

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

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

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

数字 - 基建规划的灵魂

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

分析 - 基建规划的内核

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

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

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

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

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

不少时候，就是由于这样的决策依据不一样，致使同一件事，在你的眼中刻不容缓，在老板的眼中是有价值的但它是能见度更低更小一些的刻不容缓，最终没有让你动手去作。

里程碑 - 基建规划的皮囊

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

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

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

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

人头 - 基建规划的保障

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

大盘 - 基建规划的格局

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

总结 - 基建要从长考量

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

好的，个人分享就结束了，也但愿你们能够从个人分享中受益。

你们有问题能够在微信群中提问，我会选择 2 个问题进行解答，也能够加个人微信给我留言。

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

看完如有启发，就请点赞评论转发三连吧