一直觉得在猿辅导工作算是非常幸运的，这家公司或者说你的领导和同事努力营造了一种恰当的氛围。
一直觉得对于员工的要求，我们要求同存异，不用PUA, 也不用太多 KPI 来限制其本身的规划。通俗的讲，每个人都在根据自身的期望去做事情，没有太多来自上层的束缚。
对我而言，在辅导有两方面的成长。
技术角度而言是，是在移动端端上的APP 整个开发流程有所了解。知道如何开发一个APP， 以及后续如何进行需求迭代和发版，包括发版后市场的管理和数据质量的监控。
管理角度而言，是学到了如何利用管理工具进行员工业务需求的交流和分配，并且利用科学机制确保公平性和工作的强度。
回顾过去几年时间，我特别感谢 Tala 和 Bo 哥给予工作的信任和指导。我一直觉得信任在员工管理中特别重要。这表现在对于下属工作能力的认可，以及放开下属技术思维的局限。这种信任与员工测表现在自驱能力较强的人可以得到足够多技术架构权利。
iOS 的举步维艰
自己刚入职的时候，最初选择的是调研 Web 互动题的技术方案，这个也是辅导历史议题，不同组之前有不同的选型。比如辅导有 Cocos 2d 打底的一系列解决方案。而隔壁斑马则依赖于轻量级框架 Phaser 进行技术演化。当然我们这边结论还没定的时候边去支援 iOS 开发。
在入职的前一周时间，自己一直在学习 Swift 和 iOS 开发相关，然后到开始写第一个需求的时候却发现是 OC 为主，需要去读 OC 代码。需求大致就位实现图片上传裁剪的功能。也是基于 Github 开源的组件，进行一些业务关联性的功能。由于预估的是 13 分研发 Estimate，也就是一周左右。从小自己就不是一个特别善于去虚心请教的人， 因此还沉浸于“埋头苦干”。
由于编程语言的相通性和早先 C# 的一些积累，代码阅读相对而言不是那么困难，业务改动也还比较好弄。比较难得问题反而是整体包跑起来的流程，对于 IOS 通过 Pod 进行模块管理，介于网络问题也会出现 pod install 异常问题，包括内部模块的引用问题。在徘徊一天尤其快要到 Scrum 会议的时候，自己联系了 IOS 比较有经验的蕾姐同学。在她的帮忙下，确实很快解决了这个问题。大概对于未知领域尤其流程相关的，可能请教资深的同学反而效率更高。
蕾姐不仅会 Web，还会 IOS / Android ，确实是个多面手。也是我发现辅导藏龙卧虎的地方。包括Android 项目期初也是她参与规划了一些模块。大概那个时候自己开始觉得不应该局限于所谓我更有经验的 Web 前端。
猿萌萌 Android 起步
随着蕾姐离职和 IOS 初步成形上线。压力来到了 Android 端。Android 这个时候真的是一穷二白， 团队没有人会 Android。当时 Yshuo 小伙子和我开始了这个所谓难度极大的项目，这也是初步的 Android 小组。大概接下来几个月的周期，我们所做的就是按照预定的发版目标，开始需求的拆分和管理。
Android 开发与我而言最早是在 360 时候黑客马拉松 48 小时的学习， 之后就再也没有接触过开发了。几年时间 Android 有了很大变化，比如市场主流已经是 Android 10 了，比如我们使用了 kotlin 进行开发，同时也提供 MVVM 的架构模式进行整体页面的架构。而且辅导内部也有足够的技术沉淀，比如 Webview ， 埋点等库的第三方 Maven 地址。
由于斑马和我们的形式类似，因此感觉有得作业抄了。然而对于一个新人去解剖如此巨大规模代码，似乎也是很难下手的。因此我们还是依据一个全新的 APP 进行需求计划，比如项目初始化，项目基本模块，网络，Webview，埋点，播放器等进行核心模块功能划分。而这些模块也伴随着相对应的业务同步进行需求管理。我印象特别深，我第一次接触 Webview 的时候，网上一搜，感觉代码似乎也没有那么复杂。但是看着辅导的模块划分，似乎又非常庞大。自己那一周似乎都就陷入在辅导 Webview 里极为复杂的模块之中，加上需要随时的进行 Java 代码的阅读理解工作，真的算是我认为至今比较困难的点。到最后自己干脆直接跑到原作者身旁，叫对方友情协助讲解了整体的实现思路和技术规划。
由于核心需求是录播课。也就是视频和 Webview 的结合，大概这边整体自己实现参考的是 IOS 实现的那个方案，也感谢之前的学习，对于 iOS 测代码的翻译工作变得没那么困难。当然这里面还是有很多差异性需要自己去补齐，大概能够初步跑起来的时候，自己需要关心很多业务细节。包括动画的时间点以及和互动题通信的交互。大概结合着以前 Web 和多媒体的经验，在进行 Web 通信块和视频块的协调工作异常顺利。因此这个最为核心的功能，反而没有给自己带来意想不到的困难。
随着不停的迭代，我们终于到了发版提测的日子。在提测间隙也研究了 Android CI 的相关。感谢之前 Docker 的经验，也算完成了公司内部新的构建平台整体 Android 发版流程。但是处于内部镜像问题以及其与产品都没迁移，还是以人工为主。我们在构建会分为 Test, Beta , Release 三个类型。而对外的渠道也是基于 Release 构建分发。而在测试的阶段，大概是我认为迄今为止最为挑战的日子。大概也是和 Yshuo 建立深厚的友谊，毕竟一起熬过夜。这个阶段暴露的问题非常多，这其中表现在三个方面：
业务理解和实现的偏差。大概这个问题一直困扰着我本身。自己有过几段创业经历，自己的思维还是有些偏向所谓 Owner 出发去思考本身需求应该成为什么样子，而不是产品文档所谓描述的这样，尤其描述不清的地方，也容易自成一套，按照自己的思路去实现。这样变化引起测试和产品的困惑，这个也后续是借助测试用例，以及更多产品预审稿来进行问题的交流，尽可能暴露一些问题在 Scrum 需求讨论中。
马虎粗心导致低级问题这里面其实很多时候都是非常低级的问题，比如文案差异，单位控制，异常边界处理问题。我一直认为本身成长伴随这样的问题，我理解本身控制最好的便是小学初中的答完试卷的结果校验。但是在高考的时候，时间没那么充裕，因此没有时间校验导致出现了让我难以忘怀的一个选择
36 * 3 = 118
这次我还是觉得昨晚需求，应该完整的走一次自测 Case 包括对产品搞的复核。实际我们在需求的时候都是参考 UI 来做，往往忽略了一些原始产品稿件的细节说明。也是在这样强迫自己的规则慢慢提升质量的交付。
经验欠缺导致疑难问题给不出正确解决方案 我觉得这一块在那一段时间非常的消耗，由于客户端系统版本非常多，权限系统改动也非常大，不同厂商规则也不尽一样。于是乎出现修复完A型号又衍生出B型号的问题，进入了死亡循环。大概在这期间我们开始每天进行扫描，同步问题修复进展，我印象特别深刻的是，老大随后在总结问题时候找了隔壁斑马组的支援，虽然只有一个同学，但是他的经验却很好的帮助我们在一些是非纠结的问题给出了很好确定性结论。经验性问题，我们不必一条路走到底，需要的只是确定性结论，做或者不能做，产品出适配方案就行。在客户端这种情况很多，取舍与决策来源技术与产品的密切沟通，这也是后续给自己在进行技术难点决策时候很好的一个辅助，一个未知的问题，如果经验可循，请教经验丰富的同学，如果业界没有探索，便摸着石头过河，依赖于当前版本分布，流程影响大小，在关键节点给出结论后期再进行调整。船需要向前开，无论如何，如果一直停留，永远到不了终点。
猿萌萌稳中向上
随着 APP 用户规模的扩大，Android 团队不停扩大规模，招来了大厂的开发人员 Wming, LiK，XzQ, 帮助我们进行了 APP 的部分重构和瘦身工作。也是接触到了整个大厂进行客户端开发工作比较 Care 的点。
- 关注资源的合理使用
- 关注模块职责的确认
- 强调业务与基建的拆分
这个期间自己开始承担部门 Scrum Master 的职责，而自己这个阶段关注的是数据辅助的体验问题。这里开始定期制作体验周报，用于进行客户端体验质量相关，这其中包括 Crash率，视频异常率，网络请求异常等。除此之外，客诉反馈也是非常核心的点。每周都会扫描客诉上来的问题，这表现在两个方面
- 关注老师报障平台，及时推进研发产品同学发版解或者指引操作
- 关注用户反馈上来的问题，进入到需求池进行 Scrum 评估排期
也是随着关注的增多，整体客诉数量明显开始进入下降趋势。而且也是伴随着指标的提醒，大家也能关注到每次迭代的质量上，及时发现问题并进行纠错修复。
双减下的团队稳定性
期初自己进入猿辅导给自己定了两个目标
- 从 0 走向 10w DAU
- 呆到合同期满
第一件事情是业务需求目标。第二个目标是自己稳定性发展目标。每一份履历都在给自己复盘，在后面几年自己强调耐心的重要性。因为事物发展有阳光灿烂必然有酷暑严寒，只有经历了几个四季，才知道本身在这里特别适合什么。
这期间有很多猎头打电话问外面的机会，自己也都还是一一谢绝。那个时候对于未来期望是非常大的。
去年，年中绩效盘点完，双减政策开始出现。这个黑天鹅是我至今抱有质疑的政策。伴随着出身率的下跌，国家开始陆续放开二胎，三台政策，以及各种促进结婚和新生儿的优惠策略。中国出身率下降的问题，它是非常复杂的问题，也单单不是教培行业一个因素。
我印象特别深，在双减前，有部电视剧，叫《小舍的》里面描述了如今一些学习乱象。我是没有预估到几个月后，政策来了非常直接了当的结论，这个行业需要彻底的进行去资本化和所谓的减负工作。后续我会专门写一篇，关于近几年高压政策背后的博弈。
这个政策前期对于我们测业务线处于模糊的边际，但是印象疼别深的是隔壁组同学，很多同学前一天还在对接需求，第二天就收到所谓的裁员消息。这个于当事人或者作为朋友的我而言实际上很难去接受。这段时间，于产研团队而言是相对比较折磨的日子，很多人害怕这个名额落到自己头上。实际上，于我们业务线，在那个动态也悄悄进行了开支缩减计划，而重心主要是放在产品测试身上。快到年关，老大终于出来稳住了信心。
然后春节过后，早有计划的同学都提了离职，已经提前联系好了工作。和他们聊，大概是对未来依旧存疑。其实自己那个时候也是有些疑惑。这里面有非常要好的朋友也都出去换工作了。但是我觉得还是可以尝试呆一呆，毕竟自己第二个目标还没有实现呢。
年后三月份北京市教委下达了关于幼儿阶段培训 APP 停止运营的草案商议。其实如果对自身产品定位了解的话，这份草案对于我们的影响无疑是巨大的，尽管后期我们业务线调整收缩到6-12岁，然而与这条线的感情无疑是非常深厚的。
三月下旬突然的消息通知到我们，也就是收支平衡目标，上一次创业让我明白这个概念是什么含义。大概与我而言，预言到了这条生命线的完结。在整体制定名单时候会有很多决策，包括去年绩效的遗憾，现有人员的能力，部分员工的替代性，最后关于 Android 的取舍时候，在得知对方的不愿意后，自己主动担了这个名额。我觉得这一刻算是对过去两个目标的未达成交卷了。产品生命线一直围绕着我的整个决策。自古以来有忠于自我原则，有忠于上级领导，也有忠于自己羁绊。大概任何黑天鹅事件于我而言，是非常不公平，但是又必须去接受，而重新出发，再度挑战。
But if we ever get lost on our way
The waves would guide you through another day
管理的点点滴滴
在双减下，我们的另外一条线，自己承担起端上业务侧和互动内容的团队管理工作，无疑管理担子重了一些，管理其实在这些年成长的过程中陆续体会的是我们要向上关注目标达成，向下关注员工自我实现。
自己在 15 年开始创业的时候，对于管理本身经验也属于摸着石头过河，只是结合着 360 的经历去推进事情进度，而忽略了关于 “人” 的核心诉求。对比那个时候，我觉得现有的自己在方法论上算是有些自我心得。真的也很感谢 Tala 给予亲身示范，什么事情需要参与，什么事情需要关注过程，什么事情需要放任下属等。大概我觉得好的管理是双向成就的，如同前端生态圈。
使用开源的项目 -> 成长 -> 反哺开源社区
管理也是一样，你如果有好的 Leader ，你会吸收他关于管理的经验。而为后续自身参与管理作出辅助。我觉得目前大家预期的 WLB ，管理的角色其实有非常大的职责。我们在业务预期管理的时候需要思考几个点：
- 需求一定要在某个点上？
- 人员是否处于高压状态
- 在合理的工作时间内的 60-70 个点是否投入到工作
- 是否主动去推进无意义的卷的行为解题
- 会议是否能够高效沟通
至少辅导，老大会在下班点，到点就走。这无疑是给人很多参考点。如果管理者不主动去改善这个现象，后续就必然面临着，下属的高压工作，以及强迫内卷。解决互联网内卷一定是自上而下的行动，需要管理层以身作则，作出自己科学化的管理，平衡以人为本以及自我目标导向的问题。
自己这几份工作经历中，阿里是真的需要大家 All In 到工作，在 VeeR VR 很多人湾区回来的，到点了就会陆续回家，打游戏的一起约去打游戏，并不影响产出的问题。而阿里更多焦虑来自于不停消息打扰。非常分散研发精力。这也是自我一直克制任何休息时间发消息的原则。
辅导的管理机制表现出员工与 Leader 弱管理关系和业务强驱动型。我们差不都会有两周或者一周位周期的 Scrum 会议。每个人会进行任务的拆分和工作量评估。 这里面我们确保 任务的拆分和工作量是大家都认可的。
任务拆分是一起做的，因此大家会有讨论如何进行拆分合理，以及有哪些点需要关注。而任务评估也是一起参与，每个人都需要给出合理的分数，并且阐明具体原因最后汇总成一个合理的工作 Estimate 。 管理者需要保证任务的合理，工作估分的公平，包括任务分配的可控性。我们单周 Scrum 里，几乎就没有任何大会议，后面都是小组自我驱动的会议，比如测试用例，产品更新需求等，这里面 Leader 都是没有直接介入的。
质量管控是在整个 bug burndown 中进行的，在进入发版时间线，产品线晚上都会进行 bug 汇总和决策，这里更多时候决策权是下放到产品和研发的，如果出现纠纷难以解决，Leader 才会出面进行协调。相对而言这段期间是比较紧张的，因此早日暴露和发现还是来源于需求的碰撞，测试用例的评审，以及自我质量的约束。
在辅导于个人而言最大收获是验证了未知领域的挑战如何系统化进行克服。让我想起学校创业的时候，我们从一无所知，到最后交付产品，整个事情一致，未知不代表不可逾越，困难不代表无解，以前是知道个人努力和更多投入，现在更多的是如何和团队一起去应对这场挑战。
我相信辅导在度过这场困难之后一定有别的生态会开花，这也是整个创业最为核心点，产品会不停的变化，但对于未来事情的执着，以及对于流程合理的把控管理，干什么都不会差的。这也是给予我最大的信心支持，无论未来接触什么样业务，自己有意愿去陪伴产品成长，而没有那么多自我顾虑。
Good Luck 猿萌萌！