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

 

业务背景

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

 

 

效能挑战

前期基础建设

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

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

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

 

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

 

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

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

建立研发效能度量体系

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

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

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

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

 

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

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

 

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

 

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

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

 

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

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

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

 

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

 

承认管理手段的客观局限

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

 

和讯网的答案是否定的。

 

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

 

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

 

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

 

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

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

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

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

 

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

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

 

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

 

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

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

 

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

 

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

 

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

 

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

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

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

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

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

 

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