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方法的最佳实践：
?
