某大厂原14级离职分享

某大厂原14级离职分享

技术博客 admin 141 浏览

序文

在这段时间互联网大厂工作的过程中,尤其是在大环境不佳的情况下,我们可以明显的感觉到每个个体甚至到每个团队变得越来越卷,也变相的导致企业对个人的输出效率和产出质量要求变得更加严格。不过既然我们暂时改变不了环境,那就去适应环境,辩证的看待这个就业环境问题,这也给了我们一个动机去主动的提升自己的影响力和塑造个人品牌,高质量的输出不仅能展示个人能力及你的工作成果,还能为他人带来工作和生活上的启发与思路。

为了在往后的工作生活中,不管是技术分析、架构设计方案、业务分享甚至是个人随笔中提高个人输出方面的能力,接下来的生活中我也会刻意训练自己写作方面的能力,这次的感悟篇也算是开个头,也给自己的大厂工作收个尾。希望这篇文章也能对正在阅读的职场新人或者即将晋升到P7的同学带来一定的收获~

职场生存

我想很多人和我一样,都是经过九年义务教育,然后经历过高中、大学甚至研究生和博士生的校园生活然后才逐步进入社会开始各自的磨砺,然而由于我们的前半生都是在学校生活中度过,所以会习惯用校园生活那套思维去面对工作,那么在职场生存中一定会遇到许多坎。例如:在学校生活中,我们的任务是完成学校的考核又或者是家长/老师的期望目标,即“学习——完成作业——考试”的循环中一步步做完每一个由别人设定好的阶段性目标。

我认为学校和职场最大的区别在于:自主思考。在学校中我是被动的接受知识或者得到咨询,而在职场中我们要内化成自己的理解并且有所产出,由于许多规则和任务并不会和学校生活中一样写在明面上,而是隐藏在我的项目之中,隐藏在我的人际交往之中,甚至隐藏在公司之外,很多事情的解法也并不是和数学题一样只有唯一解,需要我自己去发现并寻求解法;很多事情也需要我自己去判断,没人我你答案,我也要对自己的选择负责。

这也是为什么我会在一开始会提到职场生存这一点呢,因为只有先生存下来才能去聊其他。也因此我对校园中用的“生活”这个词,而在职场用的是“生存”这个词,那么接下来我想说的通过哪几点让自己生存的更加“轻松”。

心态管理

我希望大家的人生一帆风顺,但是在大厂中难免会遇到很多令人心态崩溃的瞬间,例如6->7,7->8的晋升失败,例如某个季度拿到了3.25,例如你拿到了裁员通知等等。

首先,我一直认为工作不是生活的全部,我不是那种在可以工作中获取到喜悦的人,因为我认为我现在就是在打工,是在为别人的事业添砖加瓦,即使这个事业是万里长城,那么人们也只会记住秦始皇。所以即使在工作中失意,也不要影响自己的生活,因为那可能没有那么重要。而且我一直认为除了工作,大家都需要给自己寻找一些兴趣爱好,假如你没有你可以去尝试之前没有体验过的各种生活体验,因为它们可以丰饶自己的内心世界,而饱满的精神世界也会成为你工作生活的支撑。当然,也可以和领导请假处去旅个行,又或者周末好好出去走走散个心都是不错的解决方法。

我常常会问自己几个问题,如果我40岁了我会想做什么?如果我50岁了我会想做什么?如果我退休了我又会想做什么?当你找到了一些目标和梦想的时候,可能你更会清楚那些事情更重要,哪些事情其实不过如此。

其次,我认为平静的心态和冷静的思维可以帮助自己在这个阶段作出更好的决策。人不是机器,是容易出现差错的动物,而在不冷静的情况下有时候作出错误决策的概率就会变得更高。比如在后续的工作中自暴自弃,或者对待同事或者好朋友不够友善伤害到身边的人等等。俗话说,塞翁失马焉知非福,福兮祸所系。即使暂时的失败,但是后续可能会遇到某些机遇,让你翻盘!

最后,要相信失败总是难免的,要学会去接受失败。我很喜欢的漫画《地—关于地球的运动》中里有一句话——“错误并不代表没有意义”,故事中说到的是“地心说”是社会的主流流派,然后漫画中的主角们提出“日心说”的故事,在当代我们的视角看来,这两种说法都是错的,但是它们都对着整个宇宙科学论有着重大的进步意义。我想说明的就是即使我们在工作中遭遇了某次失败和挫折,也不要气馁,要去思考失败的原因,要去复盘执行中哪里做的不到位,它们都会成为我们日后成功的坚固的地基。

