「这是我参与2022首次更文挑战的第1天，活动详情查看：2022首次更文挑战」

本文为作者在公司内部做“前端团队如何更好地支撑项目与赋能”技术分享的讲稿文字版，相关的公司信息、内部文件已屏蔽。 关于作者：现公司某BU的前端负责人。

本次分享的主题是“前端团队如何更好地支撑项目与赋能”，首先说一下为什么要做这个分享，或者说这个分享的定位在哪里。

第一，我在公司工作也有两年了，除了入职前半年左右参与了标品研发，此后主要是在项目上工作，经历过一些项目从开始到结束，也看到过一些好的东西和不好的东西，所以说可以在经验上做一个总结。

第二，现在零售家装BU上有一个现象，就是当新项目来了之后，却时常找不到合适的前端负责人，那么要怎么培养前端负责人呢？本次分享打算全面地介绍一个项目从开始到结束的主要环节，以及其中的前端工作重点，给即将成为或者想要成为前端负责人的前端同学一些方向。

本次分享的内容上会比较广一些，并且不会太具体，比如我们的SOP其实可以专门拉一个会去探讨；还有代码规范上可以举很多具体的例子来讲解一下；这些在后面会做更多具体的分享。

然后因为内容上讲的基本是我们日常工作要做的事情，这里就不会交代很多的前因后果，会直接开门见山地讲问题、说事情。

说到怎么支撑好项目，可以先参考我们公司的项目交付方法论，通过项目的全周期，还有整个交付团队要做的事情，来给我们前端团队做一些定位，并且明确其中要做的事情。

两个项目周期大致上是从项目立项到需求文档的产出，由于这两个周期在研发工作之前执行，所以在本次分享里面会归类为项目启动阶段。前端同学在里面有三个工作重点，第一个是参与需求调研；第二个是前端人天评估；第三个是前端技术架构的搭建。

由于这两个周期主要是做研发工作，所以这里会归类为项目研发阶段。在这里面，前端同学需要做好任务拆解和分配，以及做好进度管理和按照进度管理开发。

在这个周期里面，前端同学除了配合做好验收工作，还会参与项目复盘。因为项目复盘对于持续优化工作方法比较重要，所以本次分享会把复盘当作一个重点讲，直接归纳为项目复盘阶段。

在项目启动阶段，我们应该做些什么，来为后面的工作打好基础。

在研发阶段，我们应该怎么做，去保证项目研发顺利、按时交付。

这里讲一下项目复盘的意义，以及具体的复盘方法。

重点讲一下前端代码的规范与质量上的解决思路，以及现阶段的问题与解决。

介绍一下赋能措施，以及如何通过组织赋能，把前端团队的整体能力提升上来。

项目启动阶段主要做三件事件，第一个是参与需求调研；第二个是前端人天评估；简单总结下就是需要把前期的需求梳理清楚，以及做好成本控制；第二个是框架、基建的设计与搭建，如何把整个前端的技术架构做好。

我们先来看一下需求调研及人天评估，其实这部分主要是前端负责人要做的事情，但是前端同学都可以去了解下，因为以后每个同学都有可能去独立负责一个项目。

需求调研是研发工作的开始，前端同学需要配合客户、产品经理，做好前期的需求调研/评估，分析技术实现的可行性，为后续的研发工作打好基础。

如果有去客户现场的同学应该知道，我们要去跟客户谈、跟产品经理谈，把需求梳理清楚。当产品经理输出好对应需求文档、原型之后，技术同学才能投入到开发中，否则可能会有一些沟通效率上的损耗。比如说产品经理他自己觉得需求是没有问题的，但是在输出完原型之后，到了开发同学这里，开发同学又说实现不了，这样就会浪费了时间，影响了整个开发效率。

然后除了需求调研，还要作出一个人天评估。

人天评估也是项目中很关键的一环，直接关系到项目的盈利能力、交付周期保障，我们需要根据需求来制定合理的人天评估，并作出合理的前端资源投入计划，最终达到公司与客户双赢的结果。

