年终总结我的 2021 年终总结

debugtalk · 2022年02月06日 · 最后由 debugtalk 回复于 2022年02月10日 · 6203 次阅读

还有几天就要到农历新年了，堕落到一年一更的博客也不好意思再拖延了。按照老习惯，先翻出去年的年终总结看一遍找点感觉，然后在幕布上分维度罗列下要点和关键词，再大致整理下思路，开写！

这里也提前说明下，我的年终总结更多的是记录自己一年来的经历和思考，内容比较多且杂，大家挑选感兴趣的部分看看就好，也欢迎大家在评论区多多交流。

工作

在 2020 年六月，我从深圳字节转岗到了成都互娱研发部门，转眼间在成都已经工作了一年半时间了。整体来说，在成都工作和之前在深圳广州工作并没有感觉到太大的差异，我对现在的工作内容和工作状态的也挺满意的。

在工作方面，我个人 2021 年最大的关键词就是「ToB」和「从 0 到 1」了。但回顾这一整年做的事情，最大的问题还是投入方向比较零散，走了些弯路，好在下半年逐步进行了聚焦，目标也清晰了许多。这里就挑几个投入时间相对较多的方向进行下总结。

测试任务调度

在年初的时候，我们专项团队在成都只有两个人，另一个同学跟我还不是一个方向的，因此整个上半年我基本还是延续 2020 年的工作内容，做测试任务调度相关的技术框架建设。只是相比于 2020 年，今年更多是提升服务易用性和可用性，实现更多的业务落地。

在服务易用性提升方面，考虑到通用的任务接入方式（shell/python 脚本）存在一定的使用门槛，因此集成了几种常用的专项能力，包括 Web/H5 场景化测试、Fastbot 稳定性测试、shoots UI 自动化测试等，并且新增支持了调度执行 gitlab 仓库的能力，这样就可以将用户跑在内网的测试工程无额外成本地调度运行在全球各地的边缘节点。在服务可用性提升方面，主要是完善了核心指标体系，实现了通过看板准确度量任务成功率和明确 top 异常问题的「数据驱动」研发能力；并且新增了多项问题定位辅助工具，提升了关联服务 auth 同步、RPC 调用等异常问题的排查效率。而在业务落地方面，主要就是作为任务调度中台，与相关合作方进行协作共建，稳定支撑了内外部近十个专项测试平台。除此之外，还做了些软能力的建设，包括优化项目管理机制、推动实践 monorepo 开发模式、解决各模块 code review 流程标准不统一的问题。

总体来说，这部分工作还是面向公司内部，算是常规意义层面的测试开发工作内容。

ToB 探索

在去年年初的时候，我们专项团队在公司内部完成了 ToB 产品立项，业务方向主要做是数字体验监测（DEM）。用一句话进行概况，核心就是利⽤分布在全球各地的真实设备和真实⽹络，模拟⽤⼾的真实⾏为，采集体验相关数据，提供体验问题发现，智能归因及报警服务；详细内容可看下这篇介绍文档。

为什么一个测试开发团队要去做 ToB 的事情？原因是多方面的。从国内大环境来看，ToC 市场已经基本饱和，接下来十年在 ToB 市场会有更多的机会，各个大厂都在加大 B 端市场的布局和投入。字节公司层面也十分鼓励内部将技术中台能力对外开放，因为内部技术平台需要有更高的标准，光是内部反馈说好还不够，能走出公司收获市场的认可才是真的好。而在我们团队内部，leader 是一个连续创业者，对 ToB 具有非常大的激情和决心，在他的感染之下，我内心深处的创业热情也被激发出来了。还记得之前我在大疆的时候写过一篇文章《如何度量测试开发的价值产出？》，作为测试开发角色，工作内容和形式很多时候跟创业很像，我个人也一直是以创业的心态来对待自己的工作。而现在我终于可以有机会真正地参与到商业化 ToB 从 0 到 1 的创业过程，我自身也是兴奋不已。

