一名前端 Leader 的转正述职记录

背景

一转眼，已经是 2022 年了。为了我爱的人，我决定离开北上广，去海口或者三亚过两年隐居的日子。
最近翻了翻语雀，发现有一篇写于去年刚来公司转正的记录性文章。于是整理了一下，决定发出来，可能会给大家的成长带来一些帮助。
以下是正文部分：
转眼之间来公司已经三个多月了。
虽然因表现突出，两个月前已经被提前转正，但是具体的转正流程都没有走。在 HR 的组织之下，我开始准备述职报告，这是公司的传统。
转正述职会的参会人员共有 5 位：

1. 我。
2. 我的直属领导，也就是研发经理。
3. 技术中心负责人，也就是技术老大。
4. HR。
5. 以及 HRM，也就是人事的老大。

我的述职共分为 5 块内容：

1. 试用期期间完成的成绩
2. 对岗位职责认知
3. 工作中问题的分析与改进
4. 下一步的工作计划
5. 转正答辩
   

试用期期间完成的成绩

代表项目

京东商城上线

人往往对刚开始的事情记忆特别清晰，我入职的当天，上海刮台风，地铁停运，尽管我早起了一个小时，打了出租车，但还是迟到了一个小时。
加入公司的前三天，京东商城上线，之前的前端 Leader 着急离职，就把他的 Bug 转给了我，然后加班修复了十余个 Bug，支持京东商城正常上线。

BH 银行云商城上线平台活动

加入公司的第四天，BH 商城要上线平台活动，并且要与红包功能互斥。从了解需求到梳理逻辑到功能研发到产品上线，只有 1 天时间。我记得当时和 DW 哥（项目）、Q 哥（后端）、JP（测试）四个人加班到凌晨三点多。当时我还没有搬到公司附近，住的地方离公司非常远，所以就在公司附近的酒店住下了。DW 哥还贴心地送我到酒店、帮我订好票才回家。
上面介绍的这两个项目是我刚加入公司做的项目，而且比较具有代表性，所以拿出来讲一下。
熟悉公司的业务、团队和流程之后，我的主要的工作内容有以下三个板块。

产品研发类

第一类就是产品研发类的工作。这一部分内容包含两块，一个是云商城，也就是 MALLSAAS，另一个是 OTOSAAS。

云商城版本迭代

MALLSAAS 的主要客户是 BH 银行，其实我们公司最大的客户也就是 BH 银行。所以云商城的很多功能迭代都是围绕 BH 银行的需求修改的。
比如日常的营销活动，中秋活动、伊利牛奶活动、养老活动等等。
比如功能的升级迭代，平台活动与红包互斥、上线快递 100 等功能。

OTO 场景优化与修复

OTOSAAS 由于场景很多、客户也很多，各种兼容性问题、细微的 Bug 层出不穷。所以相比于云商城，OTO 是一个复杂性更高的项目。
研发卡券 2.0。修复和优化过很多场景，比如电影、话费、外卖、卡券、快递等等。

团队建设类

招聘

第二类就是团队建设类。
由于项目的复杂度过高，项目采用的技术栈也较为庞杂，有些核心项目的技术栈老旧，导致项目维护困难，慢慢地前端就变成了项目的瓶颈。
所以招聘一直是我工作中的重中之重，我一直在努力的招聘、也迫切的需要能找到一些优秀的同事来一起升级打磨我们的产品。
从加入公司到现在为止，三个月的时间，经历了大概 60 场面试，平均下来每天 1 场。
发出去将近 10 份 offer，入职过 5 位同事，但最终只留下来 2 位。
而这两位同事就是 Vue 团队的同事。为了解决上面提到的那些问题，我们组建了 Vue 团队，用 Vue 来逐渐替代 React，来解决招聘困难、项目维护困难等问题。
所以除了招聘以外，我的另一个工作重心是 Vue 团队建设。这一部分还处于第一阶段，我的主要贡献是搭建了组件库的研发脚手架、编译、测试、打包等完整的工作流。并主导组件库的设计和研发。

