转转-李金城-管理视角看效率：转转研发效能管理.pdf

1、管理视角看效率：转转研发效能管理李金城转转-技术VP 技术基建对效率的影响 技术选型对效率的影响 历史包袱对效率额影响 组织对效率的影响 日常效率管理保障体系目录20152018 转转FE没统一技术栈，各种新技术，重复造轮子，但基建却几乎没有，随着团队扩大，效率问题、质量问题频发，18年开始加强基建建设。方向确定后，成立前端技术委员会，一起决策，最大化共识从业务调人，扩大前端基础架构团队，专人专事持续建设从统一开发框架开始，前台VUE，后台React，聚焦沉淀修改晋升标准，逐步加强统一基建共识，严控重复造轮子19年底局面开始扭转，随着基建日趋完善，团队从忙于救火转为追求卓越。组件库组件占比 6

2、7%，页面开发效率提升 30%，UI还原度90%+运营自助生成运营活动占比 95%页面平均打开时间低于 0.8s统一是基建最快的路（技术基建对效率的影响统一是基建最快的路（技术基建对效率的影响）转转测试环境治理过程：2017年成立之初，转转测试环境只有5台64G内存的老机器，搭5个完整的测试环境，够用，但不太好用。2019年上线了基于IP路由的动态增量部署方式，硬件资源下降30%，够用，比以前好一些。2021年上线了基于标签路由的动态增量部署方式。稳定性提升 95%部署时间5分钟以内，降低 70%资源自动回收，从消耗3200G到1200G，降低 60%回想起来，理想方案应该更早研发。所以高频使

3、用的基建不能只是够用，要尽早做到位，复利带来的收益远超一时的投入。高频使用的基建，不能只是够用（技术基建对效率的影响高频使用的基建，不能只是够用（技术基建对效率的影响）2016年，转转APP基于Native开发，一月一版业务觉得慢。开始试着加大客户端投入，两版并行两周一版，连轴转，问题有好转但人受不了。最终转为Hybrid开发模式，70%的页面交给FE开发，发版快还省人，问题轻松解决了。技术方案选对了，事半功倍技术方案选对了，事半功倍（技术选型对效率的影响）（技术选型对效率的影响）2016年之后再没出现过发版瓶颈问题H5比双端原生开发效率提升了40%当然也引入了体验不如Native的问题，我们

4、通过预渲染技术，H5的体验问题大幅改善。高PV页面首屏时间:485ms 高PV页面加载完成:693ms技术不能封闭，要走出去，加强交流，扩大视野。21年转转联合去哪儿创建ITCP联盟，效果不错。技术债重要不紧急，常常被忽视，积少成多，慢慢会导致效率和稳定性下滑，如果拖到问题集中爆发，那影响很差，解决成本非常高。防微杜渐的一些方法：大债要记录，强制保持10%20%技术建设投入。年底1-2月业务规划阶段，集中瘦身、还债。online问题跟进机制，监控线下和线上质量趋势。控制技术债（历史包袱对效率的影响）控制技术债（历史包袱对效率的影响）2017年，为了实现新业务快速规模化，启动中台建设，宏观层面收

5、益大，微观层面问题多。新业务3-5个人，两周就能跑通完整流程。业务人才投入减少，人才能力要求降低。链路变长，结构变复杂，协同、学习难度加大。中台是个双刃剑中台是个双刃剑-控制沟通成本（组织对效率的影响）控制沟通成本（组织对效率的影响）21年转转、找靓机合并，进行了中台系统整合，刚整合完，赶上需求量暴增，导致系统质量失控，成为效率瓶颈。经过分析，先和公司汇报问题根源和改进措施，争取到公司支持。制定需求管理规则，控制需求节奏，预留40%内建资源。解决系统隐患，重点完善自助平台，降低沟通与熟悉成本。组建中台BP，走进业务，从支撑转为赋能业务。2017年，转转QA主要负责功能测试，业务增长很快，QA人

6、口增长更快，人多了质量还在降低。测试团队要尽量小（组织对效率的影响）测试团队要尽量小（组织对效率的影响）要从“保姆”向质量保障转型。聚焦核心项目：强制推行开发自测率50%，边缘系统QA不介入，QA工作减少30%，质量基本没影响。提高提测质量：控需求优先级、抓需求质量、编码质量、冒烟case通过率等，bug/case持续降低，后面发现的问题少了，效率自然提升了。扩大测试开发比例，加强测试平台建设。例如：case管理、接口管理、自动化测试能力、数据构造能力、自动化压测能力、兼容性