从 22 年入职字节、选择了一个对自己来说完全陌生的“监控”领域和“APM”团队，就这样开始了几乎每一天都是充满新鲜感、充满挑战的日子。整个团队当时有几块业务：对前端同学来说最核心的是“前端监控平台” Slardar web (对外的上云版本是 Apmplus) ，其次是 iOS/Android 端监控平台，另外还有后端监控平台 “云监控(对外)、Argos平台(对内)”。我入职当时作为团队(近三十人)内除了主管之外最资深的同学，就承担起了主管最关注的 Slardar web 这个由前端自己掌控的前端监控平台。我虽作为平台的 owner、但本身对这个领域完全陌生，内心其实是有些不安的、于是边学习边承担起各种“力所能及”的工作。
一些亮点
入职前三个月，投入了超过 1/3 的时间帮助主管招聘，跟阿里蚂蚁做监控的同学轮番聊、找熟人介绍并在微信群里发广告、沟通或接触了近百人。进入面试流程的有十多个人，进入终面的4个人、最终有2个人顺利入职(一个人在其他部门)，当时一共超两千人的基础架构大部门、每双月公开通晒“招人光荣榜”，个人荣获了第五名、并获得了一个小米电纸书的奖品，整个APM团队也只有我榜上有名。
入职不久、上级大前端团队开始组织发行<架构前端双月刊>，我担任了我们APM团队的“接口人”角色，平时跟进各期的稿件“收集对接或review宣传”任务。在期刊的第五期、轮到我们APM团队“制作刊文并做宣发”，刊文要求有最近半年原创的涵盖各个子主题的共计14篇文章。我作为负责人：
- 设计和确定了 “智能可观测与开源”、这个能起到宣传团队作用的刊文主题，进过多轮修改优化、书写出三百多字的 开篇词 并录制成了视频。随后在大团队季度大会上的双月刊工作环节，播放了我录制的开篇词视频。
- 制作过程中需要到处看各兄弟团队近百篇的分享和文档、最终从中筛选近七篇存量优质文章，并跟人约稿了3篇全新文章。
- 发行后、对本次期刊内容的匿名投票环节，收获到了16人的全五星好评，反馈结果最好 (目前为止双月刊一共出品了10期、他们都有四星评价)。
- 另外在今年初的年度总结-双月刊优质文章排行榜上，在阅读和点赞量上霸榜前两名的、都是出自我们APM团队 (也有我帮助出版的一点功劳~)。
说说业务和个人角色
开篇提到我入职后负责“前端监控平台” Slardar web，这个产品在我入职之前半年多(约2021年8月)有过一次全新改版、而且当时产品理念也是比较先进的，其中一大亮点是抄了 Datadog 的 Sessions Explorer 功能、改名叫数据探索。但是产品的整体信息结构跟阿里或其他外部的监控平台很不一样，这点对有经验的监控人来说、可能很快会能理解，但当时作为领域新人的我、却有很大的困惑。
比如为什么“JS/性能/API请求/静态资源”等监控类型和这个“数据探索”综合性功能、在信息结构上是平行的？虽然产品上有互相的链接跳转、但也没有文档说明他们之间的关系，其实有不少新用户也有类似的疑惑、不能非常直观地理解这里的逻辑性。又看了一下改版之前的产品，发现这是综合考虑到“B端产品交互风格的渐进延续性、以及用户的教育成本或接受度”等因素后的一个折中的结果。
但时至今日个人仍然觉得，虽然 “抄了个好功能、但没抄出好产品”，当时即便不做大的信息结构变化、也能有更合理的产品设计。但很遗憾的是这种能体现 产品匠心 的时机已经错过，虽然想做优化 但排不上优先级、也很难让别人感受到价值。
除了产品信息结构对新人不友好外、雪上加霜的就是文档写的不太及格(程序员都不太爱写文档~是真的)，这个产品因为是前端在负责、只是在大的改版阶段才有专门的产品经理跟进，改版上线后就没有专门的产品经理了。我接手后、就担当起了产品经理职责，优化文档、变身最主要的oncall(客服)负责人、参与几大业务线的bp(需求对接)。
我做了一个产品经理应该做的工作，而且也拿到了 文档易用性、oncall数量减少 等不错的结果数据，并且对工作过程、也做了比较详细的文档记录。从过程到结果都证明了自己的付出和能力，但这个事情的价值、可能更多只是锦上添花。
虽然对 产品各处细节的打磨 看起来应该是专业产品经理的责任，但实际是需要专业前端来做的。 专业的产品经理、因为可能没有前端背景，更多是把控产品整体的设计、在大的产品改版或跨产品统一功能设计上体现价值。
除了兼职产品经理外，我作为业务和产品的owner、还要承担加倍的全面的责任和工作内容，比如：
- 首先要对团队内一起协作的五个同学(全是96后)的工作、能深入理解并有所帮助，组织每周例会。
- 前期很多精力在产品优化上、代码产出较少，主管提醒要体现代码产出、就要加班了解并修复些代码细节问题。
- 刚入职一个多月、很多东西还没来得及搞清楚用起来，就接到一个很有挑战的功能“Issue管理”、让我设计并实现出来证明自己的能力。
- 团队外协作和团队规划：承担“架构前端双月刊”的接口人职责；邻近年底需要组织 竞品调研 和新年的 年度规划。
- 合作的后端同学是外国人(完全不懂中文)，多数时间只能借助翻译软件艰难沟通、效率较低。
- 虽然也花了时间学说英语、但在沟通需求细节时 有很多弯弯绕绕的逻辑、用中文都要仔细组织语言才能说清楚、用英语就更麻烦。
其实上述的这些工作，回头看相当于一个人、同时承担了 “产品经理 + 一线研发 + 团队半个管理者 + 破局” 的几重责任和任务，整个过程真的是又累又难！但其中最难的就是“破局”责任了。面对这么个复杂的产品，我作为这个领域的新人、一开始难免理解不深，后来发现当时的产品阶段已经是比较成熟的 (这个跟之前负责这块的产品经理也有过交流和印证)、就更加的感到压力巨大。
后来经过更多的了解才知道，在我入职的前两个月、之前负责这个产品的 资深的前后端 同学都离开了、剩下的都是工作4年内的年轻人接手各个子模块。在去年初、负责这块的后端一线同学“离职或转岗”走了两个人，去年九月、我主管的主管(整个监控的总负责人)也转岗到了其他团队、随后两个产品经理也转岗走了。除了 剧烈的人事变动 外、这个产品的体验当时也比较 “糟糕”，因为公司给的服务器资源不太够以及其他代码或设计的原因(后端换人也频繁)，经常出现页面查询报错或是误报问题、带来了大量的oncall，后端搞了接近一年的“稳定性建设”、才慢慢有少许好转。
具体到前端和产品建设上，主管希望我做“Issue管理”功能、给产品带来新的亮点或破局，我也充分调研了app监控以及外部竞品、发现这个功能存在很强的“模糊地带”，而且实际效果都不够理想，大家也都 没有很好的或一致的设计方案、甚至没有比较好的量化目标，想做的彻底或有明显效果、要涉及到现有 产品底层逻辑和产品设计上 比较大的变化。先是和团队内以及后端合作等同学密集沟通多轮技术方案，又经过比较“波折”(如下解释)的PRD设计和开发的过程，最终落地了两期功能、并和产品QA等协作同学制定了推广方案。
如上个人承担多重责任、要兼顾投入精力到多个地方，而在这个功能上只能投入1/3左右的时间。
这个功能的 产品PRD 设计稿 研发 都要自己做。综合考虑落地可行性和成本等，功能在最终的页面上没有体现非常明显的变化。产品目标的预期和对齐沟通没有特别到位 (包括主管和他的上级)
作为字节新人，遇到很多比如 “工具平台繁多且上手复杂、有关联的其他功能有许多旧缺陷要修复、其他高优需求插入打乱原本的开发节奏计划、英语沟通效率较低” 等等意想不到问题。
很多时候做成事、尤其是 “破局” 这种很难的事，一定是需要天时地利人和的。至今也 思考了好多次 ，首先自己在监控领域的能力和经验需要更好外、其实还是有巨大的客观困难无法解决，这个功能本身的难度以及协作中各方(小组同学/产品经理/后端)对这个功能看法和目标在内心里比较难一致。对当时甚至是现在来说、这都是一个不可能在短期做出亮眼成果的功能(长期会有结果/但资源不到位)，我个人后来对业务理解越来越深后、并且基于客观条件可行性、思考规划一些可能更有价值和ROI也较高的事情：
- 产品信息结构的优化，能让用户有直接的收益、也可衡量出效果。
- 产品功能的原子化，做成一个个可装配的插件、方便集成或被集成，形成 workflow 的能力。
- 比如关注 iPaas 平台，跟 AIOps SRE ChatGPT 都有结合点。
这些事情在前边几个月里、只能处在脑暴和讨论阶段，也需要拆分成阶段性目标任务、才可能得到资源支持来落地。 后来(去年八月末)调整工作内容、我去支持“后端监控-报警模块”的前端开发。我觉得这样刚好也能深入了解下后端监控是怎么玩的，当时就抱着简单浓厚的学习心态、投身其中。后来发现后端监控业务本身也遇到了破局瓶颈，而且积累了大量的历史缺陷和历史代码债。需要干大量的脏活累活来填坑、同时不断有新的优化类需求，以致几乎无暇有学习时间、难免对后端监控的理解深度不够。后来了解到这块的前端支撑同学近一年换了三个人、后端大主管也转岗走了，原来有个实习生已经给了转正机会、也不来入职了。
网上有人写 “字节一年 人间三年” 的文章，因为字节的组织非常不透明、所以我只了解身边人的工作强度，其实因人而异(工作年限/事情大小/亲疏关系)、也不是每个人都这么累。具体到我个人是处在一个被“全方位严要求”考验的角色定位上、却又遇到了极度困难的客观环境，就出现了那种极度的“身心俱疲”的感受。但我觉得这归根到底是 “管理和信任” 的问题，是涉及和身边所有合作的人、特别是和主管之间的双向问题，而合作中的每个人其实都是管理者、我借助反思这段经历的过程 也特意思考总结了 如何做一个好的管理者。