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

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

第十四届|前端成长晋升专场，8-29 即将直播，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 和稳定的技术分享，以及团队主管对人员的动态调整，整个团队的基建氛围就能逐步逐步起来了。

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

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

有效的判断是授权的前提

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

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

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

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

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

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

数字 - 基建规划的灵魂

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

分析 - 基建规划的内核

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

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

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

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

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

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

里程碑 - 基建规划的皮囊

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

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

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

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

人头 - 基建规划的保障

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

大盘 - 基建规划的格局

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

总结 - 基建要从长考量

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

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

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

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

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