信息与沟通

一方面是组织信息的对齐,这方面重点关注你的组织架构的变动的影响。

一方面是业务目标的对齐,作为一个合格的P7,其中对自己业务模块的理解要更加深入,我理解只要你能掌握业务的「6个什么」——用户、场景、系统、功能、问题以及目标。那么你才能真正的了解业务,你才能说你有了和业务方平等对话的能力。

获得信息只是一开始,获得信息后还要进行有效的处理及沟通,这里分享一本书「非暴力沟通」,可以更好的进行信息交换,对于问题的思考和阐述都需要做到简要精炼,避免造成信息gap。

这里的沟通方可能是业务合作方、也可能是自己的领导与下属。话语本身传达的诉求有很多,但是你要了解的是话语背后的本质。比如:

「产品评审场景」

产品经理:XX产品需要做XXX的功能,为了达到XXX的效果?

(我们需要对它实现的目标进行优先判断,该目标和整个产品的方向基调是否一致、该目标是否和你的目标有冲突;其次需要判断这样的功能是真的能帮助目标的完成,是否有数据进行佐证判断,以及这样的实现是否是最佳的路径。假如对其中任意问题有疑问,你需要表达出合理的质疑)

我:实现XXX功能的目前估算的成本为YY人/日,请问该功能的底层依据是什么?后续上线以后要怎么判断目标是否完成,该功能是否是可长期维护不会轻易更改的?

(可以按照真实语境,进行拆分询问)

「向上沟通场景」

领导:目前XX项目的进展如何?

(我们需要了解,领导询问该问题的目标是因为对项目风险把控以及有可能进展速度不达预期。并且在真实工作场景下,假如你判断有风险,都需要主动提前和领导沟通,因为问题暴露的越晚,那么可以补救的手段就会越少,对你越不利。)

我:根据刚收到的消息,(简要说明问题来源)由于A的变更,B的延期等问题,导致XXX项目有无法按期交付的风险,(给出自己认可的解决方案)目前我认为,例如可以先暂时交付主链路的部分功能比保证按期交付。

最后,再给一些职场沟通的小细节:
  1. 任何有非本部门人员参与的(线上/线下)会议,需要双方给出共同结论的。那么最好在会议前与自己部门同学提前达成统一口径,可以避免在会议上出现分歧以及保障整体会议可以高效沟通。
  2. 许多涉及到多人的项目任务开展前,提前建立好最小相关人的群组,有任何风险问题在群中风险提暴露,如果在群里无法得到及时帮助,那该向上反馈就向上反馈。一是为了有更多的时间去解决问题,二也是为了保护自己
  3. 所有需要上游协助配合的工作,都需要和对方接口人沟通清楚具体的交付时间和交付产物,并保留证据(清晰的聊天记录,非语音或口头承诺)。

选择

选择是一个很大的命题,当来到职场的时候无时无刻面临着选择。比如架构调整后、新的业务、新的职能线;又比如对待同一个问题的不同技术方案,甚至小到需求项目的不同上线方案都是需要由人来进行决策的地方。

有人说,组织架构变动,工作职能变更不是自己能选的,这当然没错,但是你需要清晰的了解你之后要承担的工作内容,如果不了解则要及时和你的领导沟通,看目前的安排是否合理,是否有更好的选择可以争取。如果我们没有自己的思考和自己的偏向选择,就结果而言这当然还是有选择的,只是是领导替你做好了选择罢了,而领导未必是最了解我真实需求的人,因为他思考问题要从整个团队甚至整个公司的角度出发。

我认为一份好的工作内容要从两种角度出发:

一是有成长,一般能带来成长的工作内容一定是颇有挑战颇有难度的,这里的难度不一定指的是耗时久,也不是说做出一个特别牛X的产品,它本身就像个“陷阱”,即使项目本身特别宏大,牵扯的资源面很多,但是如果你在这个项目中能提供的作用很小或者角色很边缘,那么对你来说其实真实帮助不大,只是在你后续面试的时候可以简单吹个牛X,你参与了XXX大家耳熟能详的项目,但是假如面试官继续深挖细节,我觉得你们可以聊的内容就不会太多。我认为的“成长”是说能让我离开这家公司时可以带走的东西,比如这个产品背后链路的技术实现,又比如项目管理方面的技巧等等,是可以复刻的。我要去挖掘这个工作可以给你带来价值的东西。

