和讯网的研发管理数字化转型之路

阅读本文你将获得: 1、由研发开启的中小型组织数字化转型有哪些挑战; 2、研发团队效能建设的基础准备;3、研发效能量化管理的四大关键步骤;4、层层拆解追问根因,在日常中落实工程改进 5、向上游输出影响力,撬动业务数字化进程;

和讯网的研发管理数字化转型之路

本文共计5100字,建议阅读时间:10~11分钟。

阅读本文你将获得:

1、由研发开启的中小型组织数字化转型有哪些挑战

2、研发团队效能建设的基础准备;

3、研发效能量化管理的四大关键步骤;

4、层层拆解追问根因,在日常中落实工程改进

5、向上游输出影响力,撬动业务数字化进程;

前言:本文将介绍和讯网自 2019 年至今的数字化实践:以 2021 年为例,效率方面,各部门人均生产率同比提升194%,五个部门周人均生产率高于行业上四分位(前25%),产能稳定性同比提升 36%;质量方面,阻塞、严重问题类型实现清零。

01 业务背景

和讯网是一家成立于 1996 年,集资讯、金融数据工具、知识社群等功能于一体的财经服务网站。作为一家核心业务较平稳且传统的企业,和讯网的研发一直处于足够支持业务需求的状态。

在数字化趋势下,和讯网研发团队看到了传统业务转型及加速的需求,而研发团队高效高质的交付能力,正是业务转型、快速响应市场需求变化的基石。

“我们的思考应该基于怎么做是对的、是有利于将来发展的;而不是自我设限,只着眼于当下能做什么。”基于这样的理念,和讯网研发团队开启了研发数字化转型之路,并以此为支点撬动了组织的业务数字化转型。

▲代码当量指标来自思码逸深度代码分析系统

02 效能挑战

2019 年和讯开始推行研发数字化管理体系的建设之时,面临内外部多重效能挑战:

  • 管理与改进缺乏量化抓手:难以从软件研发过程及成果中沉淀数据,导致研发团队能力与产出效能无法被数字化评估,管理与改进实质上依赖管理者的主观判断
  • 人才资源相对薄弱:与互联网企业相比,研发团队的技术能力存在差距,体现在产出效率、质量、抗压能力、进取动力等方面。
  • 研发内部工作流待改善:产品发版前的赶工现象仍相当常见,一旦研发环节用时超过预期,测试人员就很被动,大量等待造成了瓶颈和浪费;测试不通过打回版本时,往往已接近发版,大概率造成延期。
  • 受限于上游产品团队:研发团队所创造的业务价值受限上游需求数量与质量不足,造成研发进取动力下降。

03 前期基础建设

研发数字化工作从DevOps建设开始。

和讯团队首先将不同职能的责任解耦,明确定义研发、测试、运维三者的边界,使测试承担起全局的质量控制工作。

其次,搭建起包含 SonarQube、Git、Jenkins、TAPD、Cat、Yapi,Zabbix 等工具的 DevOps 工具链,借助工具自动执行规范,同时保障研发过程数据的留存。

04 研发效能度量,以量化管理守住下限

为了客观回顾研发过程及成果,和讯团队引入了思码逸研发效能分析平台,对研发效能进行度量。

思码逸平台能够从代码库中提取量化指标,从组织、团队、项目、个人不同层级,提供开发效率、软件工程质量、组织人才发展等多维度洞见,使研发管理不再处于黑盒状态。

建立研发效能度量体系

微软 Velocity Lab 这篇讲解 SPACE 生产力度量框架的论文中提到,如果不顾业务阶段、团队特征等上下文,一刀切地使用单一指标,甚至进行横向对比,就落入了过度简化的陷阱。不仅会给团队带来错误信号,引发质疑,更可能误导一线开发者造数据搞面子工程,效果适得其反。

效能包含了研发工作的多个维度,其度量并不存在银弹。度量本身已经是对软件研发这一复杂系统工程的抽象,必然存在片面性。因此需要通过精细设计,来避免系统性的误差和盲区。

和讯网引入了效能分析工具后,初步建立起了度量体系,便于研发团队基于自身情况灵活选定关键指标:

  • 交付效率

