品质优化半年工作的回忆与思考
好久没有写博客了,上一个博客应该是去年12月底了,讲了我的2020都发生了些什么。这回说一说我最近半年的工作吧。每当我脑袋里总是充斥着关于同一件事的想法和回忆时,我就知道是时候把这些想法好好梳理一下,做一些总结了。
最近半年的工作确实值得好好说道,因为这是我工作以来(包括实习)最有意思的一段时间,但同时也是我最焦虑的一段时间。这半年我主要在做品质优化方向的工作。何为品质优化?在我的理解来看就是通过优化产品体验问题或性能问题来达到提升产品数据收益的工作。这句话有点绕口,我们拆开来说。这个工作的目标是改进产品体验,从而提升留存时长等数据,手段可以是修改产品结构、上线新的产品策略和进行性能优化等。
20年9月份的时候我换了一个方向,从业务侧到品质小组工作。刚开始,这是一个超出我预期的工作内容,因为我开始做性能优化工作了。我相信每一个工程师都明白,单纯的做业务迭代对于技术来说不会有很多的成长,可能一开始还不熟练,等到了熟练以后基本上就是体力活。在过去的很长一段时间里,我接的需求基本上扫一下文档就知道要怎么写了,我也觉得自身的技术达到了某种能感知到的瓶颈。不过我很幸运,在遇到瓶颈的时候有了参与性能优化工作的机会。
刚开始我做的是启动优化工作,这是一个我完全没接触过的领域,不知道各位有没有那种面对一个很着急的事情但你什么都不懂也无从下手的处境。为什么会有这种情况呢,在我看来是因为我离开了舒适区,这是件好事。虽然技术上我不是很懂,不过没关系我可以学。于是我花了大概一周多的时间来研究启动相关的知识并且产出了启动问题分析的文档。虽然这份文档要做的事情以及后来的实验都证明了没什么用处,不过我也算成功入门了。在整个9-10双月里我基本没有实质性的产出,不过我却在技术上有了超大的提升。如果说做性能优化工作前,我技术提升是对数函数的话,那现在的我技术提升大概是指数函数,就是这么夸张。不过在大公司做启动优化有很多困难,首先是接入业务方过多,问题推不动。有一次我想推动开屏广告SDK的同学帮我优化一个问题,他竟然跟我说3个月后才能解决,我的天,那我的OKR都凉透了。其次是AB实验,做启动优化理论上应该提升产品收益,所以启动优化至少不能让产品数据掉,像有些团队说的什么首页数据缓存这种方案根本不现实。最后,在我开始接这个工作前,同事已经优化了一波,干掉了很多大头问题,因此我只能做精细化的优化,对我来说可能10ms的优化都是很重要的事情。在我看来,启动优化这件事情就是理论简单、问题已知、目标明确,但就是很难优化。虽然有这些困扰,但是毕竟是在做工程实践。既然我推不动,那我就自己改,我要是改不了那我就hook。只能感叹这半年写的hook比前两年加起来都多。
后来我对启动优化这件事越来越得心应手,对于启动防劣化服务的报警,我基本上扫一眼trace就能知道哪有问题了。在这个方向上的产出也得到了同事的认可,并且分享了西瓜iOS的冷启动优化方案。想起mentor曾经跟我说过:“头条业务比我们西瓜重,我们至少启动不能比头条慢吧?”,现在确实比头条快了。前段时间也有同事跟我聊到:“你知道我跟你做启动优化的最大区别是什么吗?是激进,你做优化不会担心出什么问题,很激进”。确实,我确实很激进,我觉得这可能也是找我来做这个工作的理由之一?说起来我很喜欢字节的一点,在于它不会因为你是应届或者是实习生就不敢交予你大或者难的事情。但这可能也看不同的人是否能接受,像我就喜欢做有挑战的事情。
到11-12双月时,我开始接起整个西瓜iOS的流畅性优化工作。不得不说,这又是一个极速提升我技术水平的工作。我是真没想到,当初所谓面试造火箭的知识,现在被我用的一干二净。在这个双月里,我对我们的首页进行了流畅性优化,让有点卡的首页变成了不那么卡,没想到竟然取得了显著的产品收益,真是十分有成就感。在我最开始的时候其实是决定对首页进行重构来达到性能优化的效果,不过这个方案被否了,因为成本太高。没办法,面对那一坨屎一样的代码,我所做的工作也只能是在屎上添屎并努力让新的屎看起来好看一些,说起来我倒是挺擅长改造屎的呢。不过一坨屎再怎么改造都是有极限的,现在我差不多已经让这坨屎达到极限了,只有推翻重来才能再提升了。哎,滑动播放的性能问题简直是世界级难题。
现在,在不动列表架构的前提下,优化一个列表的性能问题对我来说非常简单。只要跑一遍instruments基本就能看出问题,然后针对性的优化一下差不多就ok了。流畅性优化对我来说基本上已经没有技术提升了,纯粹是体力活。回忆起19年频繁面试那会,那时无论是技术广度还是深度都会被现在的自己碾压吧,没想到也就一年多的时间我竟然成长的这么快。
不过到了1-2双月,感觉一切都变了。在我换方向4个月后,我发现我手里已经没有那种一眼就能看出有收益的事情。现在的情况正如头条之前所遇到的,叫做品质优化已经进入了深水区,没想到这个转变来的这么快。因此我开始做一些精细化的性能优化工作,比如说针对低端机做性能优化。不过很遗憾,我虽然按照了我的想法开发了许多优化上线,但根据AB实验的结论来看,那就是我在想当然,这真是令人沮丧。接着,我应该是陷入了某种奇怪的节奏中。那就是非常焦虑的想有产出,然后由于焦虑做了特别多的事情,但是做完特别多的事情并没有让我有成就感的产出,接着我就更焦虑。对我来说,仅仅是有性能收益已经满足不了我的胃口,我想要既有性能收益,又有产品收益,这真的很难很有挑战。
另外,在品质工作中的每一个需求都会有特别长的链路。举一个例子,当你决定做一个优化时得先分析为什么要做这个优化,接着开始开发和找QA测试或者自测,最后合码。OK,这对于一个研发同学来说还算好。不过接下来就得等漫长的各个灰度和最后上线,上线完还得开AB实验,实验一般得开1到2个完整周。所以整个流程基本上要有一个月的时间。这大概是什么意思呢?就是假设你需要通过一个优化的AB实验来指导你下一步该怎么做,那你得等接近一个月,真是好强的延迟满足感呢。以前作为业务研发同学,我只需要关注流水线上自己的那几个环节,但现在我作为一个优化项的owner,我必须关注所有环节,而且时间被拉的很长。这样一来就会引入一个问题,那就是做事的容错率很低。一旦我最开始确定有收益的事情在一个月后实际没有收益,那我这个双月定的OKR就没有完成的希望了。
所以在1-2双月里,我为了能够完成我的OKR,我做了非常多的事情试图取得收益。但这样让我精力分散,完全没有进行深度的思考和分析,最终的结果就是我完全没有取得产品上的收益。这两个月的经历让我开始佩服起产品同学,他们一直都是这样过来的吧,作为整个流程的owner,需要去跟各个职能的同学沟通并且推进项目的进展。最后在功能上线后还要等实验结论再继续指导他们的工作。突然能理解为什么他们总是走的比我们迟,我觉得我还有很多地方需要向产品同学们学习。
因为1-2双月的经历和感受,最近我一直在反思,为什么我会陷入这种焦虑的怪圈。我觉得我的第一个问题就是需求前期的分析不足,没有真正的找到问题的关键,并做出强而有力的事情,试图靠数量来弥补质量。我想了想,我觉得这大概就是假努力?做了很多事情来减缓自己的焦虑,实际上没有解决任何问题。举一个例子,我最近做了一个较小流量场景的性能优化,实验结果表明性能优化效果非常显著,但产品指标却有一点点负向。这是为什么呢?经过我对数据的仔细研究我发现用户进入这个页面后基本就不滑动,都不滑动那咋可能因为性能影响体验呢?在这个例子里我觉得我出现的最大错误就是我竟然没能前置的分析出这个情况,我只是因为看到性能数据很糟糕就下意识的认为优化性能问题就能取得产品收益。如果我在动手之前全方面的分析一下,我是不是就不用耽误这么多时间了呢?前段时间我听了头条那边一位同事的品质优化分享,我发现她的数据分析能力真是太强了,我完全被她的能力所折服。我感觉我在能力上跟她的差距,比我跟猪的差距还要大,这应该就是我想拥有的能力水平吧。
我的第二个问题就是推动力、规划能力不足,导致工作方案局限在我一个人能完成的范围内。随着品质工作时间的变长,我越来越发现职场中的软素质与硬素质(技术能力)一样重要。我认为作为一名软件工程师,技术只能决定我的下限,而软素质能决定我的上限。技术固然重要,但是在工作中并不能靠自己单打独斗完成所有事情。我很享受一个人能完成所有角色的事情,这样拥有极高的效率,因为都是脑内交流。如果一个需求需要多个人介入,那就需要花费很多时间在沟通上。而我现在往往是是一件事情的owner角色,为了达成目标,我还需要去推动其他同学跟我一起完成这个事情,对我这种嫌麻烦的人来说简直是让人糟心,从内心就有些抗拒,我觉得我需要克服这个毛病。克服了嫌麻烦的心态之后,我还得学会如何推动别人,因为合作总会遇到很多推不动的情况,或许是我没有让对方意识到做这件事的价值或许是我推动的方式不够合适,这也是我需要持续学习的地方。在规划能力上的不足,具体表现在我不知道如何在多人合作的场景下去拆解一个大事情,或者说知道要如何完成一件事,但我不知道要如何和别人一起合作完成。比如确定方向、分工和确定里程碑等内容,我完全不知道怎么开始怎么协调别的同学。仔细一想,可能是因为我工作经验还不够,我相信只要我确实的做过一次这样的事情我就能学会它。
总结一下,这半年工作让我意识到的事情。第一个是需要让自己的焦虑稍微平静一下,不要因为急于想要有产出而失去判断力。第二个是需求前后思考两个WHY,做需求之前需要进行充分的分析,为什么要做这件事,是因为什么样的数据或者理论支撑了做这件事的理由。在出来的实验结果也需要仔细研究为什么我的方案会得到这样的数据变化,要针对数据变化归纳出原因。第三个是丰富自己的方案思路,不要局限在只能自己一个人完成的领域内,要多与他人合作,从而能够锻炼到自己的软素质能力。最后,数据分析能力真的很重要,需要多锻炼,提升数据的敏感度,学会看数据,从数据中发现问题。
本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!