二是有更大的影响,这点和你的职业规划有关,假如你希望你的职业生涯更进一步,那么在同样的时间里,你觉得自己可以大展拳脚的,投入产出比更高的“黄金”项目一定是大家都需要竞争的,你需要和领导及时沟通并进行争取/立项。 因为你在你后续P7升到P8的晋升或者面试别的公司的业务/团队负责人的时候,有一个体现业务复杂度或者是技术复杂度的项目时会直接提高你个人的影响力,这里的影响力有两个维度:一个是你的产品影响力,一个是你的个人影响力,它们都会在你后续的职业生涯中起到比较关键的作用,因为通过一场战役去证明自己,或者通过一个“技术标签”去代表自己,这比很多话都更有用。分享一句我比较类似的话:“爱情本身不需要成本,但是证明爱情需要”。

任务达成

当你成为或者即将成为14级的同学后,对你来说你的工作任务主要有两块,一块是部分的管理职能,这里的管理包括项目和团队同学;一部分是在当前业务/当前BU,针对某个问题需要由你给出一套较为完善的的架构解决方案(目前前端技术中主要为两个方向通用技术产品领域类技术方案)并成功落地得到业务反馈或者数据支持。如果后续有同学对管理感兴趣可以单独拉篇幅单聊,这里主要聊一聊后者业务或者技术任务达成~

虽然作为一名程序员,但是写代码并不是你工作的所有,你要基于你的目标做可行性分析报告、你的技术方案、以及事后数据采集等工作。这里我准备结合我初入公司接手的微前端架构中后台系统进行探讨。

寻找方向

那么,当领导交给我该中后台系统进行架构优化后,我就要去寻找具体的优化方向。

发现问题

首先,我认为标准的解决问题的完整链路为“发现问题——定义问题——拆解问题——解决问题”。

那么针对第一步“发现问题”,我们要进行需求分析与现状评估。 在做过一定的用户调研(通过问卷系统手机使用用户反馈)以及与自己老板沟通历史遗留问题后新建出一个优化问题反馈表,将高优先级的问题进行专项修复,后续我们沟通后发现中后台系统有以下问题,例如:

  1. 缺少权限角色管理能力及对应配置UI界面,接入新角色、权限必须通过权限平台接入以及代码接入两步,目前仍需人工操作,浪费人效。
  2. 各子业务模块(即独立微前端应用)间所有通用能力无法共用,例如白名单管理、消息通知等。

当发现具体问题定义后,我们就要开始定义问题,并且拆解问题。

定义问题

这一阶段的重点是明确上面发现的几个问题的具体问题范围、影响因素以及需要达成的目标。

例如:针对“缺少权限角色管理能力及对应配置UI界面”这一问题,定义问题时可以细化为:在当前权限管理下,新角色和权限的接入以及老角色的编辑更新需要具体消耗的成本为(耗时 = 单人操作时间x操作人数)xx人效,具体卡点是因为什么原因导致的,问题本质是权限编辑流程不合理,后续优化后,可通过自动化或者节省多少步骤已剩下yy人效(以上关键指标如何采集也需要列在定义问题中,以后续验证优化效果)。

拆解问题

拆解问题的目的是将复杂的问题分解为更易可执行的子问题,便于逐步解决。针对权限管理问题,可以拆解为几个子问题,比如:

  • 理清楚现有的权限系统是如何如何管理各种角色(一般是通过权限码/角色码实现)。
  • 是实现新权限管理系统 还是 在老权限管理系统上做迭代 (假设我们选择前者)
  • 新权限管理系统如何兼容现有子页面/项目
  • 现有的角色码梳理,数据如何一键更新/迁移
  • 新权限管理系统的页面UI如何实现
  • 新权限管理系统的接口如何实现
  • 后续的角色码如何管理,提供对应的新操作手册
  • 进行相关人员的培训宣讲
解决问题

项目上线了不就代表事情完成了,更不是到此结束,俗话说:“有始有终”。在问题解决之后,仍然需要重点关注以下两个方面:

  1. 数据对比验证:确保有完整的前后关键指标数据,以验证优化效果。如果公司没有完善的埋点系统,也可以通过人工统计等方式辅助收集数据,确保能够清晰量化优化成果。
  2. 文档沉淀与复盘:整理并记录整个优化过程,形成可复用的经验或能力文档,便于其他同事参考。通过复盘,总结个人在过程中遇到的挑战和取得的成果,这不仅是提升自我的过程,也是在团队中展现自身价值的良机。

这样才是完整的闭环。

时间管理

在大厂工作中,特别是我这种弯道超车来到大厂的人来说,一直能感觉到时间明显不够用,不只是因为涉及到的开发内容变得更多,而且我需要花比别人更多的时间用来学习、团队管理、开会、甚至是解决一些公司政策性工作,并且每天都会发生一些预料之外的“事情”。