兴奋归兴奋，真实的 ToB 探索路阻且长。虽然我们的产品在年初就通过了立项，而且已有的工具平台在公司内部已经持续支撑了抖音、头条和众多明星出海业务，取得了非常多的价值收益，但要实现对外开放试用，还有非常多的工作要做。安全合规改造是最重要的一项，包括隐私合规要求梳理、开源组件 license 梳理、法务流程审批等等。而在技术层面，需要将之前部署在字节云的系统迁移部署到 K8S 云原生的火山引擎，那么针对字节云特有的内部特性就需要进行改造重新实现；同时在国际化机架和边缘节点设备层面，需要在保障资源复用的前提下，解决 ToD/ToB 环境和资源隔离的问题。

除了安全和技术方面，最头疼的还是产品设计层面的问题。说实话，公司内部的测试平台大都是面向内部技术人员，甚至有些还只是给自己使用，更多还停留在技术工具层面，距离目标用户「好用」「易用」「爱用」的产品还有相当大的差距。哪些是我们的目标用户？用户的痛点是什么？关注点在哪里？使用场景是什么？使用习惯如何？这些都是作为一个商业化产品需要进行关注的，也是我们团队当前充满未知的。比较好的方式，就是尽可能早尽可能多地触达外部用户，特别是针对一些重点 KA 客户，可以通过线下拜访和免费开放试用的方式来收集反馈。

然后我就开始兼职做商务和售前的角色，从 5 月开始跟团队的相关负责人一起到客户现场进行交流，包括大疆和多家知名出海企业。后面再借助公司和团队成员的资源，我们团队全年累计触达了 20+ 个 KA 客户，覆盖了政府、泛互联网、游戏、金融、运营商、车联网等行业，并初步与一些生态合作伙伴建立了合作。我也借此机会又回到了老东家（大疆和工信部电子五所）的工区，熟悉的地方，熟悉的同事，甚是亲切。在这里也非常感谢各位前同事和合作伙伴们，在交流的过程中给予了我们较多的反馈，为我们的复盘改进和调整产品方向提供了很大的帮助。

经过接触外部客户，我们发现部分产品方向和很多客户的需求存在一定的 gap。例如，网络性能体验对于字节的产品非常重要，提升 0.5% 就会产生非常大的经济收益；而对于一般体量的用户公司来说，提升网络性能体验的 ROI 很低，相比下来，提升研发过程中的测试覆盖率、解决功能性 bug 是更高优的事情。又比如针对服务可用性监测，我们的产品优势在于全球化 150+ 国家地区的主流机型和当地 WiFi/3G/4G/5G 真实运营商网络链路的覆盖，而客户通常不需要这么细粒度的真实环境，对于他们来说找几台 AWS 服务器部署个脚本监控主干网就够了。这里存在的矛盾点就在于，对于大多数中小企业来说，用户体量还比较小，业务量级还没到关注数字体验的阶段；而体量已经很大的公司都不缺资源，基本都倾向于自己建设。

其实上面的 gap 还是很好理解的。参考马斯洛的需求层次结构，客户对软件产品的需求大都也会遵循一定的金字塔层级模型：功能（接口/UI）、性能这种处于金字塔底层，用户需求肯定是最多最普遍的；而体验、本地化、安全合规这类需求处于金字塔顶端，用户受众会少很多。当然了，用户的需求也不是一成不变的，他们在满足底层需求以后也会逐步关注上层的需求。但我们之前存在的问题是产品只专注于数字体验、本地化、安全合规这些处于金字塔顶端的需求，而对于最广泛的接口/UI 功能、服务端性能这些能力完全没有投入，这就会造成我们直接对最广大的用户群体关闭了大门，继而错失了转化用户的机会。

