我们组即将迎来一次新的组织架构调整。之前我们的直属 Leader 是 Privacy Infra 这边，调整后将汇报给美研的 Privacy Product Mobile 团队。 从做的事角度上看，这次变化是顺理成章的，因为我们是做业务，和 Infra 没有太多联系了，Leader 也不太关注团队做的事和发展，调整到业务团队是更好的选择，并且有个专门负责 Mobile 端的 Leader，对于团队成员的成长也会是有更多的指导。尽管说存在中研和美研由之前兄弟团队变成了汇报关系心理有点别扭，以及对于未来对中美业务的划分存在不确定性外，这次组织架构调整更多是利大于弊。

昨天和 Bob 聊了一会，感觉有些收获，需要记录一下，遂成此文。

第一个交流的点在于对于业务研发来说，什么是底层知识，我自己的看法，比如 Android 这块，我会认为一些 Framework 的知识，一些性能优化的知识，是比较低层的，而业务代码是比较上层的。之前也很有往基建方向转的想法，但也担心自己的能力够不上。Bob 认为这些知识，比如客户端基建，跨端基建，其实更多的是另一个赛道或领域的知识，并且已经有很成熟的团队在做了，我们去做这个意义不大，最多也就是能跟上，不太可能超越他们，并且这个方向已经是很卷的存在，我们没必要去这个方向卷。对于一个资深工程师来说，最重要的是架构设计能力，能够根据一个业务，做出一个好的架构框架来支撑业务。这个能体现出复杂度，就能支撑你晋升到 22。如果 22 要再往前更近一步，则需要的更多是领域相关知识的积累，比如基建、比如音视频、比如我们目前的隐私合规，我认为相比较之下，隐私合规是更朝阳的存在，是可以投入一条赛道。

听完后，我觉得是有一定道理的，之前像磊哥也说过，其实做啥都一样，背后表达的可能也是这个意思，架构能力，是晋升 22 的关键。当然我认为必要的底层知识是一定要掌握的，可能需要做些取舍，不然不足以支撑架构设计，这是硬实力，再一个是业务理解和抽象能力，这是软实力，两者缺一不可。

第二个印象比较深的点在于在交谈过程中他表现出的比较有领导力，或者说比较懂得带人，了解职场规则的一些点，这些点可能在平常我并不太会去关注，可能直来直去，以后比较吃亏。比如说，这次调整后，他给团队成员划分了一些重点业务，我是有些业务范围变动的，之前我担心的一个点是 Android Owner 的角色是不是就没了，虽然这个角色有利有弊，但对于晋升，这个角色还是有些帮助的。但后面聊下来，这部分的职责没有被拿掉，也打消了我的一些顾虑，后面他说我们在推一些事情或项目时，肯定有的时候需要其他角色配合，这时候不能缩小人家的 scope 来达到自己目的，而是需要达成一种共赢目标，这样阻力才会比较小，我觉得前面关于 Android Owner 的角色以及这次组织架构调整其实都印证了他的这个观点。

比如说我们团队中有个 Android 比较资深的同学，从我的视角看，可能缺点挺多，做事慢，死扣细节等，但他说对于这种情况要做针对性的策略调整，比如做事慢，可以和他的晋升挂钩，如果他想尽快晋升，那就会把事情做快，比如死扣细节，有代码洁癖，那可以安排做 code review，也挺好的，知人善用，目前我觉得我离这个差得很远，还停留在喜欢听话的人层面上，以后这块也是要好好学习总结的。