基础建设类

第三类就是基础建设类。
这是一部很难体现出来的工作，但这也是不能被忽视的问题。
基建类的工作主要包括几块内容：
设计并实现了生产仓库 git commit message 的验证规则工具，每次提交都必须注明发布日期和发布序号，这样可以有效防止误发布、漏发布和错发布等问题的发生。
研发了 OTOSAAS 多场景多客户的快速发布脚本。在此之前 OTOSAAS 有一个单场景的发布脚本，通常用在测试环境中。如果要在生产环境多场景多客户发布，依然要手动拷贝很多遍代码。整个过程相当麻烦。而且极容易出错。使用快速发布脚本可以通过配置快速完成多场景多客户的发布工作，避免了人工操作带来的一系列问题。
OTO 之前有很多依赖包来自于不同的地方，有些来自于公司自建的 npm 私服，有些来自于 git，有些甚至需要手动拷贝包。后面我统一整理到公司的 npm 私服上面了。
使用 React 15 版本封装 OTO 新的组件，使用单仓多包的发布与管理模式，可以做到即插即用。并且兼容 OTO 全场景。目前封装的组件有公司信息页脚、底部导航栏、订单列表和手风琴等。虽然后续主要的技术栈要切换到 Vue 上，但是 React 组件可以解决当前的很多问题，所以还是有必要的。
还有就是云商城的工作流改造。主要包括两个部分：本地服务器和编译打包脚本的改造。
云商城原来是由多个人并行开发的，所以在设计上只考虑了单模块的本地服务器启动和打包，不支持所有的模块全部启动，比如首页跳转分类，需要先把首页停下来，再启动分类，整个过程会将近 5 分钟。由一个人来开发的话，开发体验非常糟糕，所以我使用了一层聚合代理，可以支持全量模块或者指定模块的启动。
另一方面，原本编译打包脚本也是不支持并行的。如果修改了公用的方法或者样式，每个模块逐一打包，大概要半个小时，都可以睡一觉了。我使用多线程进行并行打包，将时间缩短到了 5 到 10 分钟。
这些基础改造都是在 POC 上线那一次开始并逐步完善的。虽然我经常加班，但是在周末和后端一起加班，那是唯一一次。所以记得很清楚。POC 那次改动的东西非常多，所以需要频繁地编译、打包、发布。我是被逼得没办法才这么决定做这些事情的。

工作中问题的分析与改进

硬性问题

我对工作的态度还是很认真、诚恳并且有耐心的。
虽然日常工作中会存在各种各样大大小小的纰漏，但如果说一个最大的问题，那无疑是发布。
由于之前对公司的 CDN 运行流程并不是很了解，所以导致了几次发布问题。比如有一次 jy 银行发布出现问题，加班到凌晨两三点。
对 CDN 有了一个全面的了解之后，发布出现问题的情况减少了。但仍然会存在一些问题，比如对饿了么的加密问题不够了解，直到发布前一个小时才反馈问题，导致发布拖延到下一个发布日。
而 Jenkins 线上打包有问题，主要就是不识别路径大小写，这也是我一直的痛。所以我一定要解决掉打包的问题。目前的解决方案是搭建灰度环境，测试通过后将灰度环境下的前端代码推送到生产环境进行发布。

软性问题