就是说要去估算前端同学做这些需求，需要多少人天，需要投入多少人，来保证我们的成本是合理的，资源不会缺少，也不会浪费。

不过每个人的理解不太一样，做出来的东西也可能不一样。就比如一个需求，A觉得应该要这么做，B觉得要那样做；一个任务的人天评估，A觉得需要一个人天，但是B觉得需要三个人天。这时候就需要有一个标准的工作流程来指导，消除这种差异，目前需求调研SOP、人天评估SOP已经逐步完善起来了。

需求调研SOP主要包括以下内容：

此外，还有包含了一些调研计划和访谈记录的辅助表格。

其实看起来会更像是产品经理的操作手册，但是前端同学也会或多或少地参与进来，所以为了保证项目整体的交付质量，规范流程还是需要去强调起来。

人天评估SOP主要包括以下内容：

这里先分享一张前端研发流程闭环图，我们可以先看下前端研发的每个环节里面，可以做些什么，应该做些什么。

比如说：

这张流程图可能还不够完善，不过总的来说，已经足够启发我们将日常工作对标标准的流程时，研发环节上可以做哪些更好的调整。

一个好的前端架构对于项目来说是很重要的，有利于提升前端应用的可扩展性、可维护性、性能，还能提升开发效率。

在我们之前的项目里面，基本上是把标品项目复制下来改一改就可以了，很多时候是没有问题的，但是有时候项目环境、产品的差异性会比较大一些，就不能完全适用了。

这时候可以结合上面的研发流程闭环图，去思考框架是不是合理的、基础建设是不是完善的。比如说我之前参与过的一个长城汽车项目，没有Jenkins来做Web端的发布，这时候我们写了一套脚本工具来优化了发布流程；还有物料库上我们增加Taro UI，提升了小程序的开发效率；然后在数据Mock上也做了一些尝试，提升了前后端的联调效率。其实这里面还有不少可以去思路的点。

前面讲了项目启动阶段的几个工作重点，这里总结一下前期工作所需要的一些能力，需要软硬技能结合，让后面的工作更顺畅、更容易收到好结果。

软技能包括：

硬技能包括：

前期的工作做完后，会进到研发阶段，接下来讲一讲项目研发阶段主要做的事情。

第一个是任务拆解及分配；第二个是进度管理。

参考上面这张图，在需求原型出来之后，需要把每一个功能点拆分为前端的子任务。拆分的基本原则是分成页面编写、接口或逻辑处理两种类型，并且要保持一定的颗粒度，如果页面比较复杂，可以把里面的弹窗、子模块进一步拆分出来。需要尽可能地去保证每一项任务是单一的，这样会有利于我们后面追踪任务的进度。

在任务分配上，优先按照能力来分配，让每个人去做适应自己能力的任务，或者说这项任务对他来说，实现的难度不会太大，也不会太简单。

在进度管理上，一个主要的动作是要每天过上面这张进度表，去Review每项任务的开始时间、结束时间、进度、测试进度等等，是否在预期之中。

还有一些基本的原则：

因为任务的排期都是按照交付计划来定的，所以要尽量地去保证每一项任务都能按时完成，有阻塞时需要及时处理、及时支援。

反过来说，如果排期不合理、进度不跟进，就可能会导致交付延误、甚至交付失败，所以说我们需要加强进度管理。

当我们按照计划把项目交付了，然后项目结束了，是不是说之前的计划和执行都是过去式，对于以后的工作没有帮助了？

答案是不是的。

我们需要去检查，其中哪些事情是做得比较好的，哪些事情是做得不好的。比如代码规范和质量做得怎么样，有没有很多Bug，甚至有没有被客户投诉；还有比如进度管理做得怎么样，分配的任务有没有阻塞等等。

还需要去处理，好的方面应该去做一些强化和表彰，差的方面应该要去改进，循环迭代地去优化工作方法。

针对项目复盘流程，目前也梳理出了对应的SOP。

