案例背景

以需求为核心的研发效率度量

贝壳致力于推进居住服务的产业数字化、智能化进程。通过聚合、助力优质服务者，提供包括二手房交易、新房交易、租赁、家装、家居、家服等一站式服务。

站在房产与互联网行业的交集，贝壳的组织文化、技术架构与典型互联网企业有所不同：业务链条长、线上线下大范围协同、一线业务需求由研发中台统一承接，研发团队与业务方的距离更远、沟通成本更高。

这就要求研发效能建设扩大视野，不仅要服务于研发团队，而要兼顾业务、产品、研发多方视角，关注价值交付全链路。只有重视全局优化，才能避免研发埋头猛干和局部优化，让研发提效转化为实实在在的业务加速。

而需求在流动的过程中，恰好串联起了业务、产品、研发各个角色。需求这一概念对于各方都是可感知、可理解的。以需求核心的研发效率度量，为跨部门沟通与协同提效提供了共识基础。

基础设施建设：流程与工具收归统一平台

在发展前期，各业务团队各自建设系统、平台和工具链；加盟商或子公司则研发流程都存在差异。随着贝壳的规模扩大，反复造轮子的情况严重，跨业务协同困难。

通过 2020-2023 持续几年的建设，贝壳将产研全流程收归至统一平台，并加强了规范方面的要求。这首先保障了需求数据完整且准确，其次需求与任务、代码等各阶段交付物强关联，为后续的需求颗粒度校准提供了良好基础。

思码逸解决方案

将“忽大忽小”的需求控制在合理区间，让度量更可信

作为度量体系核心的需求指标，却由于受主观因素影响较大，存在数据不全不准、需求大小不一等问题。如果“需求”这一基本单位所代表的研发工作量都是不确定的，“需求交付速率”“需求交付周期”等指标难免模棱两可，无法可靠说明研发效率现状。

贝壳通过思码逸引入了更准确的编码工作量指标——代码当量。在贝壳看来，这个指标的优势在于直接从代码提交中解析获得编码工作量的信息，换句话说，代码当量仅依赖代码这一研发中间产物，受主观因素影响较小。同时，代码当量排除了代码风格、换行习惯、注释、格式化操作等干扰，准确度方面优于传统的代码行数指标。

贝壳使用代码当量指标，量化每个需求对应多少编码工作量，进一步分析需求颗粒度的分布情况。基于数据，贝壳可以了解各业务团队的需求拆分是否合理，颗粒度是否相对稳定。在全面了解的基础上，建立起组织级基线，及时识别超出基线、颗粒大小异常的需求点，并给出引导。

同理，代码当量也可以用来量化 Merge Request（也称为 Pull Request）的颗粒度。贝壳设定了 MR 颗粒度建议值，引导团队改进工程实践，避免 MR 过大带来的问题多、冲突多、测试 debug 成本高的问题。

识别故事点预估/工时记录的偏差，辅助研发流程规范化

在引入代码当量前，贝壳也尝试使用其他指标指标来量化需求的大小：规划阶段的故事点估算，和事后记录的工时。前者主要是基于需求分析阶段的主观判断，而后者受需求状态流转是否及时的影响，在有效性上都需要打个问号。

代码当量可用于校准这两个指标，帮助团队识别故事点预估偏差、工时记录不全不准等问题。在研发流程相对规范，估点可靠性较高的前提下，可以同时使用多个指标交叉验证需求大小，进一步控制需求颗粒度。

估算需求吞吐带宽，为规划提供参考

需求大小不一时，研发团队的“本迭代交付xx个需求”的承诺常常会有变数。这种不确定性导致了业务、产品等团队与研发协作受阻。

校准了需求颗粒大小后，贝壳还分析了每周新增当量与需求交付数的线性拟合情况。如果新增当量和需求交付数相关性高，一方面说明研发到交付的流水线成熟、稳定性较好，研发完成后一般能顺畅上线；另一方面说明质量较好，缺陷返工概率较低。研发团队可通过当前的代码产能，可靠预测短期内的需求吞吐带宽。

这一信息可以为项目规划提供参考，引导产研团队合理安排研发计划，控制需求准入，保障高优先级需求的快速交付。

提效下一步：深入服务一线研发团队

由于贝壳规模庞大，各研发团队的业务属性存在较大差异。为了保障度量平稳落地，贝壳工程效率团队还未将度量用于规范要求，而更多是向一线研发团队客观呈现需求颗粒度的分析结果，并配套提供最佳实践建议，引导团队自发改进。

目前，贝壳工程效率团队正在进一步深入研发团队，帮助一线管理者全面了解研发现状，并根据团队的实际情况自主制订改进措施，提高研发效能健康度。具体实践包括基于工时与代码当量指标，量化团队开发负载，进而评价项目的人力资源投入是否合理；基于需求类型与代码当量，识别周期内团队在不同需求类型上的工作量分布，进而合理调整研发工作重心等。

‍