研发人员轮岗与交流自查报告

研发人员轮岗与交流自查报告本次自查针对我部门2022年1月至2023年6月推行的研发人员跨模块轮岗交流机制展开，覆盖部门全部32名研发人员，其中参与过至少一次轮岗的共27人，本次自查通过梳理轮岗全流程档案、一对一访谈参与人员及对接负责人、统计轮岗前后项目效能与人才成长数据，全面梳理机制运行的成效、存在的深层问题，并形成可落地的改进方案。在推行轮岗交流之前，我部门作为公司的技术中台部门，下辖用户中心、交易中心、配置中心、风控中心四个核心模块，长期存在三个难以解决的痛点：一是模块技术墙固化，每个模块的研发长期深耕自己的领域，对其他模块的技术逻辑和业务痛点几乎不了解，全链路压测的时候，只要涉及多个模块的问题，就得拉齐四五个研发一起定位，沟通成本极高，经常出现一个跨模块的小问题拖两三天才能解决的情况；二是核心人才单点依赖，四个核心模块中，交易中心的支付核心逻辑只有3名资深研发能独立修改，风控中心的规则引擎只有2名研发能维护，一旦核心人员请假、离职，整个模块的开发进度就会陷入停滞，2021年就曾经出现过交易中心核心骨干休年假，一个线上支付超时的问题拖了12小时才定位修复，给业务造成了不小的损失；三是新人成长速度慢，新入职的研发一般都会固定在某个模块，只能接触到局部的技术点，至少需要2年才能熟悉整个中台的全链路逻辑，很多工作1-2年的研发遇到跨模块问题根本无从下手，成长速度远达不到公司业务扩张的需求。正是基于这些痛点，我们才推出了跨模块轮岗交流机制，希望通过人员流动打破模块墙，培养全链路研发人才，降低核心节点的依赖风险。推行18个月以来，轮岗交流机制已经初步显现出效果，首先是核心模块的抗风险能力明显提升，截至2023年6月，四个核心模块中，能独立承接核心开发工作的人数从原来的12人增长到26人，每个核心模块至少有4名研发能独立处理线上问题，核心人员缺位导致项目停滞的情况从2021年的4次降到2022年的0次，2023年上半年也没有出现类似问题；去年双11大促之前，我们需要对交易中心的分库分表做扩容改造，原来这个工作只能由原来的3名核心研发承接，预估需要2周才能完成，这次扩容有5名经过轮岗的研发参与，只用了5天就完成了开发和测试，提前完成了大促准备工作。其次是研发人员的成长速度明显加快，从我们统计的数据来看，参与轮岗的初级研发，12个月内掌握至少两个模块技术栈的比例达到83%，而未参与轮岗的同层级研发这个比例只有36%，很多原来只会做单一模块开发的研发，经过轮岗后已经能独立承接端到端的项目开发，去年部门有3名初级研发通过轮岗成长，提前半年晋升为中级研发，这在之前是从来没有过的。第三是倒逼了技术知识的显性化沉淀，原来各个模块的很多技术逻辑都是掌握在老员工脑子里，文档写的非常简略，新人接手全靠老员工口口相传，轮岗机制推行后，因为每个研发都要把自己的工作交接给别人，也要接手别人的工作，所以倒逼各个模块完善了技术文档和接口说明，部门整体的技术文档完整率从2021年底的62%提升到2023年中的94%，接口测试覆盖率从58%提升到87%，不仅降低了新人接手的难度，也减少了因为文档不全导致的线上问题。第四是激发了技术创新，不同模块的研发带来不同的技术思维，很多原来惯性存在的问题被新进入的研发发现，比如2022年下半年，原来做前端工程化的中级研发轮岗到配置中心模块，发现配置中心原来每个业务线都重复开发了一套配置生效监听逻辑，总共重复了12套，每年光维护成本就需要三四十人天，他结合原来做前端工程化的组件化经验，提出了抽离公共监听组件的重构方案，方案落地后，删掉了12份重复代码，每年可以节省30人天左右的维护成本，还降低了配置不生效的线上问题发生率，这个优化如果没有跨模块轮岗，根本不可能被发现，因为原来配置中心的研发已经习惯了原来的开发模式，不会觉得有问题。本次自查对不同层级研发的轮岗效果做了统计对比，具体数据如下：研发层级参与轮岗人数平均轮岗周期轮岗组代码评审合格率轮岗组跨模块问题平均响应时长轮岗组12个月内晋升通过率同层级未轮岗组代码评审合格率同层级未轮岗组跨模块问题平均响应时长同层级未轮岗组12个月内晋升通过率工作1-2年初级研发126.1个月92.3%42分钟33.3%83.7%78分钟16.7%工作3-5年中级研发84.5个月89.1%38分钟25.0%80.5%61分钟14.3%工作5年以上高级研发/技术专家73.2个月76.2%58分钟14.3%77.8%52分钟11.8%从统计数据和访谈结果来看，我们的轮岗交流机制还存在很多深层的问题，远没有达到预期的效果，主要体现在四个方面：第一，轮岗匹配机制粗放，没有结合个人成长规划和岗位需求，大部分轮岗还是“缺人补位”式的被动安排，不是计划性的成长培养。我们梳理了27次轮岗记录，其中有16次是因为接收模块有人离职或者项目赶进度，临时从其他模块调人过去轮岗，占到了总轮岗数的59%，只有11次是结合研发个人成长规划做的计划性安排，占比只有41%。这种被动安排的问题非常突出，比如去年有一个想深耕前端工程化的初级研发，因为我们配置中心缺一个做页面的人，就把他安排过去轮岗做后端业务配置页面开发，他本身对后端开发没有兴趣，接收部门也只是把他当成临时劳动力，只安排他改改bug做做页面，没有给他接触核心配置逻辑的机会，半年轮岗下来，他既没有学到想要的前端工程化经验，也没有掌握配置中心的核心技术，属于两边都不沾，浪费了半年的成长时间。还有的情况是，接收模块想要一个有架构经验的高级研发，结果给塞了一个刚工作一年的初级研发，接收模块不满意，研发本身也压力很大，最后轮岗效果自然好不了。第二，过程管理和考核衔接机制缺失，导致很多轮岗沦为“打酱油”。首先是考核权责不清，原来我们规定轮岗人员的考核由原部门和接收部门各占50%，但是实际运行中，两个部门都不愿意承担考核责任：接收部门觉得研发呆不了半年就要走，不愿意花精力培养，也不愿意给核心工作，怕刚培养出来就走了，所以只给安排一些杂活、边角活，考核的时候要么给个平均分不得罪人，要么就觉得你干的活少给低分；原部门觉得研发现在在接收部门干活，自己不了解情况，也不愿意管，最后就是考核流于形式，研发干好干坏一个样，自然没有动力。其次是原工作的衔接不到位，很多研发轮岗之后，原模块的工作没有完全交出去，原部门遇到原来的问题还是会找他，导致研发大部分时间都在处理原来模块的杂事，根本没有精力投入新模块的工作，我们访谈的时候，有超过60%的轮岗研发表示，自己每周至少要花2天时间处理原模块的遗留问题，有的甚至占到了一半以上的工作时间，根本没办法沉下心学习新模块的技术。还有就是进出交接没有规范，2022年底就出现过一次线上事故：一个资深研发从用户中心轮岗到风控中心，走的时候只交了纸质文档，没有带接手的人做两周的实操交接，也没有兜底机制，结果一个登录态异常的问题，新接手的研发找不到问题根源，耽误了三个多小时才修复，影响了近千名用户的使用，就是因为交接机制不完善。第三，方案设计一刀切，没有针对不同层级研发设计差异化的轮岗目标，导致高级研发和专家轮岗阻力大、效果差。从上面的统计表格就能看出来，我们的轮岗对初级和中级研发的成长促进非常明显，但是对工作5年以上的高级研发和技术专家来说，效果反而不如不轮岗，核心问题就是我们用同样的要求要求所有层级的研发，让高级研发也从头开始做新模块的业务开发，相当于让一个领域的专家去做初级研发的工作，一方面高级研发放不下面子，从头学基础开发觉得掉身价，另一方面，高级研发的时间成本很高，花半年时间做基础开发，对个人和公司都是浪费，所以很多高级研发都不愿意参与轮岗，我们部门7名高级研发，只有3名完成了完整周期的轮岗，剩下4名都因为各种原因中途回到了原模块，而且完成轮岗的高级研发，大部分也没有产出有价值的成果，只是完成了基础的开发任务，没有发挥出他们的经验优势。还有的高级研发，原来在原模块是负责人，轮岗之后变成了普通开发，心理落差大，工作积极性也不高，自然出不了效果。第四，跨部门轮岗交流通道不畅，目前大部分轮岗都是部门内部的跨模块轮岗，跨部门、跨条线的轮岗几乎没有，限制了人才的成长空间。我们现在27次轮岗，全部都是我们中台部门内部四个模块之间的轮岗，没有一次是跨到业务线、产品部、测试部或者其他技术部门的轮岗，核心障碍就是跨部门轮岗涉及到编制、考核、晋升的问题，两个部门的负责人都有顾虑：原部门负责人觉得，我把人放出去轮岗，半年一年回来，我给人留着位置，但是人会不会被对方部门挖走，就算回来，我这边的活也没人干，得不偿失；接收部门负责人觉得，人编制不在我这，考核我只能提意见，最后晋升还是原部门说了算，我花精力培养，最后给别人做嫁衣，也不愿意接收。所以跨部门轮岗一直推不动，而很多研发想要成长，就需要接触业务前端、接触产品需求，只在中台内部轮，根本得不到这些经验，很多想往技术管理方向发展的研发，也没有机会接触不同领域的管理工作，成长受限。针对本次自查发现的问题，我们结合访谈中研发提出的建议，梳理出了五个方面的可落地改进方案，接下来会逐步推行：第一，优化轮岗匹配机制，建立“个人申报-部门规划-双向选择”的准入匹配体系，取消被动补位式的轮岗安排。每年年底绩效沟通的时候，要求所有研发结合自己的绩效结果和未来1-2年的成长规划，申报自己的轮岗意向，明确自己想要提升的能力方向和意向轮岗的模块/部门，部门层面会结合每个模块的人才培养需求、核心节点备份需求，梳理出年度轮岗岗位清单，明确每个岗位需要的能力、要达成的目标，然后研发和接收模块双向选择，最后由部门统筹确定最终的轮岗名单，从根源上避免“乱点鸳鸯谱”的问题。比如想要深耕前端工程化的研发，我们就会给他安排到前端公共组件组轮岗，想要往技术架构方向发展的研发，我们就会安排他到核心业务模块和基础架构模块轮岗，匹配个人发展需求，从根源上提升研发的参与积极性。同时我们也设置了准入门槛，要求申请轮岗的研发必须把原模块的工作梳理清楚，原模块已经确定了接班人，能够承接原有工作，才能批准轮岗，避免出现人走了工作没人接的情况。第二，重构过程管理和考核衔接机制，明确权责，避免轮岗流于形式。首先调整考核权重，轮岗期间的考核，接收部门占70%，原部门占30%，并且明确要求接收部门必须给轮岗人员安排至少一个完整的独立子项目，要求轮岗结束必须产出可验证的成果，不能只安排杂活，接收部门负责人要对轮岗成果负责，如果一个轮岗人员结束后没有产出合格的成果，会影响接收部门负责人的年度考核，从制度上倒逼接收部门重视轮岗人员的培养。其次明确原工作交接要求，研发轮岗之后，原模块的工作必须完全交接给接班人，除非出现影响线上生产的重大问题，否则原部门不得找轮岗人员处理原有工作，如果确实需要轮岗人员协助，需要经过两个部门负责人共同签字批准，并且计入原部门的工作量，从制度上保证轮岗人员能把全部精力投入到新模块的工作中。然后完善进出交接规范，不管是进入新模块还是离开原模块，都必须设置至少两周的交接缓冲期，交接期内需要完成文档梳理、实操带教、问题复现三个环节，交接完成后需要交接人、承接人、部门负责人三方签字确认，并且交接人需要对交接内容兜底三个月，三个月内因为交接不清出现的问题，交接人要承担主要责任，从制度上避免交接不清导致的问题。第三，针对不同层级研发设计差异化的轮岗方案，分层设定目标，避免一刀切。对于工作1-2年的初级研发，定位为成长型轮岗，核心目标是拓展技术栈，熟悉中台全链路逻辑，轮岗周期设定为6-12个月，要求参与至少一个完整的项目迭代，能够独立处理新模块的日常开发和常见线上问题，考核重点就是技术掌握程度和项目参与度；对于工作3-5年的中级研发，定位为补全型轮岗，核心目标是补全能力短板，培养端到端开发能力，轮岗周期设定为3-6个月，要求能够独立带领一个小团队完成一个完整功能的开发，能够梳理出新模块的技术痛点，提出至少1-2个优化建议，考核重点是解决问题的能力和产出成果；对于工作5年以上的高级研发和技术专家，定位为交流型轮岗，核心目标是输出经验，发现跨模块的共性问题，带动整个部门的技术提升，不要求从头做基础开发，而是要求带着原有模块的技术经验，到新模块梳理架构问题，输出优化方案，培养新模块的研发人员，比如原来做基础架构的专家，可以轮岗到业务模块，帮助业务模块梳理架构痛点，做架构重构，发挥自己的经验优势，轮岗周期设定为1-3个月，考核重点就是输出方案的质量和对新模块的技术提升，这样既不会浪费高级研发的时间，也解决了高级研发放不下面子的问题，提升他们参与轮岗的积极性。第四，打通跨部门轮岗交流通道，推动更大范围的人员交流。我们已经和公司人才发展部门沟通，接下来会推行跨部门轮岗的配套制度：跨部门轮岗不改变研发的原有编制和职级，原部门保留研发的晋升资格，考核由接收部门给出主要意见，原部门结合接收部门意见做最终评定，同时公司层面明确，未来所有技术管理岗的竞聘，必须有至少一次跨部门轮岗经历，从制度上倒逼大家参与跨部门轮岗。接下来我们部门已经安排了两个高级研发，分别轮去前端业务线和产品部，其中一个去前端业务线是为了了解业务端对中台接口的需求，改进中台的接口设计，另一个去产品部是为了学习产品思维，提升后续和产品对接的效率，周期都是三个月，后续我们每年都会安排至少3-5名研发参与跨部门轮岗，拓展研发的能力边界。第五，建立轮岗后的知识沉淀和共享机制，放大轮岗的价值。要求所有研发轮岗结束后，必须输出一份完整的轮岗总结，内容包括自己在新模块学到的技术知识、发现的跨模块问题、提出的优化改进建议，然后部门每个季度组织一次