除了这个硬性的问题以外，我还反思了自身几点软性的问题。
第一类是工作习惯的问题：
第一点是：在面临高难度任务时，喜欢用战术上的勤奋掩盖战略上的懒惰。就像云商城的瀑布流改造，原本的代码已经很难继续修改了。明知道这样做是存在风险的，但还是在上面修修补补，最终也没能成功通过测试。让之前研发的排期时间白白浪费掉了，这种场景我应该下定决定把它重构掉。还有一次是 bj 银行的线上事故反思后的技术方案。我的技术方案是让运维监控第三方 JSSDK，出了问题第一时间发邮件、发钉钉。而研发经理给的方案是将第三方 SDK 进行备份，放到 CDN 上面，通过配置子域名、防盗链的方式，彻底避免依赖不可靠的第三方 JSSDK。
第二点是：喜欢专注于某一类事情，面对多任务频繁切换时容易应接不暇。但是我的工作性质就是包含了很多管理方面的因素在里面，所以任务频繁切换是不可避免的。我只能逐渐适应这种节奏。
第二类是思维方式的问题：
思维神经比较敏感，容易把一些事情想象得过于严重，以至于夸大事实。所以有时就会自己给自己制造很多压力。这种思维方式有利有弊。如果心态好的话，可能会转化成动力。如果心态差的话，那可能就会产生很多负面情绪。
第三类是思考问题时不怎么划分边界，容易超出自己的职责边界。也就是老是为别人考虑。我经常帮助项目去思考问题。关于这一点，开会时老板经常提到，不要干涉自己职责范围以外的事情。
思维方式往往是很难改的，但我会尽量按照公司的企业文化来考虑问题。

对岗位职责的认知

我的岗位是前端 Leader。要成为一名优秀的前端 Leader，我认为要做好三点。团队建设、项目研发和技术方案。

团队建设

团队建设的本质是以解决问题为根本，追求事物的可持续发展。
简单来说，就是在现实的复杂情况下，把人凝聚起来，让团队成员有提高、有成长，形成团队战斗力。之后再把事情梳理清楚、做明白、拿到结果。
在这个动态变化的过程中，需要不断地解决问题、完善机制、打造团队。这就是我对团队建设的理解。

项目研发

一个项目的标准流程简单概括是 PRD 评审、确定排期、研发、测试、上线、验收。
这个过程并不复杂，想要做好这些事情，那么就做好三件事即可：把执行做到位，关注过程管控，确保系统交付。

技术方案

技术方案的制定，通常应该是由架构师来确定的。
我们公司目前并没有前端架构师的岗位，但其实我目前的工作职责是和前端架构师的职责有所重叠。
那么我所关注的是，当下最流行哪些技术、我们应该选择什么方案、我们应该用什么开源框架。
当然，不应该仅仅是这些东西，还需要具备战略意图和思考力。
那么，就是需要考虑几个问题：
在目前的架构中，应该关注哪些？应该干预哪些？
如何通过技术方案为团队或企业创造价值？
如何在各种资源制约之下，去实现架构目标？
每一个问题都是值得深入探索、探讨的，就不在这里展开说了。

我的优势

个人性格

我是一个偏外向、皮实的人。而且充满自信和勇气。
我可以面对各种各样的挑战，并且可以战胜它们。
我认为这些性格特点是成为一名优秀的管理者不可或缺的能力，重要程度甚至胜过技术能力。因为技术能力是很容易被培养的，而性格却是很难改变的。

个人特质

求知欲、思考力、心态。
我对新知识的渴求极强，特别爱看 Youtube、Twitter、Medium、Reddit、BBC News 等网站。关注最新的知识、技术动态。因为国外的知识往往都是第一手、最新的。而且国外分享的内容都很直接、很干。国内的很多公众号和技术社区的内容质量差强人意。
国内的学习平台我喜欢使用得到、极客时间、知识星球、知乎、微信读书等。不过我更倾向于付费的内容，免费的内容很少去看。原因就在于付费可以保证内容质量的下限。每个人的时间都是有限的，既要 work life balance，又要不断学习，最好的办法当然是提高时间的使用效率和学习内容的质量。
另外一个就是我有听博客的习惯，小宇宙是一个非常不错的 App。
求知欲所带来的就是数不胜数、琳琅满目的知识，经过对这些知识的梳理、归纳、内化后，我会进行一些思考，并且将这些思考输出到一些平台上面。比如商业类的思考我会在财富 Plus 上面进行发表；正式的技术类探讨，我会在 Discord 和 Matrix 上面参与，我有加入 W3C 的几个 CG。技术类的文章我会发布到自己的博客网站，也会发布到掘金。
我最满意的，是我的心态。我是以一种轻松愉悦的开放性态度去对待工作和生活的。我不会因为某些工作不合胃口而去排斥它。我认为一个强大的人，无论要做什么事，都应该能够接受。无论是造火箭还是擦马桶，都能做出让人意想不到的成绩。

