和讯网:由研发开启的中小型组织数字化转型之路

思码逸研发效能
+ 关注
2022-04-27 14:13
261次阅读
 

业务背景

和讯网是一家成立于 1996 年,集资讯、金融数据工具、知识社群等功能于一体的财经服务网站。作为一家核心业务较平稳且传统的企业,和讯网的研发一直处于足够支持业务需求的状态。
 
在数字化趋势下,和讯网研发团队看到了传统业务转型及加速的需求,而研发团队高效高质的交付能力,正是业务转型、快速响应市场需求变化的基石。
 
“我们的思考应该基于怎么做是对的、是有利于将来发展的;而不是自我设限,只着眼于当下能做什么。”基于这样的理念,和讯网研发团队开启了研发数字化转型之路,并以此为支点撬动了组织的业务数字化转型。
 
本文将介绍和讯网自 2019 年至今的数字化实践。持续的探索和学习也带来了成果:以 2021 年为例,效率方面,各部门人均生产率同比提升194%,五个部门周人均生产率高于行业上四分位(前25%),产能稳定性同比提升 36%;质量方面,阻塞、严重问题类型实现清零。
 

效能挑战

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

 

前期基础建设

研发数字化工作从DevOps建设开始。
和讯团队首先将不同职能的责任解耦,明确定义研发、测试、运维三者的边界,使测试承担起全局的质量控制工作。
其次,搭建起包含 SonarQube、Git、Jenkins、TAPD、Cat、Yapi,Zabbix 等工具的 DevOps 工具链,借助工具自动执行规范,同时保障研发过程数据的留存。
 

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

 
为了客观回顾研发过程及成果,和讯团队引入了思码逸研发效能分析平台,对研发效能进行度量。
思码逸平台能够从代码库中提取量化指标,从组织、团队、项目、个人不同层级,提供开发效率、软件工程质量、组织人才发展等多维度洞见,使研发管理不再处于黑盒状态。

建立研发效能度量体系

微软 Velocity Lab 这篇讲解 SPACE 生产力度量框架的论文中提到,如果不顾业务阶段、团队特征等上下文,一刀切地使用单一指标,甚至进行横向对比,就落入了过度简化的陷阱。不仅会给团队带来错误信号,引发质疑,更可能误导一线开发者造数据搞面子工程,效果适得其反。
效能包含了研发工作的多个维度,其度量并不存在银弹。度量本身已经是对软件研发这一复杂系统工程的抽象,必然存在片面性。因此需要通过精细设计,来避免系统性的误差和盲区。
和讯网引入了效能分析工具后,初步建立起了度量体系,便于研发团队基于自身情况灵活选定关键指标:
  • 交付效率
在交付效率方面,基于代码分析能力,代码当量、代码影响力等创新效率指标与需求交付周期、需求交付数量、按期交付率等常见指标形成互补,帮助团队从资源效率+流动效率两个视角进行度量复盘。除了产能指标以外,产出稳定性、贡献分布、工时投入、工作饱和度等数据也帮助团队更全面地理解效率表现。
 
代码当量是衡量开发者修改代码的工作量的指标。
相比代码行数等指标,代码当量能够有效统计代码所包含的逻辑工作量,排除代码风格、换行习惯、注释、格式化操作等因素干扰。
  • 交付质量
在交付质量方面,函数复杂度、模块性、代码复用度、测试覆盖度、注释覆盖度、代码问题积压等侧重软件工程质量的指标,能够作为测试环节质量指标的补充,引导开发人员主动分担质量优化工作,不仅能在开发阶段就避免一大部分基础错误,也能提升代码的可读性与可维护性,避免技术债堆积。
  • 交付价值
在交付价值方面,首先通过投入工时与代码当量/需求交付数量的交叉分析,量化研发环节的投入产出,合理调配研发人力资源;其次,通过将产品团队与需求环节纳入量化考核,需求与业务战略目标直接挂钩,带动产研与战略对齐,这部分实践在后文还会提及。
 
交付成本与交付能力的度量模型还在持续细化与推行落地中。
 

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

考虑到量化管理是由研发管理者引进,而势必对团队原有思维和行为习惯带来冲击,研发效能度量不能一蹴而就。和讯从流程、规范、方法改善起步,不断争取团队共识,培养团队使用数字化度量指标进行复盘的习惯。
  • 第一阶段 选取关键试点,建立感知
    • 对项目效率与质量进行度量反馈,建立团队对量化反馈的感知。
  • 首先在表现较优的部门进行试点,因为数字化度量排除了人际关系等因素,从客观上佐证其优秀,这些部门的心态会更加开放。
  • 要求研发团队先导入活跃项目。这些项目的关注度和更新频率相对较高,也有发版压力,因此效能优先级较高,研发团队也有动力主动去做分析。由于这些项目本身质量问题较少,人手也较充足,软件工程质量将被纳入研发环节交付质量的指标中,受到硬性要求。

 

  • 第二阶段 面向场景建立模型,寻求共识
    • 基于自身情况,设计不同指标权重,建立起面向项目、团队及个人的效能度量模型,洞察研发效能问题并针对性改进,使量化管理的效果在团队内获得认同。
  • 在工作量度量的激励下,团队自发导入低活跃度项目。这些项目的问题积压较多且时间较长,优化成本高,不对这些项目的工程质量做硬性要求。