一不小心 ToB 探索这部分就写了好多，但实际需要考虑的因素还远不止这些。对于 ToB 而言，产品和技术本身并不是全部，营销获客效率、行业领域特点、用户付费意识、客户决策链路等等，这些都是需要去重点关注的维度。在整个探索的过程中，遇到的挫败会非常多，拿热脸贴冷屁股也是常有的事儿，但这就是最真实的商业化世界。虽然有时候我也产生过自我怀疑，但我还是非常感谢能有这样的学习和锻炼机会，可以让自己获得更全面的成长。幸运的是，部门对 ToB 这件事儿并不急功近利，也没有给我营收压力，而是立足长远，坚信做有挑战的事情、提升核心能力、锻炼有战斗力的团队，才是我们最核心的目标。

差不多到了 9 月的时候，经过多次沟通，我这边重点投入到了 XX 性能检测工具（基于 HttpRunner+）和体验评测报告这两个方向。

XX 性能检测工具（基于 HttpRunner+）

先说下 XX 性能检测工具，这其实也算是机缘巧合，我们发现面向 XX 领域做性能测试工具可能存在一些机会。具体领域这里先保密，产品形态基本上可以理解为是基于 HttpRunner+ 做的一款简单易用、功能强大的桌面客户端压测工具。

为什么选择 HttpRunner 呢？

说来惭愧，之前因为工作方向变动的原因，我已经快一年没有投入到 HttpRunner 的开发了。但我惊喜地发现，HttpRunner 已经有了较大的用户基数和知名度。在搜索引擎中搜索 HttpRunner 时，除了我之前写的教程，还可以搜到很多用户自分享的文章，甚至还有培训班以此开设了付费课程，以及有人写书时以较大篇幅对 HttpRunner 进行了介绍。在抖音中搜索测试工具关键词时，我也在多个视频中看到有人提到了 HttpRunner。这些反馈给了我极大的鼓舞，同时我也觉得大众对于 HttpRunner 的接受度较高，而且已有的品牌效应不能浪费，运营好 HttpRunner 可以帮助我们触达更多的用户群体。

然后在功能设计层面，HttpRunner 的一个很大的优势是采用了约定大于配置的思路，脚本是结构化的，方便生成和转换，因此可以非常方便地与其它工具进行集成。而且 HttpRunner 本身支持接口测试和性能测试，那么基于 HttpRunner 就可以快速开发出我们的目标性能测试工具。不过，既有的 HttpRunner 可能还没法直接满足我们的需求。因为我们的核心目标是要做一款性能测试工具，对于发压能力和数据准确度具有非常高的要求；而之前的 HttpRunner 是基于 Python 开发的，性能测试部分使用的是 Locust，其单机发压能力和数据准确性都存在较大的问题。

经过短暂的思考后，我打算采用 Golang 重写 HttpRunner，这也就是现有的 HttpRunner+（hrp）。选择 Golang 替换 Python，这里面的确有我个人的技术偏好，但可以明确的是，采用 Golang 开发的 hrp 相比于原有的 Python 版本，在保持使用方式基本不变的前提下，功能会更加丰富，运行更稳定，并且性能更强，也更易于部署使用。

下图罗列了 HttpRunner+ 从 9 月开始开发至今已经实现的功能特性，以及近期要完成的重点功能特性。可以看出，当前 golang 版的 hrp 已经在功能上基本追平了 Python 版的 HttpRunner，并且在性能测试方向增加了许多 locust/boomer 缺失的特性。

限于本文重点，这里就不再对 HttpRunner+ 进行过多介绍了，接下来我将会重点补齐用户文档后，再通过多个渠道进行下宣传介绍，后续也将加强下针对 HttpRunner+ 的运营和用户支持。

额外再补充一句，HttpRunner+ 将永久开源，并且保持以 Apache-2.0 的开源协议，商业友好，大家完全不必有任何顾虑。相信后续 HttpRunner 在获得商业化支持后，会有一个更持续、稳定的发展。

体验评测报告

而投入体验评测报告方向，主要有两方面的原因。