下一步的工作计划

让团队保持稳定

团队稳定对我来说是一个不小的挑战，因为在这方面我没有足够多的经验。
我目前的想法有四点。
第一、定期团建。吃吃喝喝聊聊天吹吹牛，这是提高信任的最佳方式。也可以说是一种人文关怀。
第二、定期技术分享。团队内的很多人是很仰慕我的技术的，我认为应该利用这一点，每周展开技术分享，和大家多沟通交流讨论，促进彼此的技术增长和友谊。更重要的是，Leader 的强大能够给大家带来信心。
第三、为团队成员争取奖励。比如提高加班补贴、餐补福利、调休福利、绩效奖励等。表现优秀的人应该得到奖励，提高大家的竞争意识。
第四、帮助团队成员分担外部压力。如果我们在项目中出错，项目经理带来的压力是非常大的。我希望我能够主动去分担压力。尽量让大家保持一个较好的工作心态，不要产生「我做了那么多，为什么最后挨骂的还是我？」的心理感受。

Vue 技术建设

实施 Vue 组件化，以 Vue 技术栈进行开发，并通过质量验收，完成项目交付。
具体细节不在此展开。

保障项目工程质量

我打算分两个层面加强项目工程质量。
第一是研发阶段，落实团队内 git flow 的分支模型，每次发布代码前都需要进行严格的代码评审。
第二是运行阶段，接入监控平台，我希望是 sentry。如果资源足够，也可以选择自研。

答辩

直接主管

我的直接主管是研发经理。他说我上面说的东西全部都是对的。没有什么问题。那能不能说两个他自己感受到的我的缺点？
我说当然可以。

问题1：反馈问题不够精准。项目和测试那边提出的问题，我的回复都是小问题，并没有把问题的严重性描述清楚。到最后容易出现不可控的事故。

问题2：对线上问题不够重视。每次线上出现故障，大家都会下意识地说是客户的问题或者是第三方的问题，从来没有优先考虑是不是自己的问题。

这两个问题说得很对。
第一个问题确实完全是我自己的问题，我总是觉得自己能力是完全可以的，自己就可以把问题处理的很好，所以不想把问题严重化，所以向上反馈都是按照较轻的程度反馈。如果我的直接主管很反感这样的话，那以后我就把最真实的情况反馈上去，这是没问题的。
第二个问题是我的问题，同时也是整个研发部门的问题，不论是前端还是后端。我们的习惯就是如此。当然我也在努力改变这个问题。我尽量以身作则。

技术中心负责人

W 哥作为技术中心的老大，当时决定招我进公司的就是 W 哥。
W 哥对我问了两个问题。

问题1：来公司之后最大的收获是什么？

两个方面吧。
一是管理能力的提升。
因为我上一份的工作是架构师，其实管理属性很少，甚至可以说并没有什么管理属性。但是在三年前和五年前分别担任过技术负责人和项目经理。所以还算是有一点管理经验的。
但是并没有系统地学习过管理这件事，也没有认真思考过管理这件事。但是在加入公司的这三个月里，我也算是总结了一定的管理经验。
比如该怎么和下属沟通、比如怎么增强人文关怀、比如怎么复盘、怎么管理项目进度、怎么制定技术标准、怎么提高协作效率等等。
二是对技术耐心的提升。
公司的产品是在四五年前就启动研发了。这么多年来积累下来的东西还是非常多的。单单 git 中的仓库数量都有 500 多个。
其中 OTOSAAS 的技术非常复杂，从 Webpack1 到 Webpack5，从 React 15 到 React 17。各种时代的技术都有在用。
我记得刚加入公司的时候连 npm 装包都非常困难。
包括很多框架的文档现在也很难找得到。
我觉得这也是很多前端被劝退的原因之一。能够 Hold 住这些项目并且愿意留下的人真的很难找。
但是我并不是遇到困难就退缩的人。我把 npm 3.x、5.x、6.x、7.x 的装包机制和特性都研究了一遍。包括 npm、yarn、pnpm 之间的一些差异都研究了一遍。
当然也踩到了很多坑。
比如 npm 3.x 不支持 peerDenpendencies。
比如 React 的 typescript 类型是从 16.x 版本才支持的。
比如 Fregument 是 React 16 才支持的。
比如 CreateRef 是 React 16.3 才支持的。
比如 Webpack 2+ 才会优先寻找 package.json 中 module 中指定的入口，Webpack 1.x 只会去寻找 main 指定的入口。如果要导入 module 指定的入口，需要使用全路径。
解决这些问题，只能不断尝试、不断翻阅源码。
在这个过程中，增加了很多对技术设计哲学、运行机制原理和源码的理解。

