「这是我参与2022首次更文挑战的第1天，活动详情查看：2022首次更文挑战」
本文为作者在公司内部做“前端团队如何更好地支撑项目与赋能”技术分享的讲稿文字版，相关的公司信息、内部文件已屏蔽。
关于作者：现公司某BU的前端负责人。
前言
本次分享的主题是“前端团队如何更好地支撑项目与赋能”，首先说一下为什么要做这个分享，或者说这个分享的定位在哪里。
第一，我在公司工作也有两年了，除了入职前半年左右参与了标品研发，此后主要是在项目上工作，经历过一些项目从开始到结束，也看到过一些好的东西和不好的东西，所以说可以在经验上做一个总结。
第二，现在零售家装BU上有一个现象，就是当新项目来了之后，却时常找不到合适的前端负责人，那么要怎么培养前端负责人呢？本次分享打算全面地介绍一个项目从开始到结束的主要环节，以及其中的前端工作重点，给即将成为或者想要成为前端负责人的前端同学一些方向。
本次分享的内容上会比较广一些，并且不会太具体，比如我们的SOP其实可以专门拉一个会去探讨；还有代码规范上可以举很多具体的例子来讲解一下；这些在后面会做更多具体的分享。
然后因为内容上讲的基本是我们日常工作要做的事情，这里就不会交代很多的前因后果，会直接开门见山地讲问题、说事情。
项目交付方法论框架
说到怎么支撑好项目，可以先参考我们公司的项目交付方法论，通过项目的全周期，还有整个交付团队要做的事情，来给我们前端团队做一些定位，并且明确其中要做的事情。
项目启动跟蓝图规划
两个项目周期大致上是从项目立项到需求文档的产出，由于这两个周期在研发工作之前执行，所以在本次分享里面会归类为项目启动阶段。前端同学在里面有三个工作重点，第一个是参与需求调研；第二个是前端人天评估；第三个是前端技术架构的搭建。
系统实现和系统上线
由于这两个周期主要是做研发工作，所以这里会归类为项目研发阶段。在这里面，前端同学需要做好任务拆解和分配，以及做好进度管理和按照进度管理开发。
项目验收
在这个周期里面，前端同学除了配合做好验收工作，还会参与项目复盘。因为项目复盘对于持续优化工作方法比较重要，所以本次分享会把复盘当作一个重点讲，直接归纳为项目复盘阶段。
五个子主题介绍
项目启动阶段
在项目启动阶段，我们应该做些什么，来为后面的工作打好基础。
项目研发阶段
在研发阶段，我们应该怎么做，去保证项目研发顺利、按时交付。
项目复盘阶段
这里讲一下项目复盘的意义，以及具体的复盘方法。
代码规范与质量
重点讲一下前端代码的规范与质量上的解决思路，以及现阶段的问题与解决。
赋能
介绍一下赋能措施，以及如何通过组织赋能，把前端团队的整体能力提升上来。
项目启动阶段
项目启动阶段主要做三件事件，第一个是参与需求调研；第二个是前端人天评估；简单总结下就是需要把前期的需求梳理清楚，以及做好成本控制；第二个是框架、基建的设计与搭建，如何把整个前端的技术架构做好。
需求调研及人天评估
我们先来看一下需求调研及人天评估，其实这部分主要是前端负责人要做的事情，但是前端同学都可以去了解下，因为以后每个同学都有可能去独立负责一个项目。
需求调研是研发工作的开始，前端同学需要配合客户、产品经理，做好前期的需求调研/评估，分析技术实现的可行性，为后续的研发工作打好基础。
如果有去客户现场的同学应该知道，我们要去跟客户谈、跟产品经理谈，把需求梳理清楚。当产品经理输出好对应需求文档、原型之后，技术同学才能投入到开发中，否则可能会有一些沟通效率上的损耗。比如说产品经理他自己觉得需求是没有问题的，但是在输出完原型之后，到了开发同学这里，开发同学又说实现不了，这样就会浪费了时间，影响了整个开发效率。
然后除了需求调研，还要作出一个人天评估。
人天评估也是项目中很关键的一环，直接关系到项目的盈利能力、交付周期保障，我们需要根据需求来制定合理的人天评估，并作出合理的前端资源投入计划，最终达到公司与客户双赢的结果。
就是说要去估算前端同学做这些需求，需要多少人天，需要投入多少人，来保证我们的成本是合理的，资源不会缺少，也不会浪费。
不过每个人的理解不太一样，做出来的东西也可能不一样。就比如一个需求，A觉得应该要这么做，B觉得要那样做；一个任务的人天评估，A觉得需要一个人天，但是B觉得需要三个人天。这时候就需要有一个标准的工作流程来指导，消除这种差异，目前需求调研SOP、人天评估SOP已经逐步完善起来了。
需求调研SOP主要包括以下内容：
- 需求调研的类型；
- 项目背景的调查；
- 演示材料准备；
- 问题准备；
- 需求调研有哪些方法；
- 调研要收集的内容；
- 需求调研的技巧；
- 需求调研常见问题；
- 造成问题的原因。
此外，还有包含了一些调研计划和访谈记录的辅助表格。
其实看起来会更像是产品经理的操作手册，但是前端同学也会或多或少地参与进来，所以为了保证项目整体的交付质量，规范流程还是需要去强调起来。
人天评估SOP主要包括以下内容：
- 人天评估的背景、意义、方法论、适用场景与阶段；
- 具体的评估流程及辅助表格。
框架、基建的设计与搭建-前端研发流程
这里先分享一张前端研发流程闭环图，我们可以先看下前端研发的每个环节里面，可以做些什么，应该做些什么。
比如说：
- 在开发准备阶段-相关规范、技术文档是不是准备了；
- 编码&联调阶段-框架是否搭建好了；物料库是否齐全了，CLI、持续集成、持续交付的工具是否完善了；还有数据Mock文档、Mock服务等；
- 调试优化阶段-包括了数据埋点、性能检测、合规检测、自动化测试；
- 构建部署阶段-包括了构建部署、页面快速搭建的能力；
- 最后是上线后数据采集&分析阶段，包括了异常数据监控、行为数据监控、性能分析、数据计算、数据可视化这些。
这张流程图可能还不够完善，不过总的来说，已经足够启发我们将日常工作对标标准的流程时，研发环节上可以做哪些更好的调整。
框架、基建的设计与搭建-实现方向
一个好的前端架构对于项目来说是很重要的，有利于提升前端应用的可扩展性、可维护性、性能，还能提升开发效率。
在我们之前的项目里面，基本上是把标品项目复制下来改一改就可以了，很多时候是没有问题的，但是有时候项目环境、产品的差异性会比较大一些，就不能完全适用了。
这时候可以结合上面的研发流程闭环图，去思考框架是不是合理的、基础建设是不是完善的。比如说我之前参与过的一个长城汽车项目，没有Jenkins来做Web端的发布，这时候我们写了一套脚本工具来优化了发布流程；还有物料库上我们增加Taro UI，提升了小程序的开发效率；然后在数据Mock上也做了一些尝试，提升了前后端的联调效率。其实这里面还有不少可以去思路的点。
前期工作总结
前面讲了项目启动阶段的几个工作重点，这里总结一下前期工作所需要的一些能力，需要软硬技能结合，让后面的工作更顺畅、更容易收到好结果。
软技能包括：
- 团队协作能力-不管是在团队内部也好，跟客户也好，协作顺利有利于工作的开展；
- 同理心、换位思考能力-我们做技术的，会更多地站在技术的角度看问题，而客户会更多地站在业务场景看问题，如果没有换位思考的话，会造成我们跟客户的沟通效率不高、甚至会产生一些分歧。
- 前瞻性思维-在我们的项目中发生过两个问题，一个是需求频繁地修改，甚至推倒重来；还有一个是技术无法适配业务的发展，导致后续需要返工。这就需要我们更多地用发展的眼光看待需求和技术，把未来的一些可能性、变化考虑好，把事情做得更稳一些。
硬技能包括：
- 岗位上扎实的专业技能-能在客户面前树立专业性，当然这个也是程序员的基本要求了。
- 工作流程标准化-如果工作流程不标准、不统一，就会造成很多的差异。有一个很明显的例子，我们之前经常吐槽，项目合同上的人天，跟我们研发评的人天相差很大，那么能不能做一些拉齐的动作呢？工作流程标准化就是一个解决的办法，目前很多流程的SOP都在逐步完善中。
- 工作方法迭代、研发能力升级-这块是我们持续要做的事情，后面也会讲到通过复盘优化工作方法；研发能力上，比如前端的多端技术、后端的DDD，这条路也持续在走。
项目研发阶段
前期的工作做完后，会进到研发阶段，接下来讲一讲项目研发阶段主要做的事情。
第一个是任务拆解及分配；第二个是进度管理。
任务拆解及分配
参考上面这张图，在需求原型出来之后，需要把每一个功能点拆分为前端的子任务。拆分的基本原则是分成页面编写、接口或逻辑处理两种类型，并且要保持一定的颗粒度，如果页面比较复杂，可以把里面的弹窗、子模块进一步拆分出来。需要尽可能地去保证每一项任务是单一的，这样会有利于我们后面追踪任务的进度。
在任务分配上，优先按照能力来分配，让每个人去做适应自己能力的任务，或者说这项任务对他来说，实现的难度不会太大，也不会太简单。
进度管理
在进度管理上，一个主要的动作是要每天过上面这张进度表，去Review每项任务的开始时间、结束时间、进度、测试进度等等，是否在预期之中。
还有一些基本的原则：
- 每天跟进进度，今日事今日毕；
- 不强依赖上下游，设计稿未出，可先按照原型写页面和交互；接口未出，可先自行Mock数据；
- 任务有阻塞时及时反馈。
因为任务的排期都是按照交付计划来定的，所以要尽量地去保证每一项任务都能按时完成，有阻塞时需要及时处理、及时支援。
反过来说，如果排期不合理、进度不跟进，就可能会导致交付延误、甚至交付失败，所以说我们需要加强进度管理。
项目复盘阶段
当我们按照计划把项目交付了，然后项目结束了，是不是说之前的计划和执行都是过去式，对于以后的工作没有帮助了？
答案是不是的。
我们需要去检查，其中哪些事情是做得比较好的，哪些事情是做得不好的。比如代码规范和质量做得怎么样，有没有很多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的前端同学，计划是双周分享一次，也会看看前端同学的积极性，可能会更加频繁一些。
然后分享的具体目的和意义是什么呢？
对于个人来讲，会有利于技术能力的成长，比如说你有一种技术，我有一种技术，那么分享之后就有了两种技术，或者技术被迭代了，变得更好了。还有就是能够提升沟通表达能力、写作能力、自信心，毕竟我们程序员很多时候都是跟机器对话，更需要一些人与人之前的沟通、公众场合的表达，对写作能力也是有帮助，从而进一步提升我们的自信心。
对于团队来说，技术的碰撞可以丰富团队的技术栈，提升团队的研发能力，然后经过团队内部的沟通加强，就有利于形成学习氛围，沉淀团队文化。
如果大家有什么更好的建议都可以提出来，后面会考虑加到具体的计划里面。
分享一句话
最后分享一句话，“既要低头赶路，又要仰望星空”。
有时候我们在项目上很辛苦，低头赶路，加班加点，而且不断地从一个项目换到另一个项目，技术上用的好像也是那些，没有多大的区别。
这时候会我们产生疑问，一直这么下去，技术会有更好的进步吗？其实我以前也会有这个疑问，所以说，我们还需要抬头看路，能够知道和跟随业界的发展方向，并且争取走在前列。
前面讲的赋能措施会逐步解决这件事情，让我们的技术成长之路走得更稳、更远，也希望能跟大家一起见证，这些更好的转变。
