2023年转眼就过去了,今年我从一名大学生转变某阿里系大厂的“搬砖打工人”,这一转变真的是给我“涉世未深的纯洁心灵”带来了大大的“震撼”。
角色的转变是需要时间进行“内部消化”的。无论是对于个人的价值认知或者是行为方式来说,都会经历从学生思维逐渐转换为互联网大厂思维的历练过程,往往这场历练都不会那般的轻松,甚至称之为“渡劫”都不为过。今年我也见过不少人无法适应这里的工作环境选择离开,我在这个视角切换的过程中也经历过质疑的时刻,甚至也产生过“大不了爷不干了”的大胆想法,但最终还是凭借自己的努力以及一系列的辩证思考、思想斗争踉踉跄跄的“渡劫”成功。
正应了那句老梗:“质疑XX,理解XX,成为XX”。这真就是我这一年的真实写照:“质疑蚂蚁,理解蚂蚁,成为一只小蚂蚁”
接下来我就讲讲这一年在蚂蚁的一些心路历程,我是如何从质疑蚂蚁到理解蚂蚁,最后成为一只蚂蚁的。
在工作之外,不得不说蚂蚁的员工关怀还是做的很好的,在我了解的互联网大厂中应该是数一数二的了,甚至我觉得比老大哥阿里都要更好,各种福利层出不穷。可以说抛开工作体验不谈,在蚂蚁工作还是很nice的。
但问题就出在这工作体验上,蚂蚁所推崇的那一套工作理论,简单来讲就是那一套“方法论”让业内业外的人,甚至是校招群体都颇有微词。
在这里工作,不仅仅是把工作做完就可以了,这仅仅是最低要求,完成最低要求是达不到老板眼里的预期的。你要做的更多的是对于“方法论”的一些履行和实践,比如:“你做这件事的价值是什么?”,“你对这个问题的分析是什么?你的分析角度是什么?你分析的全了吗?你怎么证明你是全的呢?”,“你的做法是解决这个问题的最佳路径吗?你的系统性分析在哪里?如果只是随机的想到一些做法可能得不到最佳方案路径。” 在我所接触的公司同事中,几乎每一个人都被这些“夺命连环问”拷问过,并由此陷入巨大的精神内耗,同时觉得自己被老板“PUA”了。
到底啥是方法论,我在这里说一下我作为一个阿里系新人对于方法论的理解。方法论就是一套价值驱动的对问题进行系统性辩证分析的方法模版。
理解中的几个关键词在这里解释一下:
在蚂蚁,你会发现这里的“老司机们”普遍将大家实操能力当作最基本的要求,默认每个人都是能够达成的。说直白的就是这里不关注技术细节等一些实施层面的东西,什么“分布式多线程高并发”,什么“这段代码写的不好,可以这里那里抽象一下”,“老司机们”都不care,这些都“太基础了”。
那这里工作关注的是什么,关注你对于问题的思考与深刻理解和认知,你能不能对问题进行系统性的全面拆解从而证明你走在正确的实施路径上,并且说明解决问题背后带来的巨大价值收益。
“这有必要吗?” 这就是今年我和方法论进行斗争的主线故事。对于一个校招生而言,方法论对于我行为方式的冲击太大了。十几年的学生生涯所养成的做事习惯就是就事论事,看到是啥就是啥,有问题解决问题就好了啊,不会去思考也没有机会去思考问题的内核以及解决问题背后的收益是什么。
学生时代是没有问题辩证分析论的,一是学生时代的所遇到的问题都过于浅显(虽然就算是浅显的问题也可以拆解出一些门道),二是学生时代的问题都是别人拆解好了喂给你的,对于问题本身的拆解都给省略了。如果有人说学生时代也会有些探索性的问题,需要自己拆解问题,那肯定也是在研究生时期,但我也没上过研究生……反正本科时期对于问题本身的钻研探究是少之又少。
学生时代是没有收益论的,学生时代的做事收益太明确了,只要跟随大部队走就是收益最大化的方式:做题、考试、做题、考试,高考、考研、考博、考编,反正能考就考,应考尽考即可(虽然对于我的收益最大化的方式不是这样)。
由于我的学生时代从来不会去辩证思考问题内核,也不会整天瞎想这那儿的收益,所以刚到职场的我,第一次带着一套技术方案和老板对焦,当老板把方法论以夺命连环问的方式拍我脸上,直接把我给干沉默了。“你觉得XX系统现在最重要的问题是什么?你的问题分析维度完整吗?你怎么证明你的分析维度全了呢?如没有分析全你随机想到的解决方案可能不是最佳路径。你做这件事的价值是什么?你的价值和投入匹配吗?”
“这有必要吗?”这几个字其实是我对于方法论的质疑,方法论哼哧哼哧分析一大堆有什么用呢?问题分析这么一大堆不就是纸上谈兵吗,各个都是理论大师没见得代码写的多好。
我曾经不止一次的对主管提出过质疑与困惑,对于问题分析、价值阐释的高程度聚焦和投入背后的意义到底是什么?主管给予我的解释是:“你需要自证你是对的”
“你需要自证你是对的” ,这句话是理解方法论的关键。最开始我也不理解这句话的背后的含义,直到工作的一段时间才逐渐回过神来。
学生时代的自证手段太简单了,以至于我们都忽略了自证这个过程。学生时代的自证就是通过做题中的标准答案完成的,对的就是对的,错的就是错的,白纸黑字的写在答案里,不留给人任何的思辨空间。
工作了之后,学生时代的这套自证逻辑完完全全的不适用,工作了之后没有考试没有做题,自证的判定结果不会写在题目的参考答案里,答案在哪,不好意思,答案都虚无缥缈的飘在空中。这不仅仅是技术层面能够解释的,毕竟技术本身不带来价值,技术都是开源的,而是技术所支撑的核心业务领域带来价值。
所以说我们自证自己行为的正确性,很多时候要脱离技术本身,不是简单考虑用这个多线程,那个分布式就可以的,不能从过程出发,需要一,回归起点,分析问题本身,多方面的对问题的本质根结进行抓取,以此自证我的处理过程是正确的最佳路径, 二,回归终点,分析解决问题带来的收益与价值,以此证明我解决这个问题是在做正确的事。
要理解方法论,不能只看见表象,只看见了“互联网黑话”,“向上汇报”,“PPT大师”,“理论大师”,“天才小说家”,要去看到方法论背后的驱动力:以正确的方式做正确的事。正确的方式通过问题辩证分析获得,正确的事通过价值分析获得。
理解了方法论之后,我尝试将方法论融入我的日常思考中,还真别说,有时真能帮助我思考出不少不一样的东西,以助于我找出最佳问题解决路径。
“问题该如何辩证分析?” 对于问题的辩证分析需要从几个方面入手,同时这几个方面之间是循序渐进的。
不能仅看到问题的一个侧面,而是要尽可能考虑所有相关的因素和条件。这里有个技巧,就是对于问题的全面性拆解我们往往可以从一个问题涉及的全集入手,将全集拆解成几个互斥的子集,然后一个子集一个子集的去看,看每一个子集时,从全流程出发,罗列出问题所位于的全部流程节点。目的就是框出问题的范围,抱着“宁可错判一千,不可放过一个问题”的态度。
举个例子,我要对系统的某个查询功能进行性能优化。全集是什么?这里可以将全集拆解为查询功能涉及到的所有场景。然后各个场景可以按模块拆,拆成客户端和服务端,去分别分析客户端在该场景下的流程逻辑是什么,服务端在该场景下的流程逻辑是什么,然后找到存在性能瓶颈的流程节点。
当我们通过全面分析对问题进行定位后,接下来就是对问题进行逐个分析击破。在此过程中需要注意的是抓问题要抓根因。一个问题的产生是由两部分组成的,现象和根因。现象是问题对外展现出来的表现形式,而根因是造成这个现象的主要矛盾点。如果我们的处理手段只是对现象进行处理而不是根因,那么当现象在未来因为外部原因而放大之后很可能处理手段就会失效。这就好像对一个发烧病人进行物理降温,当我们把冰袋拿掉之后,病人立马又烧起来了。只有针对发烧原因进行吃药救治,才能真正意义上退烧。
比如,如何解决查询超时问题,如果只是从现象入手,那么处理方法很可能就是把超时阈值设置的长一点。如果通过全面分析把问题的现象和根因区分清楚,那么我们有可能就能得到正确的关键路径,多级缓存或者并发查询。
当根因识别完成后,问题的拆解环节暂时告一段落。接下来就是选择正确的处理方案。此时,用发展性的眼光选择问题解决方案是一种更好的方式。问题不是静止不变的,而是在不断的发展变化中的,因此我们的处理手段也应该跟随着问题的发展而发展变化。短期来看,我们以方案A解决现有问题,但长期来说,现有问题可能会衍生出哪些可以预知的连带问题,能不能从长期的角度以方案B对问题进行防御性限制,制止问题的未来扩散。
以发展性的眼光思考,短中长期方案结合,能够得到更好的结果。 比如短期来看,查询超时可以通过并发查询解决,但长期来说,查询量可能超乎想象的膨胀,能否通过动态线程池的方式对并发度进行弹性控制,以应对未来不可预知的超时风险。这就是一种短期长期方案结合的处理思路。
其实方法论的分析套路可以用来方法论这件事情本身。方法论本身我们就应该带着辩证的态度去对待,它虽然不一定对,但毕竟阿里系的这些公司能做到现在这般地步一定有它可取的地方。有很多人只是看到了方法论的一些表象就一味的排斥和反对,没有看到方法论的内核所在。诚然方法论有他的问题,比如“PPT文化”、“PUA”之类的恶习,但是其对于问题的拆解套路和价值的阐释套路还是有不少可取的地方。正所谓“打不过就加入”,也不是不可以~
作为一名技术研发,光有技术sense可能还不够,业务sense和价值sense都是非常重要的东西。这些是一名技术研发工程师的综合素质的体现。找到解决一个问题的价值所在,可能和解决问题本身同样重要,尤其是在互联网的职场环境中。24年希望自己能够对于问题的价值阐释上面有一些自己琢磨出的东西。
我是Ian,一个喜欢琢磨事儿的互联网从业者。如果你觉得我说得不对,那一定是你对,毕竟这只是一个工作小半年的职场新手的一些小小思考,但我所说的东西对你有一定的启发,欢迎一同交流,一起进步成长。