问题2：对自己的成长有没有达到预期？

基本上已经达到了预期，但是还差一点儿。
主要是沟通时照顾情绪方面的问题。虽然每次我和其他人沟通时，都在心里暗示自己要照顾对方的情绪，但是当我要表达某一件不太好的事情时，很难既精准的表达意图又能够让对方没有产生不良情绪。我觉得这和我的经历有关系，我还没有很多这方面的经历。

HRM

作为 70 后知心姐姐的人设。HRM 并没有提出什么问题。而是说了一堆指导意见。
比如我们前端团队里面有一位号称全公司最难搞定的人，M 同学。在和他沟通时，一旦有不利于他的事情，比如给他插活、安排他加班或者指出一些他做得不对的地方，他就会很容易情绪化。虽然我一直在努力缓和我们之间的关系，但现在仍然是很难特别友好的相处。HRM 姐姐就给我分析了一些方案，比如 M 是天蝎座，天蝎座比较难以敞开心扉，心里也比较要强。而我是狮子座，同样是比较强势，爱面子的人。所以我和 M 同学之间的关系恶劣在意料之中，那么如果要缓和这种关系，一般是有两种途径。
一是直接把事情敞开心扉和他说明白。
二是恭维他，先把他恭维好，再聊事情。
天蝎座的人需要让他认可，一旦他认可了你，就不会再暗暗和你较劲了。
我和 HRM 姐姐都是喜欢研究哲学的人，她妈妈就是哲学系的。但是她研究的是佛学。而我喜欢的是西哲，尼采、康德和弗洛伊德。

HR

问题1：面试过程中如何了解一个人？

我首先会正面问一些工作经历，技术能力相关的。从这些问题中我能看出他的性格内向还是外向，是否热爱技术，是否对技术有所追求等。进而分析他是否适合、能否胜任我们的工作。
然后从侧面问一些性格、成长性、抗压能力、责任心之类的问题。
最重要的是，我要知道他最在意的是什么？他能不能接受我们的企业文化？

问题2：团队建设具体的方案是什么？

上面有提到具体方案。
总结来说，就是带人和做事。

总结

写总结的时候，我已经离开了这家公司。但它带给我的收获还是蛮大的。
很幸运能够和这批优秀的人共同经历了那么多时间。我确实学到了团队管理方面的很多技能和技巧。
很遗憾，没能和大家一起将公司上市，我得提前退出了。
因为我实在没办法继续忍受和我爱的人相隔两千多公里，整天飞来飞去的日子。而且在公司的这段时间，工作强度一直很饱和，我投入到生活上的时间真的很少。我每天只能睡五六个小时，永远无法清零的 Task List，基本上每个周末都要加班。如果我单身还好，这些都不算什么问题。可我已经有爱的女孩了，我要多花些时间陪陪她。
人生就是这样，总会有不期而遇的缘分。
离职时，老板和我聊了一个多小时，他让我认真考虑一下。
其实我没有什么可以考虑的。至于工作重要还是爱情重要，这又是一个争论不休的话题。我不想在这里继续写这方面的问题了。我只想说，我从来没考虑过这个问题，我眼里自始至终都只有她。
最后，希望大家在工作上都能有所成就、事业有成，爱情上都能碰到那个 Ta。
还有，希望上海早日解封。