本文共计字，建议阅读时间：4~5分钟。
阅读本文你将收获：
1、软件研发管理者在管什么？
2、软件研发外包团队管理实践案例
3、研发人力资源调配管理实践案例
4、研发效能度量实际应用：MARI方法论
前言：本篇文章是在QECon大会上，思码逸咨询总监Amy的演讲部分内容整理，干货满满。以下是文字版干货回顾，直接开整！
01背景：软件研发管理者在管什么？
尽管『管理』这一话题相当复杂，但也可以被大致归类为管事、管钱、管人三项。对于研发管理者来说，这三项可以进一步解读为：
事：项目过程与成果的可见性高，可快速洞察瓶颈和潜在问题，并准确定位根因
钱：盘点资源利用率，量化投入产出比，量化评估人力需求，合理调配研发团队资源
人：引入客观量化的贡献度量机制，多维评价开发者，及时发现优秀实践
这篇内容将结合实际案例，分享金融行业软件研发管理的两个典型场景，以及效能度量如何在这些场景落地，提高管理可见度，为精细化管理提供数据抓手。
02软件研发外包团队管理
统计数据显示，中国金融行业信息技术外包（ITO）市场规模在年已超过亿元人民币，其中软件研发及相关服务占比近半。
软件研发外包，是金融业数字化转型的重要路径之一，也是研发管理的常见场景。在这个案例中，企业技术人员规模达人，构成比例约为内勤:外包=1:1.8。其研发效能度量需求主要包括：
评价外包研发团队效能水平
了解外包研发人员贡献度与岗级是否匹配
了解外包研发人员质量表现，识别改进短板
针对效率方面的度量需求，团队可以在日常开发活动中，持续度量研发人员生产率水平（例如以人均代码当量反映生产率），并根据内勤/外包标签聚合，进行对比分析。
同时，可以加入基线为生产率度量提供参考。本公司历史生产率均值和行业生产率中位数，都可以作为基线值。但这里需要留意：参考项目需要与当前项目的开发语言、项目性质、项目阶段等特征相匹配，基线才更具备价值。
除了对比内勤与外包团队的生产率均值以外，也可以对比群组内的生产率差距。在本案例中，外包研发团队的人均生产率低于内勤团队，但生产率差距较小。进一步分析生产率在不同职级的分布，显示高岗级与高生产率存在强相关，但其中T4岗级的生产率呈现出两极分化现象。
这一信号可以指引研发管理者继续下钻分析：同一岗级生产率呈现两级分布，可能是由语言、职能、项目阶段等差异导致，需要对度量做优化校准；也可能是由于资源分配不合理，忙闲不均等导致，需要团队实践的优化。
除了效率，质量方面的洞察同样重要。研发团队可以将成员的效率与质量（例如重点问题率）对比分析，来查看质效之间有无相关性。
在本案例中，数据分析显示生产率偏低的成员重点问题率偏高，可能反映出偏低的代码质量导致部分成员投入大量时间修改补救，阻碍了研发效率的提升。
研发效率最佳实践
横向对比分析效能时，需要考虑团队间的业务差异，必要时进行分组分析
度量分析仅提供了数据层面的洞察，仍需通过人工分析进行回顾，探究根因
慎用指标，注意度量指标的反向牵引作用（古德哈特法则）
03研发人力资源调配
金融业务涵盖银行、保险、证券（基金）、信托、担保以及期货等诸多领域，根据业务线来构建组织架构相当常见。
在这个案例中，企业的下属业务部门超过30个，难以实现部门间的合理资源调配调与流动，集团层面也无法判断部门人力需求是否合理。其研发效能度量需求主要包括：
了解各部门生产率水平是否处于合理区间
了解各部门产能的同比变化
评估各部门人力资源利用的饱和度
识别哪些部门确实存在人力需求
首先，团队可以根据部门生产率情况进行筛选。首先在企业内部横向对比，识别生产率偏高或偏低的部门，借助行业基线判别生产力是否落在合理区间，是否落在忙闲不均等情况。针对异常部门，再做进一步的下钻分析。
下面以一个提出人力需求的部门为例：
由于该部门业务具备一定周期性，可以将部门总生产率与去年同期对比，可以看出总生产率显著高于去年同期，且呈继续上升趋势。其次，该部门人均生产率连续5个月接近上控制线，显著高于行业中位数，反映出近期该部门负荷确实偏高。
接下来，可以对该部门进行工作量的帕累托分析：数据显示，该团队80%开发当量由47%成员贡献。一般情况下，这一数值高于40%，可以认为团队的工作量分布较为均衡健康。综合来看，可以考虑给该部门补充人力，避免研发团队超负荷运转，成员工作满意度下降。
更进一步，可以对该部门研发成员进行流负载的细粒度分析，判断高负荷人员是否存在聚类，结合团队反馈，有针对性地补足人力缺口。
研发团队提出资源不足、加班过度、希望加人是常态，但加人未必就能解决问题。“忙”的根本原因，可能是业务周期性变化、需求排期不合理等原因造成的忙闲不均，也可能是任务分配不合理或过度耦合，导致项目对少数几位成员依赖度过高。
而度量的作用，正是帮助研发管理者抽丝剥茧，辨别出真正需要资源投入的部分，帮助团队把钱花在刀刃上。
人力资源调配最佳实践
组织内基线对标的参考价值，大于行业指标
相比单点值，变化的趋势更有意义
判断数据是否合理，而非定义好坏
04研发效能度量实际应用：MARI方法论
度量了，然后呢
研发效能度量不能止步于数据本身。研发管理者紧盯数据，可能导致自上而下的面子工程或教条主义，效果适得其反。
那么度量后，怎样把数据转化为真正的洞见和提升呢？可以参考MARI方法论，这是一套面向软件研发，应用于研发效能度量及提升的效能提升方法。
MARI方法强调对效能指标数据进行下钻分析：
首先对数据进行多视角的分析与解读，获取有效信号
进而结合其他关联指标和调查方法，追问根因，定位效能瓶颈和优化机会
最终将这些洞见落地为明确、可执行、可验证的改进方案，规范研发过程、建立良好研发文化。
层层推进，使度量带动思考和行动，才能发挥出真正的价值。
篇幅所限，这篇文章就不展开阐述MARI的细节，感兴趣的读者可以阅读MARI指南。这份资料也正在持续补充和迭代中。后续我们也将结合案例，分享完整的MARI方法如何落地于研发效能的细分场景。
如果您想了解更多关于本次演讲的内容，可以联系思码逸团队获取演讲视频和演讲PPT；
——————————————————————————————————
思码逸Merico研发效能分析平台，致力于帮助研发团队解决研发效率、研发质量和人才发展三大痛点，提升研发效率与软件工程质量；
如果您想要与思码逸团队交流，欢迎在网站留下联系方式，我们将在24小时内回复。