关键词:不轴
这一年信息量还是挺大,做了很多项目,但是业务产出较少(有一些外部因素),职级也未能得到晋升。经过这一年的时间沉淀,不再自以为是,以更开放的心态接受身边事物的改变。
业务
业务第一
不再以为技术最牛逼,更多考虑的是用户体验,跟产品撕逼的情况少了,愿意去提供更好的方案,更会站在产品的角度去懂得产品同学的想法。业务第一,产品第二,技术第三,技术赋能产品,产品驱动业务,一切都是为了业务。
最近有一个业务需求,需求前期阶段就同产品同学对接过几次,确定了可行方案。但是到了需求评审阶段,又进行了多次修改调整,需求评审时间跨度1周+,这就导致剩余给开发和测试的时间只有 1 周了。项目参与同学怨声载道,不满情绪较多。
这时我就陷入了两难境地,为了让项目参与同学解气也一起喷产品同学(你这需求能不能行了),还是试图让项目同学理解这种特殊情况(项目同学:理解个屁啊,开发时间这么短,谁能理解我啊,到时候上不了线又说技术同学不给力)?
我是项目技术 Owner,要解决这种僵局需要多做少说,解释就是掩饰,只能想办法解决需求变更的原因。先拉上产品同学从技术视角提供可行的解决方案,从用户视角优化流程体验,确定最终的产品核心流程链路,这些一期先上线不能再变动。
其他的统统放后续优化迭代,在一期上线之后再处理。
技术重构
这一年在上游产品输出一般的情况下,我们抽了大部分时间做了系统重构,填了很多坑(也又埋了一些坑),业务完成了收口,也为后续业务迭代打好基础。超过 85% 的业务已完成系统重构,2 个重构项目获得了标杆 OKR。
怎么选定重构项目?
从实际出发,是业务或开发痛点的才去重构,不要为了重构而重构。
- 历史包袱重且迭代频繁的核心业务功能
- 迭代频繁可抽象通用化的功能
- 迭代频繁可配置化的功能
怎么实施重构?
不着急大步推进重构,拆分成不同的迭代周期,每期的任务是具体的,是可以完成,是进度可控的。另外找到合适的时间点去做重构,借力合适的业务需求去做重构,就会事半功倍。
合适的时间点去做重构,有这样一个例子:
由于历史原因,我们有个问诊系统,对接了百度、腾讯且各自为独立系统,算上我们自己的系统有 3 套类似功能的系统,在 APP 端也是不同的功能流程。这样用户体验不好,开发维护体验也不好。
之前我们团队一直在小步重构自己的这套系统(功能已兼容其他 2 套系统),而其他2套对接三方的系统重构优先级放的比较低。
直到有一天,业务团队说三方对接业务暂停了,借此时机我们快速推进了问诊系统重构,把 APP 端的功能统一为一个流程了。
重构过程中,我比较关注怎么为以后的开发提效:
- 功能复用,减少重复开发
- 配置化,不需要开发和发版
重构后有什么收获?
人员更熟悉业务了
之前由于人员流动,部分新同学进来,加上业务文档缺失,短期没人熟悉业务,导致问题频出。重构前,会先梳理出业务文档和技术方案,有了文档沉淀。重构后,团队参与重构的同学也熟悉业务了。历史包袱少了
历史代码逻辑本来就设计不合理,因为逻辑混乱再加上后续的迭代修改,没人看得懂也没人敢优化逻辑,就成了一堆祖传代码(屎山)。后续修改维护都需要花大量时间梳理逻辑找到需要修改的点,另任何修改都需要测试全面覆盖用例。系统更合理更可扩展了
举一个例子,诊室 IM 按钮的配置化改造后,后端可以直接配置下发。
{ |
95% 情况的修改不需要 APP 发版。前几天,公司 CTO 觉得现在的按钮顺序不太合理,找到我想要调整一下,我当时心里窃喜,还好我们已经提前做了配置化改造,不然就要被喷了。
可以配置化后,很快就完成了按钮顺序调整。这件事也让我更体会到技术手段的重要性,之前 Native 开发按钮,也不是不可用,只是不够灵活,任何修改需要发版,关键时刻救不了火。
团队
每个人都是某块业务的 Owner,协作起来比较顺畅,执行力比较强(自我感觉)。
拥抱变化
公司经历了几次组织架构调整,团队人员有进有出,也以开放的心态拥抱这种变化,因为唯一不变的就是变化。
最近一次组织架构调整,原本团队 20 人左右(包括 Native),对 APP 终端的业务功能负责。这次调整,我把 Native 交给了一个比我更合适的同事。
其一,我后端出身,对 Native 技术不熟悉,属于外行管内行的情况,可能由于我这方面的短视,无法提供更有建设性的意见,对这些同学的发展不利;其二,在团队内也没有找到合适的同学来补位。
但是我还是挺感谢这一段时间经历,对我来说是一个跨界,接触到了之前没关注的领域,拓展了自己的技术视野,会全局考虑技术实现方案,对后续工作也是很有帮助。
比如之前后端在设计技术方案的时候不会考虑 Native 这边,出现过 1 个页面需要调用 20 多个接口的情况(Native 同学咋没原则,不知道拒绝),Native 代码里也充斥着大量的业务逻辑实现。对此后续在团队里面形成规定:
- 接口要收敛
- 业务逻辑收口到后端,前端只做展示和交互逻辑
充分信任
相信团队的每一个人,不再觉得只有自己能做。把一些事授权给团队成员去做,对他们才会有更多成长机会。
- 充分信任。疑人不用,用人不疑
- 授权指导。明确任务、时间、验收标准,以及如果是我大概会去怎么做
- 监督。正向反馈,即时修偏
- 拿结果。做得怎么样,问题复盘改进
寻找关键人
以点带面,良币驱逐劣币。抓好团队这些关键人,让他们经历更多事情的蹂躏快速成长起来,负责更多的事,担更多的责任,避免团队因我这个单点而导致的翻车。
个人
新的角色
加入了后端技术委员会,能为团队做更多的事,面对更有挑战的一些技术难题。
以下 2 个案例都是为了解决团队发版日必过凌晨的问题,团队发布效率低导致加班严重。
发布流水线
微服务化之后,稍微大一点的项目发布都会有 10+ 的应用,之前全是人工手动到发布平台上一个一个应用点发布,效率低,且容易出现发布遗漏应用的情况。
另外如果是多个项目发布,那么就需要排队等待,后面发布的项目就遭殃了。
有段时间我深受其害,想办法解决这种情况。刚好质效部门有个同学有些想法,于是我俩来回拉扯了几次,确定了发布流水线大概功能:每个迭代需求系统自动生成发布清单,
多个迭代可以合并发布,支持一键部署完成代码合并和应用发布。这哥们也是给力,过了一段时间就做好上线了,当然我们部门也就成了第一个吃螃蟹的人。效果很明显,后续发布效率提高了很多。
预发布环境
之前工程部门已经搞过一次,但是没有落地成功。一是方案不是很合理;二是需要对接的业务团队较多,协调困难;三是没有做到开箱即用(工程部只管搭好环境,预发环境的应用还需要业务团队自己部署)。
基于之前的教训,我先是设计出整体实施方案,并得到了技术委员会的通过,然后拉上各业务线技术负责人,告知背景并需要得到资源支持(1 个人就好,小部分应用需要做一点小改造), 最后我就拉上运维开始实施,搭建环境并批量部署应用。
预发环境搭建好之后,白天可以在预发环境(真实的数据一致的环境)测试验收,因为降低了发布风险所以可以提前发布生产了,后续发布到很晚的情况就更少了。
时间怎么分配
负责的业务更多了,大部分事情都会先到我这里。可一天时间就这么多(995 又咋样),怎么办?搬出我的时间四象限:
明年TODO
- 能负责 1 个新产品落地,从 0 到 1 更需要系统设计,更有挑战,也更有成就感
- 跟其他团队合作更多,认识更多的人,发现更多的团队问题
- 个人职级晋升,负责更多的事,担更多的责任(背更多的锅)
- 养成读书习惯,复制行业榜样的经验
职场即战场,很残酷很现实,需要实力和运气,如果当前的情况左右不了,就随它去吧,先丰富自己。