1、提升研发效率的实践过程中存在哪些痛点？
2. 提高研发效率的系统方法论：MARI方法论
看点一：研发效率提升过程中存在哪些痛点？
研发团队面临的绩效挑战体现在多个方面：
1、技术团队研发效率低，加班多，交付速度慢且质量差，业务方满意度低；
2、协作效率低，等待返工造成浪费，工程师满意度低；
3、研发人力资源配置困难，项目不断延期、超预算，管理满意度低。
因此，提升研发效率成为越来越多团队关注的焦点，但目前还缺乏明确的实施路径。 基于CMEA与客户持续沟通的实践，我们发现研发效率的实践面临以下痛点：
针对提升研发效率实践中面临的这些问题，提出了MARI方法论。
第二点：研发效率提升方法论：MARI方法论
MARI 是一套软件开发、性能测量应用和实际实施的方法论。 其目的是建立绩效衡量和改进的闭环。
研发团队结合实际情况，定位价值流中的关键障碍作为改进点后，可以应用MARI方法论对问题进行定量评估、分析和拆解，获得性能瓶颈、改进机会等洞察，然后实施他们融入到软件工程实践的逐步优化和效率的实际提高。 接下来我们将结合案例介绍MARI方法的应用。
措施
研发效率的本质是更快、更好、更低成本地交付更好的商业价值——这短短一句话包含了交付的效率、质量、成本、能力和商业价值等多个维度。
研发成效是如此多维度，全面衡量它的成本非常高，而且大厂商使用的指标可能并不适用于团队自身的情况。 因此，在开始改进活动之前，团队需要牢记“以终为始”，根据团队的实际痛点确认改进目标，然后根据目标选择衡量指标。
比如，A研发团队最近最头疼的就是频繁的项目延期和业务方的投诉。 但纵观研发的各个环节，产品、开发、测试、运维团队却互相指责，都说人手不够。 问题是什么？ 在这种情况下，需求交付周期这个反映价值流转效率、可以深入到各个环节的指标，就是一个合适的北极星指标。
分析
在有关研发有效性的讨论中，我们经常看到丰田生产方式著名创始人大野耐一的一句话：不懂数据的人都是坏人，最坏的人是只看数据的人。 人们。 仅仅停留在数据上进行衡量是一件非常危险的事情。 重要的是从数据中洞察问题并指导改进。
图中我们列出了三种分析方法：
如果已采取措施，可用于验证改进措施的有效性； 需要注意的是，观察趋势时也可以不选择平均值。 第80个百分位值或许能够更好地排除异常值并反映总体情况。
在深入研发流程时，建议避免使用容易受噪声影响的指标，例如提交数、代码行数等。 司马邑设计的基于深度代码分析的“代码等效性”可以解决这个问题。 该指标也已被信通院开源生态监测平台采用。
A团队通过分析发现，在深入挖掘近期需求交付周期时，只有研发环节的交付时间明显高于历史水平。 关联研发团队近期代码当量趋势，发现研发团队人均编码生产力呈现明显下降趋势。
审查与改进
综合以上分析，A团队研发流程的效率降低很可能是导致需求交付缓慢的瓶颈。 那么设定KPI并要求所有开发人员提高效率还不够吗？
事情没那么简单。 找到关键瓶颈并不等于找到根本原因。 没有进行根本原因调查和分析，任务就直接分配到一线。 开发者缺乏明确的改进方向指引，只能盲目延长工作时间、增加工作量。 即使投入资源，也很难共同提升，进而损害团队的工作体验。 懒惰的管理者对此负有主要责任。
以A团队的问题为例，研发过程中效率的下降可能是由系统、流程、工具、人员等多种因素造成的，也可能受到上游需求环节的影响。 从众多的影响因素中不断排除并找到根本原因，是一项非常复杂的工作。 一方面，我们可以借助相关指标和数据继续分析； 另一方面，组织专题调研，倾听一线动态和声音。 这部分工作是纯数据分析无法替代的。
A团队的一项调查发现，近期研发团队中代码贡献出现了明显的不均，团队中25%的开发人员贡献了83%的工作量。 由于任务拆分和调度不合理，大量工作堆积在少数开发人员身上，导致这些开发人员超负荷工作，而其他大多数开发人员则处于等待状态，整体效率下降。
针对这一问题，A团队一方面调配资源补充人力缺口，降低人均流量负载，减少开发者不断切换任务造成的浪费； 另一方面效率与效能的区别与联系，它调整任务分配以减少任务之间的耦合。 这避免了对关键人力的依赖和不均匀的繁忙日程。
持续改进的闭环
性能改进无法通过定期冲刺来实现。 为了实现有效和可持续的绩效改进，需要将测量和改进实践融入到日常研发流程中，并持续跟踪和持续改进。
MARI方法强调构建研发绩效管理闭环。 基于数据解读制定改进计划后，需要持续测量和观察绩效趋势，进一步分析和解释改进后的指标数据，快速反馈改进计划的有效性。 如果持续改进一段时间，持续改进效果不明显，边际效应降低。 这种机制也将帮助团队做出快速判断，及时将资源投入到下一步的改进项目中。
实施改进后，A团队继续衡量北极星指标，观察到需求交付周期比三个月前没有改善的情况缩短了29%效率与效能的区别与联系，需求吞吐量也有所增加。 可见，此前的改进计划是有效的，研发资源和任务也进行了调整。 分配和性能改进之间确实存在相关性。
为了避免出现“以指标为导向的改进”情况，A 团队将其他指标关联起来作为检查和平衡。 例如，衡量人均生产力，验证更快的需求交付确实与研发团队产出效率的提升有关，而不是因为需求被拆分成更精细的细节； 测量测试缺陷率和在线缺陷率，以验证更快的需求交付与不以质量为代价。 可以根据以往改进的影响范围来选择制衡指标。
以上就是本次回答的全部内容。 A团队最终拨开迷雾，找到了阻碍快速交付的关键瓶颈，并进行了针对性的优化。 最后用一张图总结一下MARI方法的最佳实践：