项目复盘SOP的基本内容如下：

代码的规范与质量也是项目中经常谈到的事情，退一步讲，如果我们没做好，比如说缺陷很多、性能上也不行，会导致整个项目的质量下降，甚至会让客户对我们的专业性、对我们公司失去信心，所以要重点讲一下代码规范与质量。

这里有两个小节，第一个是解决问题的一些思路；第二是现阶段的问题与解决。

辅助工具 比如在项目上配置的一些lint工具；还有Jenkins帮助我们规范部署流程、lint二次校验；以及Jest，一些测试工具等等。

规范文档 在公司wiki和微盘上都有一些，作为我们日常的学习，以及开发上的约束。

代码范式 我们会去强调标准的代码是什么样子的，并且通过工具生成一些标准且通用的代码；还有会沉淀一些标准的组件、工具方法，复用这些组件和方法，也能进一步提升代码规范。

Code Review 通过人工的方式去查找问题，从我入职以来看，code review在以前基本上是没有的，现在已经做得比较好了。

从这几种方式的优先级来看，会优先辅助工具，因为工具的自动或者半自动处理会比较省心省力，但是工具并不是万能的，所以规范文档以及代码范式也要加强起来。

最后一关是Code Review，通过人工去查找问题会相对费力一些，所以我们希望问题尽量不要流到Code Review这一关。

Code Review意识不高 这个其实是可以理解的，code review意识从没有到有，是要经历一个过程。解决办法是培养code review意识，做一些强调，加强过程管理，比如Review权限严格限制、禁止特殊方式绕过。

进度太赶，无心无力审核 有些项目一忙起来可能就是996，进度也很赶，对于审核代码可能会觉得无心无力，那么我们会推行2+1审核制，多人共同承担审核任务，多一双眼睛去发现问题，以及后续考虑组织代码评审。

问题反复出现，难以杜绝 比如：需要频繁的视觉还原，没有0px误差的追求；同样的方法到处复制粘贴...

这个也是真实存在的，同一个问题，同一个人，改了又改，那么我们怎么去处理呢？首先要善用工具，一些常规的问题其实工具比人更靠谱。

第二是加强规范宣讲，就是通过一些渠道去反复强调一下。

如果还是出现一些比较差的情况，可能就要关系到个人绩效上，也会影响到项目奖金的多少。

现有的规范较零散、不全面 主要是说我们的规范文档、辅助工具还不是很齐全，解决办法是要建立起完善的规范体系，后面赋能篇会再具体说一下。

规范贯彻不到位，Bug可能会像打地鼠游戏一样，一个Bug消失了，另一个又会冒头。

其实也有点像上边这只小熊一样，疲于处理各个地方的水管漏水，不能消停，所以说在规范上我们要多一些强调，多一些贯彻。

赋能是在团队管理里面经常提到的词汇，在技术管理里面同样适用，为了更好地提升团队能力，我们也需要把赋能措施抓起来。这里主要说的是组织赋能，那什么是组织赋能呢？我的理解是给团队赋予某种能力，并且是通过去中心化到扁平化的。

这里有两个小节，第一个是赋能措施，介绍一下有哪些赋能措施；第二个是介绍一下双周技术分享计划。

上面的“代码规范与质量”也大概介绍了这个事情，就是我们目前的规范文档有些零散、不成体系，微盘上放了一些，wiki上也放了一些，作者不一样，也没有比较统一的约定，而且很多是针对某个点去定一些规范，这样就有点类似一个叫“孤岛效应”说法。

那么会导致什么问题呢？开发同学可能在某些地方上找不到方向，要怎么写出规范的代码。甚至Review的同学也不知道某段代码是规范的，还是不规范的，这就导致了我们整体的规范水平得不到很好地提升。

所以需要从点、线、面到体的规范体系搭建，捡了西瓜，也不漏了芝麻，公司其实已经在做这件事了，预计今年上半年可以完成。