一方面，抖音作为短视频头部产品，用户体量巨大，轻微的体验指标劣化都会导致严重的经济损失，因此对各维度核心指标的关注度极高。我们作为抖音部门的专项测试团队，承担了对抖音等核心产品的体验监测和评测能力建设工作。例如，近期我们成都团队就重点针对行业内的 top 30 短视频应用的 5 大核心指标（首帧、首刷、卡顿率、卡顿时长、帧率）进行了横向评测比对，在此过程中建立了初步的评测能力，包括自动化数据采集能力、标准化算法识别能力、数据标注能力等。在未来，我们团队除了会不断优化短视频评测能力外，还会拓展评测范围，包括音视频、网络等技术维度，覆盖更多行业领域。这些能力除了在内部支撑业务解决评测问题外，我们更期望将技术溢出到外部，对外提供商业化服务。

另一方面，选择测评报告的服务形式，还可以解决我们之前遇到的一个困境。

前面在 ToB 探索部分有提到，已有的内部工具平台还不算是成熟的产品，对外部用户而言并不友好。在这种情况下，我们需要对已有系统进行重构优化，甚至要在产品层面进行重新设计。这个周期会比较长，那么怎么避免我们的重构不是内部自嗨？怎么确保我们新的产品设计是用户期望的？能切实帮助用户解决问题呢？

经过内部讨论，我们决定先通过评测报告服务的形式来触达用户。因为回归数字体验监测最终的需求目标，用户也并不是为了多一个好用的平台，而是可以借助平台能力获取到关注的数据指标，挖掘出可能存在的问题，进而产出相应的评测报告。在这个逻辑下，平台并不是必须的，最核心的还是我们的数据产出能力和问题诊断能力。

因此，我们在短期内可以先以提升报告交付效率为目标，构建稳定的行业评测报告能力，持续产出高质量的行业评测报告。更具体地，如何获取更全面的数据，如何更高效地采集数据，如何保障数据的准确性，如何在海量数据中提取出关键问题，挖掘出系统可能存在的问题，这些都是我们需要解决的最核心的问题。在解决这些核心问题的过程中势必会倒逼我们不断去优化底层的数据采集能力、服务稳定性、提升标准化算法能力和数据标注能力、问题分析诊断能力等等。

通过这种方式，我们就可以比较好地确保我们团队始终走在正确的道路上，并且以此来通过更低成本、更高效率的方式触达目标客户，收集客户反馈，进而逐步打磨我们的 SaaS 服务，驱动我们整个数字体验监测产品体系的迭代和演进，并逐步形成面向跨境电商、出海游戏、金融、电信、音视频等行业领域的整体解决方案。

在此也打个小广告，如果你所在的企业具有相关评测需求，欢迎联系我，非常期望能在新的一年和大家一起搞事情。

团队建设

除了 ToB 工作的从 0 到 1，成都团队今年也可以说是经历了从 0 到 1 的建设过程。年初的时候还只有我一个，到年末的时候我们团队已经有 9 个人了，研发、产品、测试的角色也基本都凑齐了。

得益于 leader 的信任，我同时担任了所有新人的 mentor（3 社招 + 5 校招），刚开始压力还是蛮大的。特别是在 7 月初的时候，同时入职了 4 位校招生，如何帮助这些新同学快速融入工作和团队也是一个比较有挑战性的事情。我自身呢也不喜欢管得太细，更多还是尽量做好背景同步（为什么做）和目标明确（要做成什么样子），然后就在关键节点给些反馈，唯一卡得严格些的就是 code review 了。新同学们都很给力，很快就进入了工作状态。后面在两位社招同学的热心协助下，我又可以有时间可以继续写代码了，哈哈。

在工作之余，我们团队氛围也特别融洽，平时午饭晚饭都会聚在一起吹水，饭后就在工区边上遛会儿弯儿，没女生在的时候偶尔还会在某人的带领下高低整两句（工牌已摘）。今年我们搞了两次稍微远点的团建，去融创滑了一次雪，去峨眉山登了一次金顶，计划明年再自驾走一趟川西小环线。成都因为没有车牌限制，因此成都团队的人均车辆数在整个团队中是最高的，再加上成都周边玩的地方确实多，自驾游的选择多了不少，后面还可以再打开下想象力。（此处是不是应该插入个招聘广告）