客观数据提高了研发流程与成果的可见性,不仅向一线研发团队验证了研发管理升级带来的提升,也向非技术部门提供了解研发动向的窗口,为数字化管理的继续推进争取到多方的支持。
 

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

考虑到自身人才资源较薄弱,技术能力、工程实践与一线互联网企业的研发团队存在差距,和讯网研发团队决定将效能度量纳入考核与排行,强化激励效果,缩短奖励周期,提高研发团队主观能动性。目的是为了守住下限,减少由主观因素引起的低效能问题。
  • 第三阶段 引入良性竞争,用数据驱动提升
    • 基于自身需求,和讯网将度量纳入考核与排行,逐步引入良性竞争机制,强化量化指标对研发团队的激励效果。
  • 随着公司内部对数字化管理的接纳度提高,逐步提升量化指标所占考核比重。 2020年年中,量化指标占和讯网研发部门考核比重为30%,年末提升至50%,部门级与个人级的年度评优则完全依照量化考核。
  • 在量化指标中,基于代码分析的产能与效率指标占比30%,软件工程质量指标占比20%;研发过程型指标占比50%。
应用到考核排行,就难免收到对量化模型可信度的质疑。和讯网团队的做法是保证模型的公开透明,广泛征求反馈与建议,达成共识以后不轻易改动。即使出现有争议的案例,则共同讨论模型有无需要查缺补漏之处,而不做特例调整。
 
激励带来了良性竞争。研发团队不仅向内看自身效能变化趋势,也向外看和近似业务性质、近似项目阶段的其他团队的横向对比。直观对比打破了部门间的壁垒,推动部门间自发交流、学习优秀研发实践,使知识能够沉淀下来,并在组织内高效流转。
 

承认管理手段的客观局限

自上而下的量化管理并设置考核目标,是为了守住下限。那么是否可以继续使用管理手段,不断提高要求,达到提升效能的目标呢?
 
和讯网的答案是否定的。
 
前面也提到,守住下限是为了减少由主观因素引起的低效能问题,但仍有很大一部分低效能问题是由系统性的客观因素引起的,管理手段与制度无法解决这部分问题。如果不能意识到管理手段存在客观局限,无限制地要求以主观能动性提升效能,实质上就是“内卷”,即使以开发者的超负荷工作取得了一时提效成果,也是不可持续的。量化管理不应滥用而沦为“卡里斯马型组织”的加持。
 
在和讯网的实践中,以产能指标为例,将行业基线的上四分位线(前25%)设置为考核满分标准。在组织的平均生产率达到行业上四分位线后,CTO 角色不再密切关注这一指标,使其作为日常管理机制继续运行;而个人开发者生产率达到这一标准后,也不再有额外激励。
 
更进一步的提升,需要将效能问题层层拆解,洞察根因,将责任与权限分发到研发团队,以日常的流程体系、软件工具、组织治理、人才培养机制、工程师文化等方面的改进,开启研发提效的第二曲线。
 

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

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

在研发效能的相关讨论中,经常能看到著名的丰田生产方式创始人大野耐一的这句话:那些不懂数据的人是糟糕的,而最最糟糕的人是那些只看数据的人。度量不能停留在数据,重要的是从数据里洞察问题并指导改进。
以下是三种常用的分析方法:
  • 趋势分析
展现度量指标随时间推移的变化趋势,根据走向做出是否需要继续分析的初步结论。
 
如果已经采取措施,可用来验证改善措施有效性;需要注意这里未必选择均值来观察趋势走向,80分位值可能能够更好地排除异常值,反映普遍情况。
  • 下钻分析
从宏观到微观,从表象到根因逐层排查问题,帮助团队找到关键瓶颈。由于北极星指标往往是一个顶层聚合指标,可能有多种拆分下钻的路径。
  • 关联分析
从历史数据中辨别相关性,进而寻找效能瓶颈的关键因素。此外,关联分析也有助于避免单一指标的负向牵引作用,洞察效能全局。
 

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

在开发向测试流转的环节,和讯网要求开发者在提测前,基于自动生成的软件工程质量报告完成自测;测试部门也将度量结果纳入定期高频的报告中,监督质量控制的全流程。
 
