iOSer 年度总结｜晋升的逻辑是什么

Outline
2022年发生了什么
大环境行业感悟和思考
个人工作内容变动思考
职场中一些好的特质是什么
如何晋升？
工作计划
未来展望

2022：github star 2.5k
2023：价值闭环
iOSer 年度总结｜晋升的逻辑是什么

2022年是疫情3年的一个“小尾巴”，但它一点也不小，因为它是3年内大家感受最深的一年，也是影响最大的一年。身边同事们换工作、周围见闻都可以印证这个结论。

宏远的部分就不谈了，经济大环境和政策对互联网的影响、以及人们对经济预期的变化，都在改变着我们。之前大行其道的消费主义也变了，人们回归理性，从居民储蓄率这一点就可以看得出。

除了正常的每个月的月供，我会每隔半年会提前换一波房贷，22年可能还了35万。不过现在不打算遇到还房贷了，想着多留一些现金在身边有安全感（身边有人还房贷，说银行那边排队到23年了）

对于从事互联网行业的我们，影响最大、感受最深的就是互联网的投资逻辑变了，所谓的用户量已经不再具备吸引力了，现金流和盈利才是吸引行业资金、人才倾斜的逻辑，互联网的高速增长的步伐刹住车了。国家在政策上和资本也是倾向偏实体制造业大户的，比如新能源汽车。因为能带动的产业上下游很多，包括软件开发和制造业等。很多认识的从互联网出来的人去参与到新能源造车领域发光发热。有个阿里的产品朋友聊完发现，新能源车领域互联网信息化和流程较弱，过去带着互联网那一套有“降维打击”的效果。

要是让我概括下，互联网这边有什么好的特质和思维，我尝试概括下：不舍边界、Owner 意识、数据意识、价值追踪、问题拆解思维。

Owner 意识谈得是做事情的态度和思维，为了正确的把某个项目做完，不去因为职能和岗位问题只做“份内”的事情。只做份内的事情不对吗？挺多的，不过这是大多数人的思维，强者会推动项目进去，主动协调各个角色做好事情。所以这样的人肯定是更难得的。

数据意识谈得是，做一个项目或者优化，需要有数据支撑。面临的问题是什么？现在的现状是什么？比如现在一个人需要花3个工作日才可以完成某个流程。当新的系统开发后，一个人花0.5个工作日就可以完成某个流程。那这是假设，项目上线后如何追踪？埋哪些点，去量化衡量价值。项目上线几个月后开会去复盘梳理，要不要迭代，本次上线的项目符不符合当初的设想。所以需要数据思维去量化定义和跟踪问题。价值追踪也在上面的例子谈到了，具体不做展开。

问题拆解思维谈得是某个项目需要哪些资源，某些资源不具备，我需要外部哪些部门提供资源，如何让外部部门更主动去帮助你。那如果有一个共同目标，让别人也有一个好的结果，互相成就，这样的事情更具备主动性，而不是别人买个人情或者迫于更高层的压力，那么优先级可能就会给你排低，不是一个最优的方案。

还有部分优秀的大佬，不认可字节的文化，去 Zoom 这样的外企工作了，虽然钱稍微少了一些，但是问到他，他会讲有更多的个人时间了，工作也不需要那么卷了。之前的有赞的 TL 去浙大实验室带项目了，问过一次为什么做这样的决策，回答“稳定，可以有更多的时间陪伴家人，虽然薪资方面可能会比互联网打折扣一些”。一个没参加过高考，保送浙大的人，参与过支付宝、微策略、有赞移动 TL 的人做这样的决策，肯定有自己的理解（权衡之后的一个结果吧）。

我也从有赞离职了，在有赞的工作内容可以分为2部分：前期是写业务、后来去中台写基建。在中台主要负责跨端（Weex 打包平台、性能监控、异常监控、Flutter 组件库、热修复）APM、业务异常监控等。在有赞写过业务，也做过基建开发。写过 iOS、Weex、Flutter、Electron PC 收银，写过移动端 mPass（前端React + UmiJS，后端采用 SpringBoot）写过业务异常监控。可以说是全栈了。做的不足的地方，我记得移动总监坐我边上的时候，经常和我讨论 APM 的原理和技术细节，为了移动端性能，为了统计口径的一致性，制定了公司层面的北极星指标，但是在北极星指标的时候，调研了行业内不同公司，发现每个公司的定义也不太一致，后续我们也定义了自己指标（为了更好的服务于业务，也为了更好的暴露和量化性能问题），制定好指标和去业务线宣讲，也经历了一些挑战，最后不断打磨，因为 APM 不只是一个技术命题，同时也是一个业务抓手，同时又是一个产品（不过产品的使用者是公司内部人员，比如开发者、TL、产品负责人等）所以需要全面思考并落地，那段时间是我最工作最头痛、同时也是最快乐的一段时间，被挑战的越多，倒逼我去思考更细致、更全面，成长也越大。当时也发现腾讯 Matrix 的一些 APM 问题。发现虽然是大厂的项目，但是也要对质量和用审视的目光去看待。

年度环评和时候，移动总监对我说了一句话“你在技术方面挺优不错的，但是需要提高的一点是价值闭环，比如你在做 Weex APM 的时候，虽然项目上线了，但是还没推广到各个业务线，就去做移动端的 APM 了，希望你把最后一公里走完”某个项目哼哧哼哧做了那么久，就差一步就拿到一个更高的结果了，然后没做，马上去做其他事情了。关于这一点我也很认可，希望接下去几年不断正视这个问题。

每个公司战略出现调整的时候，对于技术中台会影响更大一些。所以这次后我选择从事业务开发，业务开发上的架构设计、性能优化也同样有意思。业务背景下做优化做出价值更快，如果是做基建，价值和意义体现可能会较为被动，需要从侧面（业务宿主 App 的一些数据来体现价值）。另外业务更能摸清公司的主营业务，更具备不可替代性。

到了业务后我将业务代码的单元测试覆盖率从30%提高到93%以上。业务代码拆分为 Core 核心逻辑层和 UI 层，单测主要针对 Core 展开。所以从基建转到业务开发后，将会聚焦于业务架构，设计出面向未来可拓展的业务代码。另外从业务侧去做一些性能监控和优化，比如最近在做的 CI 项目，将一些质量问题收口到 pipeline 阶段，去监控质量，不合要求的代码，没法合并到主工程。针对业务代码提交 MR 后，gitlab hook 去触发脚本，review 出来的一些评论和互动都会通过 robot 自动发 lark 消息，不需要线下发消息告诉对应的人去 review。另外可以按照一定的策略去 lint，保证提交代码的质量。

晋升背后的逻辑是什么？换句话说，晋升的一些必要非充分条件是什么？