哦对了，今年我还有幸完成了字节技术学院「导师辅导技巧」精品课程的学习和认证，成为公司该课程首批次 30 位认证讲师之一（成都唯一一位），并面向成都 3 个研发部门的近 50 位新 mentor 进行了现场授课。从反馈的满意度评分来看还可以，但我自己也知道，知易行难，自己在辅导新人方面还有太多要提升的地方。新的一年继续加油！

生活

再说下这一年的生活方面。

2021 年，是我离开一线城市，在成都工作的第一个完整年，整体感觉还是挺好的，我也挺庆幸当时做出的决定。

购房

首先是住房方面，今年我总算把购房问题解决了。成都毕竟是二线城市，平均房价不到深圳的 1/5，从一线城市回来还不是降维打击，随便买么？嗯么，我刚开始回成都的时候也是这么想的，将之前在广州郊区的房子卖了以后当首付，在成都还是可以有很多选择的，因此还一度膨胀过，跟老婆去逛过各种 top 板块的豪宅，麓湖生态城、天新 F4、成都金融广场（CFC）等等，涨了不少见识。后面随着有了更多的了解，我们也逐渐开始清醒了，房子终究是买来住的，相比于高大上，还是位置便捷 + 资源成熟来得实在，高新区对我们来说才是最合适的选择。然而超出我们预料的是，高新区竞争太激烈了，成都人民也太有钱了，按照成都的顺位购房规则，我们这一年出头的社保时长基本上无缘稍有剪刀差的楼盘。特别是在经历了报名凯德世纪名邸苦等十来天结果摇号池都没进以后，我们基本上醒悟了，再好的楼盘买不到等于零。于是我们又进一步将注意力锁定在高新区总价最高竞争相对没那么激烈的三个新盘，中洲锦城湖二期、合景泰富臻林、成都金融广场（CFC），想好的策略就是哪个先开就报哪个，然后就听天由命看运气了。回顾整个心态变化历程也是挺有意思的，从最开始「随便挑」的膨胀，到后来「只求买到」的卑微，只能说自己还是太年轻了。

然后大概在三月的时候，合景泰富臻林开盘了，就是之前传说的中英双语管家主动式物业服务的那个楼盘，价格开的是政府限价的最高价，单价差不多 3.4 万的样子，跟周边二手房基本上没啥剪刀差。而且这个楼盘渲染的逼格很高，总之就是要贵，物业费 8 块一平，停车位的物管费也要 180 一个月。再加上公摊面积高，中庭小的问题后，楼盘的追捧度并不太高。从内心意向来看，这个楼盘是我们的第三选择，但经过短暂的纠结后，这可能是我们机会最大的一次了，与其继续等待其它两个不知道啥时候能开的楼盘，还是先报名这个吧，万一还摇不上呢，毕竟只有 1/3 的概率。然后我们就冲了，然后就摇中了，然后就想着一步到位梭哈 180 平了，然后就背上了 400 多万的贷款，兜里全空了。说到这里，又不得不吐槽下成都的房贷利率，商业贷款首套利率都达到了 6+%，不懂金融的我们刚开始还没啥感知，后面每个月要还两万三的月供时才惊觉，没法躺平了。

不过现在回过头来看，幸好当时还是选择下手了，另外两个盘至今开盘还没影儿。再多说一句，成都的房价相比于两三年前涨了不少，要是早回来两年，房贷至少省一半，所以说还是选择大于努力啊。但不管怎样，今年总算了却一件心事，接下来不用再继续关注房子的事情了。

小坚果

今年小坚果满 4 岁了。到了这个年龄阶段，小坚果的问题就多了好多，并且总是喜欢刨根问底。