需要注意的是,度量与改进都有成本,难以面面俱到。因此,建议基于项目阶段与业务特性,有侧重地选取质量指标。例如:
  • 当项目处于高活跃度的增长期,建议关注重点问题率及代码复用度,以便及时解决关键风险,并预防增长期的风险蔓延
  • 当项目业务逻辑复杂时,建议关注测试覆盖度与模块性,合理拆分解耦模块将有助于复杂项目的维护
  • 当项目进入维护或重构阶段,建议以遗留代码的圈复杂度指标作为质量提升的切入点,同时也通过模块性指标评估架构合理性
  • 人员流动性较大,或需要被其他团队使用的项目,则需要额外留意代码的注释覆盖度
  • 开发人员应在提测前,应扫清本次合并中静态扫描所发现的阻塞与严重级代码问题,这一规范适用于全部项目,在速度与质量间维持平衡;对于处于平稳维护期的项目,则进一步要求扫清既往的阻塞与严重级问题
 

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

以往,和讯研发团队需要等待多个业务部门汇总需求后才能开始开发,时间紧张;在发版前几日批量提测,也给测试环节带来压力;来不及完成开发或被测试打回,就只能延期或砍需求。工作流中大量等待造成浪费,业务方满意度下降。
 
和讯网以需求交付周期、任务按期完成率与工时投入为抓手,鼓励研发团队拆解细化任务,保障任务颗粒度适中、范围明确。任务拆解减少了子任务间的耦合和依赖,提高了并行度,使工时预估准确性大幅提升至80%以上。
 
在量化管理延伸至上游的产品部门后(下文会进一步介绍),产品经理为了保障需求能够快速交付,也更有动力对需求进行拆解和及时澄清,使复杂需求更早进入开发环节。
 
在需求与任务的粒度减小、分批次进入开发后,开发进度更加可控。开发人员在交付周期指标的驱动下,更早地将任务流转到测试阶段,给测试环节留下更多时间,测试人员在发版前还有余裕进行随机测试。小批量提交代码变更 + 频繁进行测试与构建,也降低了软件的质量风险,为团队进一步建设工程能力,试点持续交付打下了基础。
 

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

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

  • 始于一线的产研协同
许多企业的研发数字化转型是由业务需求触发。相比之下,和讯网的情况则有些非典型:由于核心业务较平稳且传统,研发团队并未受到来自业务的太多压力。
 
相反,在推行研发数字化转型后,需求数量不足、需求变更频繁且随意、需求未能带来业务价值等等,反而成为研发团队的瓶颈,研发团队开始推动上游的效率与质量提升。
 
这一现象首先在产研一线呈现:研发团队开始主动向上游要需求,并希望产品部门尽早澄清需求、避免不必要的变更。除此之外,研发团队主动承担了更多测试工作,以主动开启系统需求、性能优化、技术重构等任务,以填补上游需求数量的不足。
  • 逐步推进,将产品部门纳入量化管理
在这个背景下,和讯网将产品需求环节也纳入量化反馈中,对产品经理的行为进行数据留痕,并进行集成、清洗、分析和建模。
 
具体来说,在需求环节,不仅关注数量、类型分布和变更频率,也结合研发团队的相应工作量,评估需求拆分粒度;更进一步,通过追踪需求对应的业务目标达成情况,评估需求质量。
 
和讯网希望依托数据,引导作为收入中心(业务部门)与成本中心(技术部门)之间的产品经理更加关注和平衡投入产出比。
 
在推广思路上,则沿用了研发数字化的“逐步推进”原则,前期不对产品部门做任何要求,而是先建立数据留存机制和习惯,加强产品部门对量化反馈的感知与共识。这也一定程度上保障了数据的真实性和可用性。
 
通过将产品与研发的效能数据沉淀于同一平台,和讯网将两个角色串联起来,在原先职能型组织基础上,强调面向价值交付的业务线组织概念,使数字化管理的影响力跨过部门墙向上游延伸。
 
这样的组织治理强化了一线产研人员对业务价值的感知,使其目标能够与组织战略目标保持对齐,边界更加清晰,是更加强有力的激励机制。
 

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

和讯网规划将产品开发、交付、运营的全生命周期纳入数字化管理。由 2022 年开始,和讯网对研发流程进行调整,在项目管理系统中填写业务线战略目标,需求全部与战略目标挂钩,并统计能够直接带来业务成效的增值类需求比例,带动产研全流程直接与战略目标对齐。
一方面,在全局视角下对各个单点的效能进行更深入的评估,避免局部最优反而对全局优化造成负面影响。
 
另一方面,着眼于端到端的价值交付,避免“效率竖井”,使各产品、项目、部门效能提升能够与组织级的业务价值、降本增效、客户满意度等业务成果关联起来,用精益思想驱动传统业务的加速升级。

[免责声明]

原文标题: 和讯网:由研发开启的中小型组织数字化转型之路

本文由作者原创发布于36氪企服点评;未经许可,禁止转载。

资深作者思码逸研发效能
思码逸研发效能
0
消息通知
咨询入驻
商务合作