在交付效率方面,基于代码分析能力,代码当量、代码影响力等创新效率指标与需求交付周期、需求交付数量、按期交付率等常见指标形成互补,帮助团队从资源效率+流动效率两个视角进行度量复盘。除了产能指标以外,产出稳定性、贡献分布、工时投入、工作饱和度等数据也帮助团队更全面地理解效率表现。

代码当量是衡量开发者修改代码的工作量的指标。

相比代码行数等指标,代码当量能够有效统计代码所包含的逻辑工作量,排除代码风格、换行习惯、注释、格式化操作等因素干扰。

  • 交付质量

在交付质量方面,函数复杂度、模块性、代码复用度、测试覆盖度、注释覆盖度、代码问题积压等侧重软件工程质量的指标,能够作为测试环节质量指标的补充,引导开发人员主动分担质量优化工作,不仅能在开发阶段就避免一大部分基础错误,也能提升代码的可读性与可维护性,避免技术债堆积。

  • 交付价值

在交付价值方面,首先通过投入工时与代码当量/需求交付数量的交叉分析,量化研发环节的投入产出,合理调配研发人力资源;其次,通过将产品团队与需求环节纳入量化考核,需求与业务战略目标直接挂钩,带动产研与战略对齐,这部分实践在后文还会提及。

交付成本与交付能力的度量模型还在持续细化与推行落地中。

由点及面逐步推进,寻求团队共识

考虑到量化管理是由研发管理者引进,而势必对团队原有思维和行为习惯带来冲击,研发效能度量不能一蹴而就。和讯从流程、规范、方法改善起步,不断争取团队共识,培养团队使用数字化度量指标进行复盘的习惯。

  • 第一阶段  选取关键试点,建立感知
  • 对项目效率与质量进行度量反馈,建立团队对量化反馈的感知。
  • 首先在表现较优的部门进行试点,因为数字化度量排除了人际关系等因素,从客观上佐证其优秀,这些部门的心态会更加开放。
  • 要求研发团队先导入活跃项目。这些项目的关注度和更新频率相对较高,也有发版压力,因此效能优先级较高,研发团队也有动力主动去做分析。由于这些项目本身质量问题较少,人手也较充足,软件工程质量将被纳入研发环节交付质量的指标中,受到硬性要求。
  • 第二阶段 面向场景建立模型,寻求共识
  • 基于自身情况,设计不同指标权重,建立起面向项目、团队及个人的效能度量模型,洞察研发效能问题并针对性改进,使量化管理的效果在团队内获得认同。
  • 在工作量度量的激励下,团队自发导入低活跃度项目。这些项目的问题积压较多且时间较长,优化成本高,不对这些项目的工程质量做硬性要求。

客观数据提高了研发流程与成果的可见性,不仅向一线研发团队验证了研发管理升级带来的提升,也向非技术部门提供了解研发动向的窗口,为数字化管理的继续推进争取到多方的支持。

强化激励,提高主观能动性

考虑到自身人才资源较薄弱,技术能力、工程实践与一线互联网企业的研发团队存在差距,和讯网研发团队决定将效能度量纳入考核与排行,强化激励效果,缩短奖励周期,提高研发团队主观能动性。目的是为了守住下限,减少由主观因素引起的低效能问题。

  • 第三阶段 引入良性竞争,用数据驱动提升
  • 基于自身需求,和讯网将度量纳入考核与排行,逐步引入良性竞争机制,强化量化指标对研发团队的激励效果。
  • 随着公司内部对数字化管理的接纳度提高,逐步提升量化指标所占考核比重。 2020年年中,量化指标占和讯网研发部门考核比重为30%,年末提升至50%,部门级与个人级的年度评优则完全依照量化考核。
  • 在量化指标中,基于代码分析的产能与效率指标占比30%,软件工程质量指标占比20%;研发过程型指标占比50%。

应用到考核排行,就难免收到对量化模型可信度的质疑。和讯网团队的做法是保证模型的公开透明,广泛征求反馈与建议,达成共识以后不轻易改动。即使出现有争议的案例,则共同讨论模型有无需要查缺补漏之处,而不做特例调整。