如果你不把各种“事情”进行分门别类,你可能很快被并发的任务所淹没,感觉到“时间不够用”最终导致结果没有完成,这也是我刚开始进入大厂公司就实际遇到的问题。

我会,给大家参考一下我的记录方式以及表格的组成部分:

优先级 任务概述 衡量标准/产物 DDL:截止日期
P0
P1
P2
D0

(1)优先级

  1. P0 代表重要且紧急——表示每日都需要重点关注进度是否正常的任务。
  2. P1 代表重要不紧急——表示高优先级但是时间上并不着急的任务,可以在完成P0级任务后优先完成。
  3. P2 代表不重要不紧急——表示一些这类任务可以不设置截止日期。
  4. D0 每日需要做的事情——表示一些每日重复性的工作,比如工时登记,人员任务检查等,代码CR等。

(2)任务概述

任务的概括性描述

(3)衡量标准/产物

可以衡量该任务是否完成的确切指标,例如:xx文档、yy项目交付等

(4)截止日期

****最迟完成时间


上面表格我每个月会复制新建一个,上个月未完成的任务都会顺延复制到新的表格中,避免完成的任务过多导致表格过于臃肿,且每个工作日下班点都会设置闹铃⏰提醒,以提醒我任务完成是否有风险。

最后,我想说的是时间是很贵重的资源,也不用花时间假装努力,因为结果不会陪你演戏。

技术壁垒

技术壁垒是一个在你面试、晋升过程中常常需要体现的东西。那么如何在平时的业务项目中或者技术项目中慢慢搭建自己的技术壁垒呢。基于“二八原则”,80%的前端内容是大部分人都能熟练掌握的,而剩下20%的内容虽然使用场景有限,但却是容易形成个人壁垒并且不容易轻易被取代的内容。

在大厂中,有三条路径比较清晰形成自己技术壁垒的路径:

全栈开发

前端动画和可视化

关注业务相关的可视化需求:大厂的各业务部门(如电商、金融等)对数据展示和可视化交互需求很高,寻找并参与这些领域的项目。专注于高效展示大规模数据的前端实现,可以考虑和数据分析团队一起做需求沟通,了解他们的数据来源和关键指标,从而构思出更多的创新展示方式。这块需求可以和PD共建,假如公司没有对应的数据可视化平台,那么这就是你的机会,假如有,如何快速定制化搭建可视化也是后续可以磕优化的方法。

提升动效设计能力:将动画设计融入用户体验中,而不仅仅是“炫技”。在大厂这种用户流量大的环境下,动效优化显得尤为重要。可以学习帧动画、SVG 动画、WebGL 的使用,尤其是对高并发、大流量的环境做性能优化,例如使用 Canvas 渲染器来处理复杂动画效果。目前有很多例如可直接使用的lottie库、ThreeJs、Framer Motion都是可以深入掌握的方向。

架构设计和工程化

不可否认的是,目前前端程序员的最红火的几年红利期已经过去了,一些对开发提效最多、对业界影响较大的工具、框架库在github已经有许多,并且甚至可以直接拿来就用;且在公司内部纯做这块的人一定是少数,所以在日常工作中的机会肯定不多,我该怎么做?

架构设计或者工程化一定是对源码、整个项目的编译流程更加熟悉以后才有优化的空间。

深入学习源码和编译流程:要对现有的前端工具如 Webpack、Vite 以及内部的定制化工具有深入理解,尤其是编译、构建优化、插件机制等。熟悉源码可以帮助你发现性能优化点、定制工具或框架以适应团队的特定需求。

在大规模系统中寻找架构优化点:尝试为大规模前端项目引入微前端架构,或者设计组件库来提高复用性。阿里的业务模块众多,在团队内推动统一组件和模块的复用可以显著提升开发效率。考虑基于 TypeScript 的静态检查,降低代码耦合。

关注前端的 DevOps 工具链优化:优化工程化流程,尽量缩短开发到上线的周期。比如,精简测试、打包和发布流程,将复杂的代码审查与构建部署自动化。可以在公司内部尝试引入或优化 DevOps 工具,将精力投入到编译时间、包体积优化等方面。

总结

假如你想成为一名合格的P7,那么对于团队管理、技术创新、跨BU全局观、产品化思维以及表达能力等许多方面都会有新的挑战。但是在此之前,快乐生活,做好自己,祝各位安好。

源文:某大厂原14级离职分享

如有侵权请联系站点删除!

Technical cooperation service hotline, welcome to inquire!