这里主要是给前端负责人，或者技术骨干做一些要求。在项目上，很多事情不是靠一两个人就能完成的，比如说Code Review不是只靠一个人就能把它抓好的，需要更多有能力、有意愿的同学参与进来，多一双眼睛去发现问题。还有比如核心模块研发也需要有更多的技术骨干来承担的，所以我们需要把这个培养计划抓起来，理想的情况下，事情来了，都有称职的人去把它做好。

这块会逐步在工作上落实，比如说一些表现优秀的前端同学，可能会让他去负责比较核心的模块，或者会放到一个项目的前端负责人位置上。

这块其实我们一直有在做，这里会再次强调下，或者后面会做一些激励措施以及规范性的探索。比如说我们一直有鼓励在微盘或wiki做一些沉淀和分享，技术开源可能还没有往前走多少，以后应该会再往前走一些。好处是什么呢？能够沉淀技术、提升内外影响力、并且有利于保持技术创新力。

这块跟我们的日常工作有很大的关系，现在主要从完善前端基础建设来讲，比如说公司在推行的低代码平台，能让前端同学的开发工作更加省时省力；还有我在好几个项目上看到过前端项目缺少自动构建部署的能力，每发一次版，都要去每个项目下面打一个包，然后一点点往服务器上丢，后来我们做了一个打包部署的脚本工具，优化了这个流程。

其实还有很多例子，比如说，能不能通过简单的配置就生成一些通用的页面，这个其实是可行的；甚至还能不能再智能一些，从设计师输出设计稿，就一键生成相关的代码，目前来说业界也是有一些实践和成果的。

前端工作是从0到1，再到工具化、工程化、最后智能化的一个发展历程，里面还有很多能够提升效率的点，这里就不一一列举了，后面我们会去做更多地识别，进一步地提升前端的工作效率。

先说一下现状是什么样子的吧，目前来说我们还是比较缺乏正式前端的技术分享和培训，可能几个月或半年左右，产研侧的同学会做一次分享或培训。今年开始，计划会做更多的技术分享和培训，目前也定了一个主要的计划，就是希望先在BU里面养成技术分享的习惯，下一节会再具体介绍一下。

总的来说，希望我们能保持向上学习、相互学习的习惯，以及有一个乐于学习、善于学习的氛围，更好地去提升技术能力，改善团队氛围。

介绍一下双周技术分享计划，为什么要做技术分享，上一节已经提到了，这节介绍一下比较粗的计划和具体的意义，后面还会把计划做得更完善一些。

首先，分享的范围是零售及家装BU的前端同学，计划是双周分享一次，也会看看前端同学的积极性，可能会更加频繁一些。

然后分享的具体目的和意义是什么呢？

对于个人来讲，会有利于技术能力的成长，比如说你有一种技术，我有一种技术，那么分享之后就有了两种技术，或者技术被迭代了，变得更好了。还有就是能够提升沟通表达能力、写作能力、自信心，毕竟我们程序员很多时候都是跟机器对话，更需要一些人与人之前的沟通、公众场合的表达，对写作能力也是有帮助，从而进一步提升我们的自信心。

对于团队来说，技术的碰撞可以丰富团队的技术栈，提升团队的研发能力，然后经过团队内部的沟通加强，就有利于形成学习氛围，沉淀团队文化。

如果大家有什么更好的建议都可以提出来，后面会考虑加到具体的计划里面。

最后分享一句话，“既要低头赶路，又要仰望星空”。

有时候我们在项目上很辛苦，低头赶路，加班加点，而且不断地从一个项目换到另一个项目，技术上用的好像也是那些，没有多大的区别。

这时候会我们产生疑问，一直这么下去，技术会有更好的进步吗？其实我以前也会有这个疑问，所以说，我们还需要抬头看路，能够知道和跟随业界的发展方向，并且争取走在前列。

前面讲的赋能措施会逐步解决这件事情，让我们的技术成长之路走得更稳、更远，也希望能跟大家一起见证，这些更好的转变。