小坚果：我是怎么来的？\
妈妈：你是爸爸的小蝌蚪游到妈妈的肚子里，然后在妈妈的肚子里孕育长大的。\
小坚果：那爸爸的小蝌蚪是怎么进入到妈妈的肚子里的？\
妈妈：。。。

小坚果的交流能力已经很流畅了，而且在跟他聊天的时候，经常会震惊于他的想法。之前我跟他妈妈都要去上班，他在家自己觉得不好玩。后来就跟我们说，想让我跟他妈妈在家陪他玩。但是我们要出去上班挣钱钱啊，没有钱钱就没有饭吃。然后他就说那就让奶奶和外婆去上班吧。。。

还有一次，妈妈让小坚果学习瓜瓜龙英语。小坚果就问为什么要学英语啊？他已经表现出一些偏好了，更喜欢学习瓜瓜龙思维（数学）。妈妈就说，学了英语就能去国外找瓜瓜龙玩了呀。「可是，瓜瓜龙也可以说普通话啊」。呃么，挺有道理的，看来全球普及中文就靠下一代了。

今年小坚果开始去上幼儿园了。刚开始他还挺开心的，但上了一段时间后，他就不怎么喜欢去幼儿园了。问他为什么，他就说「幼儿园就是吃东西和睡觉，也不学习，一点都不好玩，要不是可以挣钱都不想去了」。原来他一直以为自己去上幼儿园就跟我去上班一样，是可以挣钱的。哈哈，这么小就展现出学霸潜质了，还知道为家里分担负担了。

小云朵

今年我们还干了一件大事儿，积极响应了国家号召，后续要新增一个小云朵板块啦。

不得不说，二胎跟一胎相比，关注度低了好多，应该是我们已经习惯了爸爸妈妈这个角色。我老婆说，之前怀小坚果的时候，会经常通过宝宝树看宝宝长多大了，而现在有时候甚至会忘了还怀了一个宝宝。我也有点担心，怕以后小云朵出生后，我写不出像跟小坚果那么多煽情的点滴了。

回到成都以后，我们实现了私立医院自由。之前在深圳的时候，压根没敢想过去私立医院，每次去公立医院产检都挺多人的，体验很不好。而这次在选择医院的时候，我们发现成都的私立医院并不比公立医院贵多少，但环境和服务要好太多了，医生也是慈眉善目、轻言细语，耐心特别好，平时有事儿还可以通过微信及时进行沟通。

一些阴霾

成都整体环境都挺好的，但就是阴天比较多，很少能看到太阳。成年人的世界也没有容易二字，只是大多数时候我们选择只对外展示阳光的一面，而将阴霾留给自己。

今年，我老婆和我的奶奶接连去世了，我奔了两次丧。老婆的奶奶是一个特别慈祥的老太太，我虽然跟她接触不多，但每次看到她的时候她都是笑呵呵的，给人一种很温暖的感觉，小坚果也特别喜欢她。去年春节的时候，我开车走的时候还跟她打过招呼，没想到清明节后她就走了。庆幸的是，她身体一直挺硬朗的，走的时候也没受罪。而我的奶奶就没那么幸运了，她之前因为脑溢血患上了半身不遂，在轮椅上瘫坐了近十年，走之前那段时间也是异常痛苦。小时候我爸妈在外打工，我就跟着我爷爷奶奶一起生活，我奶奶基本上算是跟我一起生活最长时间的亲人了。她学着写自己的名字给我作业签字，她去我的学校参加家长会，她打着手电筒到处寻找在外贪玩夜不归宿的我，而今年，她就这么走了。

同样是今年，我爸妈的关系基本破裂了。起初我也尝试过劝和，但随着了解得越多，我越发地感受到无力感，两个人走到今天并不是一时的矛盾，而是长年累月的问题积累。双方都有各自的问题，又缺乏好的沟通方式，导致最终都以寒心收场。也许，他们分开以后可以各自过得更好。作为子女，我尊重他们的选择。

