作者 | 齐凌远
1
业务背景
和讯网是一家成立于 1996 年，集资讯、金融数据工具、知识社群等功能于一体的财经服务网站。作为一家核心业务较平稳且传统的企业，和讯网的研发一直处于足够支持业务需求的状态。
在数字化趋势下，和讯网研发团队看到了传统业务转型及加速的需求，而研发团队高效高质的交付能力，正是业务转型、快速响应市场需求变化的基石。
“我们的思考应该基于怎么做是对的、是有利于将来发展的；而不是自我设限，只着眼于当下能做什么。”基于这样的理念，和讯网研发团队开启了研发数字化转型之路，并以此为支点撬动了组织的业务数字化转型。
本文将介绍和讯网自 2019 年至今的数字化实践。持续的探索和学习也带来了成果：以 2021 年为例，效率方面，各部门人均生产率同比提升 194%，五个部门周人均生产率高于行业上四分位（前 25%），产能稳定性同比提升 36%；质量方面，阻塞、严重问题类型实现清零。
▲代码当量指标来自思码逸深度代码分析系统
2
效能挑战
2019 年和讯开始推行研发数字化管理体系的建设之时，面临内外部多重效能挑战：
管理与改进缺乏量化抓手：难以从软件研发过程及成果中沉淀数据，导致研发团队能力与产出效能无法被数字化评估，管理与改进实质上依赖管理者的主观判断
人才资源相对薄弱：与互联网企业相比，研发团队的技术能力存在差距，体现在产出效率、质量、抗压能力、进取动力等方面。
研发内部工作流待改善：产品发版前的赶工现象仍相当常见，一旦研发环节用时超过预期，测试人员就很被动，大量等待造成了瓶颈和浪费；测试不通过打回版本时，往往已接近发版，大概率造成延期。
受限于上游产品团队：研发团队所创造的业务价值受限上游需求数量与质量不足，造成研发进取动力下降。
3
前期基础建设
研发数字化工作从 DevOps 建设开始。
和讯团队首先将不同职能的责任解耦，明确定义研发、测试、运维三者的边界，使测试承担起全局的质量控制工作。
其次，搭建起包含 SonarQube、Git、Jenkins、TAPD、Cat、Yapi，Zabbix 等工具的 DevOps 工具链，借助工具自动执行规范，同时保障研发过程数据的留存。
4
度量效能，以量化管理守住下限
为了客观回顾研发过程及成果，和讯团队引入了思码逸研发效能分析平台，对研发效能进行度量。
思码逸平台能够从代码库中提取量化指标，从组织、团队、项目、个人不同层级，提供开发效率、软件工程质量、组织人才发展等多维度洞见，使研发管理不再处于黑盒状态。
建立研发效能度量体系
微软 Velocity Lab 这篇讲解 SPACE 生产力度量框架的论文中提到，如果不顾业务阶段、团队特征等上下文，一刀切地使用单一指标，甚至进行横向对比，就落入了过度简化的陷阱。不仅会给团队带来错误信号，引发质疑，更可能误导一线开发者造数据搞面子工程，效果适得其反。
效能包含了研发工作的多个维度，其度量并不存在银弹。度量本身已经是对软件研发这一复杂系统工程的抽象，必然存在片面性。因此需要通过精细设计，来避免系统性的误差和盲区。
和讯网引入了效能分析工具后，初步建立起了度量体系，便于研发团队基于自身情况灵活选定关键指标：
交付效率
在交付效率方面，基于代码分析能力，代码当量、代码影响力等创新效率指标与需求交付周期、需求交付数量、按期交付率等常见指标形成互补，帮助团队从资源效率 + 流动效率两个视角进行度量复盘。除了产能指标以外，产出稳定性、贡献分布、工时投入、工作饱和度等数据也帮助团队更全面地理解效率表现。
相比代码行数等指标，代码当量能够有效统计代码所包含的逻辑工作量，排除代码风格、换行习惯、注释、格式化操作等因素干扰。
交付质量
在交付质量方面，函数复杂度、模块性、代码复用度、测试覆盖度、注释覆盖度、代码问题积压等侧重软件工程质量的指标，能够作为测试环节质量指标的补充，引导开发人员主动分担质量优化工作，不仅能在开发阶段就避免一大部分基础错误，也能提升代码的可读性与可维护性，避免技术债堆积。
交付价值
在交付价值方面，首先通过投入工时与代码当量 / 需求交付数量的交叉分析，量化研发环节的投入产出，合理调配研发人力资源；其次，通过将产品团队与需求环节纳入量化考核，需求与业务战略目标直接挂钩，带动产研与战略对齐，这部分实践在后文还会提及。
交付成本与交付能力的度量模型还在持续细化与推行落地中。
由点及面逐步推进，寻求团队共识
考虑到量化管理是由研发管理者引进，而势必对团队原有思维和行为习惯带来冲击，研发效能度量不能一蹴而就。和讯从流程、规范、方法改善起步，不断争取团队共识，培养团队使用数字化度量指标进行复盘的习惯。
第一阶段 选取关键试点，建立感知
对项目效率与质量进行度量反馈，建立团队对量化反馈的感知。
首先在表现较优的部门进行试点，因为数字化度量排除了人际关系等因素，从客观上佐证其优秀，这些部门的心态会更加开放。
要求研发团队先导入活跃项目。这些项目的关注度和更新频率相对较高，也有发版压力，因此效能优先级较高，研发团队也有动力主动去做分析。由于这些项目本身质量问题较少，人手也较充足，软件工程质量将被纳入研发环节交付质量的指标中，受到硬性要求。
第二阶段 面向场景建立模型，寻求共识
基于自身情况，设计不同指标权重，建立起面向项目、团队及个人的效能度量模型，洞察研发效能问题并针对性改进，使量化管理的效果在团队内获得认同。
在工作量度量的激励下，团队自发导入低活跃度项目。这些项目的问题积压较多且时间较长，优化成本高，不对这些项目的工程质量做硬性要求。
客观数据提高了研发流程与成果的可见性，不仅向一线研发团队验证了研发管理升级带来的提升，也向非技术部门提供了解研发动向的窗口，为数字化管理的继续推进争取到多方的支持。
强化激励，提高主观能动性
考虑到自身人才资源较薄弱，技术能力、工程实践与一线互联网企业的研发团队存在差距，和讯网研发团队决定将效能度量纳入考核与排行，强化激励效果，缩短奖励周期，提高研发团队主观能动性。目的是为了守住下限，减少由主观因素引起的低效能问题。
第三阶段 引入良性竞争，用数据驱动提升
基于自身需求，和讯网将度量纳入考核与排行，逐步引入良性竞争机制，强化量化指标对研发团队的激励效果。
随着公司内部对数字化管理的接纳度提高，逐步提升量化指标所占考核比重。2020 年年中，量化指标占和讯网研发部门考核比重为 30%，年末提升至 50%，部门级与个人级的年度评优则完全依照量化考核。
在量化指标中，基于代码分析的产能与效率指标占比 30%，软件工程质量指标占比 20%；研发过程型指标占比 50%。
应用到考核排行，就难免收到对量化模型可信度的质疑。和讯网团队的做法是保证模型的公开透明，广泛征求反馈与建议，达成共识以后不轻易改动。即使出现有争议的案例，则共同讨论模型有无需要查缺补漏之处，而不做特例调整。
激励带来了良性竞争。研发团队不仅向内看自身效能变化趋势，也向外看和近似业务性质、近似项目阶段的其他团队的横向对比。直观对比打破了部门间的壁垒，推动部门间自发交流、学习优秀研发实践，使知识能够沉淀下来，并在组织内高效流转。
承认管理手段的客观局限
自上而下的量化管理并设置考核目标，是为了守住下限。那么是否可以继续使用管理手段，不断提高要求，达到提升效能的目标呢？
和讯网的答案是否定的。
前面也提到，守住下限是为了减少由主观因素引起的低效能问题，但仍有很大一部分低效能问题是由系统性的客观因素引起的，管理手段与制度无法解决这部分问题。如果不能意识到管理手段存在客观局限，无限制地要求以主观能动性提升效能，实质上就是“内卷”，即使以开发者的超负荷工作取得了一时提效成果，也是不可持续的。量化管理不应滥用而沦为“卡里斯马型组织”的加持。
在和讯网的实践中，以产能指标为例，将行业基线的上四分位线（前 25%）设置为考核满分标准。在组织的平均生产率达到行业上四分位线后，CTO 角色不再密切关注这一指标，使其作为日常管理机制继续运行；而个人开发者生产率达到这一标准后，也不再有额外激励。
更进一步的提升，需要将效能问题层层拆解，洞察根因，将责任与权限分发到研发团队，以日常的流程体系、软件工具、组织治理、人才培养机制、工程师文化等方面的改进，开启研发提效的第二曲线。
5
层层拆解追问根因，在日常中落实工程改进
三种分析方法，定位效能改进关键环节
在研发效能的相关讨论中，经常能看到著名的丰田生产方式创始人大野耐一的这句话：那些不懂数据的人是糟糕的，而最最糟糕的人是那些只看数据的人。度量不能停留在数据，重要的是从数据里洞察问题并指导改进。
以下是三种常用的分析方法：
趋势分析
展现度量指标随时间推移的变化趋势，根据走向做出是否需要继续分析的初步结论。
如果已经采取措施，可用来验证改善措施有效性；需要注意这里未必选择均值来观察趋势走向，80 分位值可能能够更好地排除异常值，反映普遍情况。
下钻分析
从宏观到微观，从表象到根因逐层排查问题，帮助团队找到关键瓶颈。由于北极星指标往往是一个顶层聚合指标，可能有多种拆分下钻的路径。
关联分析
从历史数据中辨别相关性，进而寻找效能瓶颈的关键因素。此外，关联分析也有助于避免单一指标的负向牵引作用，洞察效能全局。
度量工具化、常态化，根据业务特征针对性改进
在开发向测试流转的环节，和讯网要求开发者在提测前，基于自动生成的软件工程质量报告完成自测；测试部门也将度量结果纳入定期高频的报告中，监督质量控制的全流程。
需要注意的是，度量与改进都有成本，难以面面俱到。因此，建议基于项目阶段与业务特性，有侧重地选取质量指标。例如：
当项目处于高活跃度的增长期，建议关注重点问题率及代码复用度，以便及时解决关键风险，并预防增长期的风险蔓延
当项目业务逻辑复杂时，建议关注测试覆盖度与模块性，合理拆分解耦模块将有助于复杂项目的维护
当项目进入维护或重构阶段，建议以遗留代码的圈复杂度指标作为质量提升的切入点，同时也通过模块性指标评估架构合理性
人员流动性较大，或需要被其他团队使用的项目，则需要额外留意代码的注释覆盖度
开发人员应在提测前，应扫清本次合并中静态扫描所发现的阻塞与严重级代码问题，这一规范适用于全部项目，在速度与质量间维持平衡；对于处于平稳维护期的项目，则进一步要求扫清既往的阻塞与严重级问题
量化管理，带动工作流优化
以往，和讯研发团队需要等待多个业务部门汇总需求后才能开始开发，时间紧张；在发版前几日批量提测，也给测试环节带来压力；来不及完成开发或被测试打回，就只能延期或砍需求。工作流中大量等待造成浪费，业务方满意度下降。
和讯网以需求交付周期、任务按期完成率与工时投入为抓手，鼓励研发团队拆解细化任务，保障任务颗粒度适中、范围明确。任务拆解减少了子任务间的耦合和依赖，提高了并行度，使工时预估准确性大幅提升至 80% 以上。
在量化管理延伸至上游的产品部门后（下文会进一步介绍），产品经理为了保障需求能够快速交付，也更有动力对需求进行拆解和及时澄清，使复杂需求更早进入开发环节。
在需求与任务的粒度减小、分批次进入开发后，开发进度更加可控。开发人员在交付周期指标的驱动下，更早地将任务流转到测试阶段，给测试环节留下更多时间，测试人员在发版前还有余裕进行随机测试。小批量提交代码变更 + 频繁进行测试与构建，也降低了软件的质量风险，为团队进一步建设工程能力，试点持续交付打下了基础。
6
向上游输出影响力，撬动业务数字化
串联产品与研发角色，强调价值交付
始于一线的产研协同
许多企业的研发数字化转型是由业务需求触发。相比之下，和讯网的情况则有些非典型：由于核心业务较平稳且传统，研发团队并未受到来自业务的太多压力。
相反，在推行研发数字化转型后，需求数量不足、需求变更频繁且随意、需求未能带来业务价值等等，反而成为研发团队的瓶颈，研发团队开始推动上游的效率与质量提升。
这一现象首先在产研一线呈现：研发团队开始主动向上游要需求，并希望产品部门尽早澄清需求、避免不必要的变更。除此之外，研发团队主动承担了更多测试工作，以主动开启系统需求、性能优化、技术重构等任务，以填补上游需求数量的不足。
逐步推进，将产品部门纳入量化管理
在这个背景下，和讯网将产品需求环节也纳入量化反馈中，对产品经理的行为进行数据留痕，并进行集成、清洗、分析和建模。
具体来说，在需求环节，不仅关注数量、类型分布和变更频率，也结合研发团队的相应工作量，评估需求拆分粒度；更进一步，通过追踪需求对应的业务目标达成情况，评估需求质量。
和讯网希望依托数据，引导作为收入中心（业务部门）与成本中心（技术部门）之间的产品经理更加关注和平衡投入产出比。
在推广思路上，则沿用了研发数字化的“逐步推进”原则，前期不对产品部门做任何要求，而是先建立数据留存机制和习惯，加强产品部门对量化反馈的感知与共识。这也一定程度上保障了数据的真实性和可用性。
通过将产品与研发的效能数据沉淀于同一平台，和讯网将两个角色串联起来，在原先职能型组织基础上，强调面向价值交付的业务线组织概念，使数字化管理的影响力跨过部门墙向上游延伸。
这样的组织治理强化了一线产研人员对业务价值的感知，使其目标能够与组织战略目标保持对齐，边界更加清晰，是更加强有力的激励机制。
业务全流程数字化，产品开发更精益
和讯网规划将产品开发、交付、运营的全生命周期纳入数字化管理。由 2022 年开始，和讯网对研发流程进行调整，在项目管理系统中填写业务线战略目标，需求全部与战略目标挂钩，并统计能够直接带来业务成效的增值类需求比例，带动产研全流程直接与战略目标对齐。
一方面，在全局视角下对各个单点的效能进行更深入的评估，避免局部最优反而对全局优化造成负面影响。
另一方面，着眼于端到端的价值交付，避免“效率竖井”，使各产品、项目、部门效能提升能够与组织级的业务价值、降本增效、客户满意度等业务成果关联起来，用精益思想驱动传统业务的加速升级。
营业执照公示信息