激励带来了良性竞争。研发团队不仅向内看自身效能变化趋势,也向外看和近似业务性质、近似项目阶段的其他团队的横向对比。直观对比打破了部门间的壁垒,推动部门间自发交流、学习优秀研发实践,使知识能够沉淀下来,并在组织内高效流转。

承认管理手段的客观局限

自上而下的量化管理并设置考核目标,是为了守住下限。那么是否可以继续使用管理手段,不断提高要求,达到提升效能的目标呢?

和讯网的答案是否定的。

前面也提到,守住下限是为了减少由主观因素引起的低效能问题,但仍有很大一部分低效能问题是由系统性的客观因素引起的,管理手段与制度无法解决这部分问题。如果不能意识到管理手段存在客观局限,无限制地要求以主观能动性提升效能,实质上就是“内卷”,即使以开发者的超负荷工作取得了一时提效成果,也是不可持续的。量化管理不应滥用而沦为“卡里斯马型组织”的加持。

在和讯网的实践中,以产能指标为例,将行业基线的上四分位线(前25%)设置为考核满分标准。在组织的平均生产率达到行业上四分位线后,CTO 角色不再密切关注这一指标,使其作为日常管理机制继续运行;而个人开发者生产率达到这一标准后,也不再有额外激励。

更进一步的提升,需要将效能问题层层拆解,洞察根因,将责任与权限分发到研发团队,以日常的流程体系、软件工具、组织治理、人才培养机制、工程师文化等方面的改进,开启研发提效的第二曲线。

05 层层拆解追问根因,在日常中落实工程改进

三种分析方法,定位效能改进关键环节

在研发效能的相关讨论中,经常能看到著名的丰田生产方式创始人大野耐一的这句话:那些不懂数据的人是糟糕的,而最最糟糕的人是那些只看数据的人。度量不能停留在数据,重要的是从数据里洞察问题并指导改进。

以下是三种常用的分析方法:

  • 趋势分析

展现度量指标随时间推移的变化趋势,根据走向做出是否需要继续分析的初步结论。

如果已经采取措施,可用来验证改善措施有效性;需要注意这里未必选择均值来观察趋势走向,80分位值可能能够更好地排除异常值,反映普遍情况。

  • 下钻分析

从宏观到微观,从表象到根因逐层排查问题,帮助团队找到关键瓶颈。由于北极星指标往往是一个顶层聚合指标,可能有多种拆分下钻的路径。

  • 关联分析

从历史数据中辨别相关性,进而寻找效能瓶颈的关键因素。此外,关联分析也有助于避免单一指标的负向牵引作用,洞察效能全局。

度量工具化、常态化,根据业务特征针对性改进

在开发向测试流转的环节,和讯网要求开发者在提测前,基于自动生成的软件工程质量报告完成自测;测试部门也将度量结果纳入定期高频的报告中,监督质量控制的全流程。

需要注意的是,度量与改进都有成本,难以面面俱到。因此,建议基于项目阶段与业务特性,有侧重地选取质量指标。例如:

  • 当项目处于高活跃度的增长期,建议关注重点问题率及代码复用度,以便及时解决关键风险,并预防增长期的风险蔓延
  • 当项目业务逻辑复杂时,建议关注测试覆盖度与模块性,合理拆分解耦模块将有助于复杂项目的维护
  • 当项目进入维护或重构阶段,建议以遗留代码的圈复杂度指标作为质量提升的切入点,同时也通过模块性指标评估架构合理性
  • 人员流动性较大,或需要被其他团队使用的项目,则需要额外留意代码的注释覆盖度
  • 开发人员应在提测前,应扫清本次合并中静态扫描所发现的阻塞与严重级代码问题,这一规范适用于全部项目,在速度与质量间维持平衡;对于处于平稳维护期的项目,则进一步要求扫清既往的阻塞与严重级问题

量化管理,带动工作流优化

以往,和讯研发团队需要等待多个业务部门汇总需求后才能开始开发,时间紧张;在发版前几日批量提测,也给测试环节带来压力;来不及完成开发或被测试打回,就只能延期或砍需求。工作流中大量等待造成浪费,业务方满意度下降。

