公司人力部提供了参加研发效能研讨会的学习机会，半日聆听奋笔疾记，升维思考，觅得同道知音，慢慢放下怀疑主义者的傲娇，最大的感触是各大创新殊途同归，真正的变革并非仅仅是引入新技术，还重在日常细节中洞察人性，重塑组织的协作与文化。
本文源自某头部券商资深技术领导者zlx的思考与实践，揭示研发效能提升背后的智慧与艰辛。开局时带着从武将转型文官的困惑，跨越传统项目转型险阻；中间经历了“度量=KPI”的巨大惯性，照搬经典的短暂试水、虚拟组织的“康威定律”困局；最后能行军布阵、步步为营地规划和执行，乃至全链路资产数字化重塑创新。
讲者摒弃了刻板的公文式套路，从研发者的视角探索管理实践，注重现实案例而非抽象理论，谈笑间每一步都凝聚着对研发本质的深入思考，听众身临其境、感同身受、其乐融融。
让我们一同踏上这段启发性的旅程，领略头部券商如何在研发效能的道路上披荆斩棘，最终锻造出真正高效、灵活且富有创造力的组织。
选择一个有十几年开发实战经验、能做业务开发-交付-增长、自谦对“研发效能”是门外汉的少壮派，负责研发效能建设。负责人坦言感觉“挺难的”，不像做业务那么好汇报。【思】永远不要怀疑老板的眼光和魄力。知人善任，得人者兴，结果确实是大开四方，让人耳目一新。“现在发布一个牵扯到交易方面的需求，可能要七八个团队去配合，这里边有大量的沟通协作对齐……需要全局提升”真正的研发效能提升应该聚焦于传统的、难以转型的项目，而不仅仅是已经相对敏捷的项目。这些传统项目，尤其是核心交易系统，往往涉及多个团队和复杂的协作过程，是效能提升的最大瓶颈，也是最具价值的改进点。要实现真正的效能提升，必须采取全局视角，将这些复杂项目及其相关环节全部纳入改进范围，而不是仅仅关注表面的敏捷性提升。【思】和研发者一起想着如何共同进步，而不是空想着怎么“效能管理”研发人员。度量与KPI是截然不同的概念，但常被误解。领导层和团队往往将度量视为考核工具，导致团队抵触情绪。实际上，度量的真正目的是促进改进，而非评判表现。改变这种误解需要持续的沟通和教育，这是一个渐进的过程。【思】度量名字取得不好，很容易和KPI关联，现在做的，越来越不是传统意义上的量化，而是全息扫描。度量数据不应该成为考核的借口，仅仅考核出不了优秀的产品。演讲者强调了度量与KPI的本质区别。度量的真正目的是发现问题并推动改进，而非简单地作为考核指标。他通过业务上线率的例子说明，当度量被视为KPI时，可能导致数据失真。比如为了达到90%以上的上线率，团队可能会故意设置靠后的上线时间或频繁申请变更时间，使得这个KPI一直都是99%以上。这不仅无助于改进，反而可能产生负面循环。演讲者还提到了千行代码bug率这样的负面指标，可能导致bug不登记或加大估算规模，暗示了选择合适度量指标的重要性。此外，他强调了数据自动化采集的必要性，以及在各个层面反复强调"度量不等于KPI"这一理念的重要性。演讲者调侃kpi、员工画像会被批判为“反人性”。一些考核指标可能会产生负面效果。比如考核外包人员的人均任务数,容易导致外包人员为了完成指标而过度拆分任务。同样,考核自有员工的人均交付业务需求数量,也会使他们倾向于将需求拆分成多个小的story。这种做法可能在短期内看起来非常敏捷,大部分story都能在2天内完成。然而,这种做法存在诸多问题:准出标准不高、下游系统可用性差、各团队颗粒度不统一导致难以横向比较,形成了竖井式、散点式交付模式,忽视了端到端的价值交付。此外,金融IT部门一般显得很强势,强制要求业务方拆分需求（导致业务满意度下降）。这些都是典型的内耗型指标。【思】KPI就像是面具，戴久了，就长在脸上摘不下来了！为改善这种状况, 演讲者提出按stories的共同父需求epic进行考核,只关注父需求的平均交付时间。这种方法有助于从全局角度出发,以最终交付的产品为导向。在评估父需求时,我们需要考虑多个因素:涉及的系统数量、交付时长、评估工时、实际工时、新功能类型、优化类型以及测试用例数等。综合这些参数,我们可以对父需求的规模做出更准确的估算。 这种父需求评估方法相当于一个复杂的当量计算,大家难以轻易造假。无论一个需求是复杂的、中等的还是简单的,都可以通过这种方法进行评估。这样一来,管理层就不会仅仅关注需求的数量,而是更加注重需求的质量和整体价值。公司为提升IT效能所采取了系统性方法。通过建立三层架构的机制，包括高层的委员会、效能执行机构、以及各基层对接人，公司旨在创建一个可持续发展的公司级效能体系。宏观层面，这个体系强调全面的流程和结构改进，通过定期的委员会会议来监督和推动整体效能的提升。尽管在实施过程中面临一些挑战，如维持高层次的季度效能会议面临的实际困难，但这种结构化的方法为持续改进IT效能奠定了基础。微观层面，针对跨组协作的挑战，提出通过IT产品经理进行纵向业务交付的细粒度协调，形成纵向的敏捷小队，改善协作。然而，这个方案在实施过程中遇到了障碍。演讲者引用康威定律来解释这一现象，既有的组织结构和权力关系深刻影响着员工的行为和决策，这成为了效能提升的主要障碍。【思】反康威定律非常难，讲者在本文最后一节提了一个解法和案例演讲者强调，简单套用经典学习理论难以在企业中取得实质性成效。虽然初期学习r名师写的经典效能书籍，感觉好像发现新大陆一样，就是觉得这个东西应用下去就可以有什么变化，初期实践常带来虚假的成功感，但长期来看“后面发现没什么变化”。这是因为每个企业的组织文化都有其独特性，因此学习实践方法需要根据具体情况进行调整和定制，而非照搬照抄。真正的数字化转型应该从内部效能提升开始，而不仅仅是实施新的功能系统。通过提升组织效能、流程效能和工程效能，可以为数字化转型奠定坚实的基础，从而实现更高的价值交付。同时，培养良好的项目文化和进行有效的内部宣传也是效能提升的重要组成部分。演讲者深入探讨了在复杂的软件开发环境中优化协作流程的重要性和具体方法。首先，他强调了建立清晰的需求标准和准入标准的必要性，打造出了很好的需求模板，这是确保项目顺利进行的基础。在跨团队协作方面，演讲者指出当前存在的问题：多个团队（包括核心业务、SIT、UAT、账户、中台等）之间的协作极其复杂，常常导致相互抱怨和交付效率低下。为此，他提出要通过优化流程，促进价值流动，明确显示规则，并控制在制品数量。演讲者特别强调了测试环节的重要性和当前面临的挑战。他以一个具体案例说明：表面上看是测试资源不足，但实际问题在于系统复杂度高，测试准备工作繁琐。测试过程本身并不复杂，但环境准备和依赖项对齐非常耗时。针对这一问题，他建议制定更严格的规范，优化测试流程，并建立合理的优先级申请机制。为了提高效率，演讲者介绍了几个自主开发的辅助工具：1. 人力甘特图：让项目管理者能够清晰地看到每个开发人员的任务时间安排，自动提示任务过载或空闲情况。2. 交付物排期表：旨在记录真实的交付时间，而不受KPI影响。这个工具允许团队间灵活调整交付时间，促进更有效的协作。3. 内部IM系统：能够一键将相关方拉入群组，实现自动归档，提高沟通效率。演讲者强调，这些流程优化和工具开发的目的是为了真正提高团队协作效率和项目管理水平，而不仅仅是为了达成KPI指标。他呼吁团队成员关注实际交付质量和效率，通过持续的流程改进和工具优化，最终实现更高效、更协调的软件开发流程。这个团队最初只专注于协作，现在正在扩展其职能范围。他们发现公司内部其他团队，如技术运营和基础设施团队，已经开发了一些专业平台，有成熟的工具用于监控系统健康状况、检测异常，甚至应用智能算法来减少误报。计划与这些专业团队合作，将这些专业平台进行"上层化"处理，整合到一个统一的效能平台中。这样做的目的是让更多人能够以相对基础的方式使用这些专业能力，从而提高整体工程效能。演讲者介绍了一种资产架构体系,核心是建立需求、代码、制品和环境之间的全链路关联。这种关联始于要求开发人员在提交代码时附上需求的Task ID,逐渐得到了各方面的接受。这种关联不仅便于测试人员判断需求是否真正完成,还能在出现线上问题时快速追溯受影响的范围。以某一个面向客户的业务系统为例,演讲者介绍了如何通过建立制品和需求的关联关系,提高软件发布的质量和效率。这种方法可以有效防止遗漏或多余的需求进入发布版本。演讲者展示了"制品图谱"实践,通过自动化流程将制品部署信息回传给平台。这使得团队成员可以轻松查看某个需求在特定环境中的部署状态和时间,大大减少了沟通协作的成本。素材来源官方媒体/网络新闻
《研发效能(DevOps)工程师》工信部教考中心-职业技术证书
🏆 考取证书，提升职业竞争力！
报名咨询：黛西老师159 1031 7788
1门顶5门，学习端到端的研发生命周期！
稳稳拿捏400+技术技能知识点。
![]()