比如说关于做什么样的技术项目，如何要资源。我们之前很多时候是想到啥做啥，没有完全想清楚就做，或者说我们为了尝试一些技术而做，比如我想在业务中引入 Compose，我就想过把一块历史老代码重构成 Compose 版本。但这其实不太好，因为它没有带来什么业务上的收益，反而可能引入线上问题，那把人力花在这件事上，领导可能不会买账。技术项目需要服务于业务，要能解决业务痛点，同时为了达成自己在技术上的一些想法，我们可以选择适时地塞一些技术上的私货。比如我想在业务中实践 Compose，重构老代码可能不是个好选择，但我可以在做新需求时，用 Compose 来做。比如我想重构一块老代码，那可能可以跟着一次需求迭代，一次 BugFix 来做。比如我想快速有效推进技术项目的进度，我可以在做一些相关的业务需求上，渐进式地向我理想的架构去做迁移，每个需求做一点，每个需求估时多估个两天，一个大的技术需求，可能就被做了大半了，那剩下的一半，我们可以向领导单独要个人力来做。这其实要求我们对技术项目或者说业务的架构想的足够清晰，并且能够将大的事情拆分成独立的小项，能够单独做，渐进式地做，最终达到高速路上换轮子的效果。这方面相信未来他也能带给我们更多的帮助。

第三个讨论的其实就是之后我要重点关注和解决的 TnS 业务分散的事，这个我之前也进行过一些思考，TnS 业务很零散，它会在各个业务，比如 Feed，Profile，Comment，Search 等地方打补丁，但业务逻辑也都不复杂，就是一些展示和跳转，大致上可以分为三个方面，Trigger-UI-Action。Trigger 在于每个业务触发的时机和方式都不相同，我们作为在端上的收敛一方，其实可以定义一套统一的协议，也就是和后端交互的 API IDL 应该我们来定义。UI 在于我们需要避免无休止的 UI 改动，需要将其规范化、模版化，我们应该提供 UI 能力而不是 UI 开发，甚至可以做一套局部动态 UI 框架，或复用现有的跨端动态化方案。Action 方面我们目前的交互不是特别复杂，更多的是一些跳转，或者出一个弹窗等，这些行为我们可以进行一些抽象和预定义，内置到端上，通过协议就可以调用。Bob 也比较认可这个思路，后续还需要梳理现有的业务、理解这些业务，确认这个方案是否可行。

第四点和与 Bob 的交流无关，是晚上回来后和小萌聊天想到的，起因是有个 Oncall 问我为什么 region 修改了要重启两次，我之前其实就看过代码查过原因，但是是直接发到某个群里，现在群已经解散了，没有写成文档，找不到之前的结论了。现在我知道它需要重启两次，但我不知道为什么，因此我又需要看代码，理解里面的逻辑，再写一遍解释发给别人，这个过程就很浪费时间。小萌就说这种情况应该写 SOP 文档，以后直接分享一个文档就行。确实是的，我们应该有写 SOP 文档的意识，这也是之前 Leader 跟我 One-One 时提到的，需要在团队内沉淀标准流程，比如问题排查思路，处理线上问题的方式等等。

第五点是结合 Bob 提到的积累领域知识，和我一位同事的习惯，想到应该注重知识地图的构建。那位同事非常优秀，是个全才，不仅在 Android 领域有很多的研究，并且还扩展到 AI 等方向，他的一个习惯是对于每个知识领域，他都会构建一个自己的知识地图，里面有一些领域的上下文背景，其他人的优秀实践，自己的学习总结等，让自己有需要的时候能够快速找到这些知识。我觉得这个是一个非常值得学习的一个点，在技术上应该有一份技术的知识地图，比如 Android 开发，从基础到进阶，从垂直细分到横向扩展，从业界通用到公司内部资料；在业务上应该有一份业务知识地图，比如隐私合规，历史需求业务梳理，合规的背景，业界的方案，为什么要怎么做？通用的隐私合规基建有哪些等等。前面一个是积累我们的技术实力，后面一个是积累我们的领域知识，业务知识。要在资深工程师基础上更近一步，成为架构师，就必须两手都要抓，两手都要硬。

暂时就想到这些，工作杂想系列应该复活一下，以后有些工作上的想法，还是需要记录下来。