因为见证失去，所以更懂珍惜。我能做的，就是给家人更多的耐心和理解，人生苦短，家人永远是最重要的。

个人思考

说完了工作和生活，再来记录下这一年一些零散的想法。

35 岁焦虑

又是「35 岁」这个话题。不得不说，互联网人的确是最容易焦虑的一个群体，在网上经常可以看到相关的问题，「35 岁以后还能找到工作么」、「35+ 还有出路么」、「35 岁还没升到 leader 还能混下去么」等等。

在当前国内的大环境下，这的确是一个短期内「无解」的问题。公司的目标是盈利，那么势必就会考虑 ROI 和性价比。近些年因为互联网有一些行业红利，IT 从业者的收入相比于传统行业有一些优势，导致很多只要跟计算机、软件沾点边的专业的毕业生都在应聘互联网岗位，甚至还有很多其它行业的人也会通过培训转行进入互联网行业。而在国内普遍都是应用层 CRUD 的现状下，一个应届毕业生基本上 3 年就能成长为技术骨干，很多 5 年差不多就开始带团队了。那么在这种供需关系下，企业还有必要花费两三倍的价格去招一个 10 年 + 的员工来干差不多的活儿么，毕业三四年、无家庭牵挂、听话好管还便宜的年轻人他不香么。

这话听上去是挺残酷的，但这就是当前国内的市场现状。但另一方面，即使是在成都这样的二线城市，我们也可以在招聘网站上看到很多企业花费 50k+ 的薪资招聘各种技术专家，而且这类需求还特别多，一直处于招不够的状态。从我自己待过的公司来看，这也是当前真实的现状，高级的专业技术人才在哪里都是供不应求的。因此回归招聘市场需求，它并不是缺人，而是缺在特定行业领域有深厚积累的专业人才。

想清楚这些点以后，其实也不用再对「35 岁」感到焦虑了，因为焦虑也没有用。我们能做的就是提前做好个人规划，让自己年龄大点以后不至于变得那么被动。如果自己就是想躺平，对技术没兴趣，那么就提前找好退路，或者降低自己的心理预期，既要舒适又要高薪还要稳定是不太现实的。而如果自己本身就很热爱这个行业，喜欢技术本身，那么就多投入，把自己变得不可或缺吧。当然了，这里说的「多投入」也并不是拼加班，陷入低级别内卷是无意义的，而是我们要尽量去做有挑战性的事情，不断提升自己的技术视野和能力积累。

我的未来方向

还有一年多我就要满 35 岁了，我未来的方向在哪里呢？

还记得在我的 2018 年终总结中，我就写过关于技术和管理两条路径的选择，关于个人职业发展路径的困惑。现在回过头来看，当时自己的格局还是小了。因为所谓的「35 岁失业焦虑」、「技术还是管理」、「职级晋升」，这些归根结底还是停留在打工的思维，将主动权给到了企业，而不是握在自己手上。

那要是我们跳出打工者的思维呢？杨震原在一次 All-hands 面对面中分享过一个主题，《成长是自己的事情》，里面提到的一个观点我十分认同，「不管你做什么样的工作，实际上你一直在创业；在公司内部工作就是在公司内创业，在公司外部就是在社会上创业」。如果把我们团队当作一个创业公司，从成本来说，这又何尝不是从投资者拿到的风险投资？那么我们要达成怎样的目标做出怎样的成绩才能说服投资方持续投入，甚至加大投资规模？

这其实就是创业者需要重点考虑的事情，关键还是要以创业的心态进行思考和做事。我也非常喜欢当前所处的工作状态，在拿着还不错的收入的同时，还可以做着 ToB 探索的事情，不断提升自己的技术视野和积累行业经验，这是多么好的成长锻炼机会啊。那么在多年以后，当我自身的综合能力处在一个更高的位置时，与其被动等待公司或团队的工作安排，我已经能主动追寻自己的事业目标了。