和讯网以需求交付周期、任务按期完成率与工时投入为抓手,鼓励研发团队拆解细化任务,保障任务颗粒度适中、范围明确。任务拆解减少了子任务间的耦合和依赖,提高了并行度,使工时预估准确性大幅提升至80%以上。

在量化管理延伸至上游的产品部门后(下文会进一步介绍),产品经理为了保障需求能够快速交付,也更有动力对需求进行拆解和及时澄清,使复杂需求更早进入开发环节。

在需求与任务的粒度减小、分批次进入开发后,开发进度更加可控。开发人员在交付周期指标的驱动下,更早地将任务流转到测试阶段,给测试环节留下更多时间,测试人员在发版前还有余裕进行随机测试。小批量提交代码变更 + 频繁进行测试与构建,也降低了软件的质量风险,为团队进一步建设工程能力,试点持续交付打下了基础。

06 向上游输出影响力,撬动业务数字化

串联产品与研发角色,强调价值交付

  • 始于一线的产研协同

许多企业的研发数字化转型是由业务需求触发。相比之下,和讯网的情况则有些非典型:由于核心业务较平稳且传统,研发团队并未受到来自业务的太多压力。

相反,在推行研发数字化转型后,需求数量不足、需求变更频繁且随意、需求未能带来业务价值等等,反而成为研发团队的瓶颈,研发团队开始推动上游的效率与质量提升。

这一现象首先在产研一线呈现:研发团队开始主动向上游要需求,并希望产品部门尽早澄清需求、避免不必要的变更。除此之外,研发团队主动承担了更多测试工作,以主动开启系统需求、性能优化、技术重构等任务,以填补上游需求数量的不足。

  • 逐步推进,将产品部门纳入量化管理

在这个背景下,和讯网将产品需求环节也纳入量化反馈中,对产品经理的行为进行数据留痕,并进行集成、清洗、分析和建模。

具体来说,在需求环节,不仅关注数量、类型分布和变更频率,也结合研发团队的相应工作量,评估需求拆分粒度;更进一步,通过追踪需求对应的业务目标达成情况,评估需求质量。

和讯网希望依托数据,引导作为收入中心(业务部门)与成本中心(技术部门)之间的产品经理更加关注和平衡投入产出比。

在推广思路上,则沿用了研发数字化的“逐步推进”原则,前期不对产品部门做任何要求,而是先建立数据留存机制和习惯,加强产品部门对量化反馈的感知与共识。这也一定程度上保障了数据的真实性和可用性。

通过将产品与研发的效能数据沉淀于同一平台,和讯网将两个角色串联起来,在原先职能型组织基础上,强调面向价值交付的业务线组织概念,使数字化管理的影响力跨过部门墙向上游延伸。

这样的组织治理强化了一线产研人员对业务价值的感知,使其目标能够与组织战略目标保持对齐,边界更加清晰,是更加强有力的激励机制。

业务全流程数字化,产品开发更精益

和讯网规划将产品开发、交付、运营的全生命周期纳入数字化管理。由 2022 年开始,和讯网对研发流程进行调整,在项目管理系统中填写业务线战略目标,需求全部与战略目标挂钩,并统计能够直接带来业务成效的增值类需求比例,带动产研全流程直接与战略目标对齐。

一方面,在全局视角下对各个单点的效能进行更深入的评估,避免局部最优反而对全局优化造成负面影响。

另一方面,着眼于端到端的价值交付,避免“效率竖井”,使各产品、项目、部门效能提升能够与组织级的业务价值、降本增效、客户满意度等业务成果关联起来,用精益思想驱动传统业务的加速升级。

思码逸 Merico 研发效能分析平台,致力于帮助研发团队解决研发效率、研发质量和人才发展三大痛点,提升研发效率与软件工程质量;

如果您想要与思码逸团队交流,欢迎在网站留下联系方式,我们将在24小时内回复。

与先进研发团队并肩

“软件工程在工业生产中越来越重要。一方面,软件供应链快速演进,软件研发越来越复杂;另一方面,市场的快速变化对研发能力提出各种新的要求。而思码逸作为客观的研发效能平台,立足于对软件开发给出创新性的解释,并尝试将研发效能指标标准化。这对由管理者视角、业务视角、人员视角等更多维度更加全面地看待开发过程有很大帮助。”