在转换思维以后，再回过头来看自己的未来发展方向，可能性就会变得非常丰富多彩了。也许，我可以做一名独立开发者，按照自己的想法做产品，感受来自用户的直接反馈，要是能看着用户量自发地增长那就再开心不过了。也许我还可以做一个技术自媒体，写技术文章，出版技术书籍，做技术咨询，将自己的技术积累以通俗易懂的方式触达更多读者。或者我也可以专职投入到运营开源项目，探索开源项目 + 付费服务的商业化模式。当然啦，留在字节继续打工也是一个非常好的选择，可能是做一个沉浸式的技术专家（码农），也可能是做一个项目负责人或技术团队 leader。

总之，我期望选择权掌握在我自己手里。

对 ToB 的一点思考

我今年才开始正式投入 ToB 的工作，对 ToB 的认知层次还挺浅的。不过经过短暂的犹豫后，我打算还是把自己关于 ToB 的一些不成熟的思考记录下来。相比于前面 ToB 探索部分的内容，这里的想法会更偏宏观一些。

我们 ToB 应该选择什么产品方向？我们的目标用户群体在哪里？

回归 ToB 的本质，是面向企业提供服务。而企业的首要目标，永远是挣钱（盈利），而且是持续稳定地挣钱。从这个角度来讲，ToB 服务就应该聚焦于如何更好地帮助企业用户挣钱盈利。那如何实现盈利呢？无非就是「开源节流」。开源，指的是帮助企业提升产品能力，扩展市场规模，支撑企业更好地服务用户。而节流，则是帮助企业更好地提升内部效率，缩减人力资源成本。除此之外，还得考虑「持续稳定」，解决企业用户可能存在的风险，避免在遭受极端风险时受到巨大的损失。

这里举一个更通俗的例子。市场上有很多金矿，企业就好比是一个个掘金者，只有持续挖到金子才能存活和发展。那作为 ToB 服务者，就应该是帮助掘金者更好地挖矿。「卖铲子」是一个方向，给没有铲子的掘金者提供铲子，或者帮助已经有铲子的掘金者升级为更高效的挖掘机，这既可以算作是开源，也可以算作为节流。另一方面，掘金者要想保障业务的持续稳定，还需要关注安全合规，否则可能因为一次安全事故遭受大额罚款甚至关停，这也是 ToB 服务者可以重点考虑的方向。

再回到我所在的质量或体验这个业务领域，我们的 ToB 机会在哪里呢？一个比较尴尬的现状是，当前质量这条线在大多数公司内部都是成本部门，跟企业的盈利很难产生直接关联。也是基于这个原因，当前很多公司内部的质量部门都喜欢提「业务价值」，搞「价值度量」，算「价值收益」，因为只有这样才能体现出质量团队本身的价值。在这样的大环境下，帮助企业更好地降低测试门槛、提升测试效率、追溯质量问题、度量测试价值，应该会是较为普遍的需求。这些都算是「节流」的范畴。

那我们有没有可能支撑企业进行「开源」呢？其实也是可以的。首先，我们可以先重点关注下通过测试业务来挣钱的企业。例如，第三方测评机构就是一个典型的目标客户群体，他们主要通过提供第三方测评服务、出具测评报告来获得产值。帮助测评机构更低成本、更高效率地开展测评工作，可能会是一个机会。其次，我们可以关注下哪些行业客户的系统性能、可用性、安全合规等因素，会严重导致客户的收益损失。例如银行证券类客户，银监会对这类网站的性能和服务可用性有明确要求，出现问题后可能会导致评级降低，甚至领导被追责。又例如出海类的企业，出海产品会面临欧美的强监管政策，安全合规方面稍有不慎可能会面临高额罚单甚至产品下架。如何帮助这些客户更早、更快地发现问题，甚至帮助客户在源头上避免出现这些问题，助力客户的业务「持续稳定」地发展，也会存在较多的机会。

归根结底，ToB 的核心还是要为客户提供价值，帮助客户解决痛点和问题。