Mars Sun

腾讯CODE平台产品负责人

“看清组织研发过程、合理有效地进行研发效能度量是牵引组织研发效能提升的关键。思码逸实现了深入代码语义的AST分析能力,引入代码当量将常规的基于代码行的相关研发效能度量方式提升到了一个新的高度,并通过代码层面的分析提供了研发人员的技术栈相关的标签数据,为组织研发选型提供有力的数据支撑,在行业内有很强的借鉴意义!”

杨永强

原滴滴出行代码团队技术负责人

“相信很多产品技术团队把研发效能提升列为重要的目标。然而,到底什么是好的研发效能,却很少有人能够表达清楚,而代码度量指标种类繁多且相对浅层。如何有效对程序员的工作合理量化测量,思码逸团队围绕每次代码提交对应的抽象语法树的变化进行有效评估,去除了代码中的一些干扰和噪音,为我们提供了新的思路和相对准确的一种测量基础。”

唐洪山

原京东科技研发效能部

“思码逸研发效能平台的专业性令人兴奋,非常适合中国快速发展的互联网软件企业使用。很好的帮助我们解决了团队和项目快速增加过程中遇到的研发效能度量、研发质量规范和人才组织发展的问题。后期的咨询和落地解决方案针对性强,问题分析和解决专业、高效。”

应阔浩

自如基础架构部总监

“在越来越多的企业把数字化转型作为核心战略落地主要抓手的大背景下,思码逸作为基于源代码并扩展至项目管理领域的研发效能平台分析工具,能够为企业数字化转型提供明显助力。和讯网在和思码逸合作共创的2年时间里,2020年主要集中于降本增效领域(提升下限),当年技术部的年度绩效位列全公司第一;2021年主要集中于价值达成领域(提升上限),当年技术部被公司评为年度优秀团队。”

杨扬

和讯网CTO

“开发人员状态有起伏是很正常的。采用思码逸的研发效能度量工具,我们不仅能及时发现表现优秀的开发者并给予激励,也能快速发现工作有待改善的开发者,给他们提供精准的指导与帮助,推动整个团队共同进步。”

朱文雷

长亭科技CTO

“思码逸在代码度量层面给出了创新性的解释,给技术管理者带来全新的研发效能度量提升思路和指标抓手工具,看清团队研发效能的短板,知道该往什么地方提升和改进。结合历史数据、行业数据的比对,让管理者、开发者可以看到努力的成果,并且用数据说话,研发团队日益精进。”

周彦斌

云货优选 研发部门负责人

“研发成果的度量可以说是一个世界性难题,开发者的工作之间内容不同、起点不同、用户不同、代码质量不同,既难以简单量化,也难以横向比较。思码逸作出了一个非常有意义的尝试,它一方面找到了有效的研发效能度量方法,另一方面打通了企业边界来开展数据比较,为研发数字化变革提供了一个非常有意义的新角度。”

谢超平

索贝数码副总裁/总工程师

在数字化的浪潮里,研发效能的高低是企业的核心竞争力。我们面对的产品研发都是脑力工作者,研发效能的度量也变的更复杂和有挑战性。思码逸的深度分析系统,用代码当量来更科学的评估开发的工作量,有效避免人为对代码量的干扰。通过MARI模型产出分析报告,帮助我们在公司内研发效能的推进和落地提供新的思路和方法。

谢超平

王蕾 贝壳工程效率负责人

长期以来,我们一直努力在复杂的市场环境中保持和不断提升研发效率及质量。思码逸为我们提供了重要的量化工具,较传统量化方式更客观和实用。目前思码逸的量化结果已经成为我们评价和提高研发效能的重要组成部分。

谢超平

妙盈科技联合创始人&CTO 刘涛

我们的客户

打开研发管理黑盒,数据驱动研发效能
立即试用
立即预约
在线客服
扫码添加咨询微信
售前电话
在线客服
免费试用
扫码添加咨询微信
长按二维码下载

取消