一、效能定义
定义1：“研发效能”就是更高效、更高质量、更可靠、可持续地交付更优的业务价值的能力
定义2：研发效能（结果指标）= 平均需求价值 * 需求吞吐率 * 需求交付质量 / 团队成本，参考 研发团队的效能度量
参考文章
二、迭代问题分析
节奏问题：2周迭代，开发时间只有3天左右，联调时间1-4天不等，部分迭代测试时间长至1周
需求问题：需求较散，涉及多个产品需求，导致会invovle较多开发，每一个开发在迭代时间有限，且开发介入的时间不一，间接导致需要多次提测
准入准出问题：迭代分 需求 → 反讲 → 接口定义 → 联调 → 测试 → 上线等阶段，经常一个环节的准入和准备不高，导致问题落入到下一个环节
迭代小组凝聚力：Owner并没有把责任很好的承担起来，规范跑着就跑没了，产品经理和迭代经理跑着就跑没了
人力问题：由于可能的某个迭代组工作不饱和或者迭代划分不清晰，导致一个伙伴同时会分配到多个迭代，工作节奏不停切换，伙伴成就感和效率都不高
资源配置：部分迭代人力配比不合理，前端和QA都有可能是瓶颈之一，但并没有得到有效解决
依赖问题：各个业务域依然存在依赖，协同成本较多
RD能力：rd能力方差比较大
三、架构&工程效能问题分析
1、产品/业务架构 ：产品B点定义(缺少了画面感) + 业务架构A点 → B点路径不清晰，缺少顶层设计，导致 微服务定义粒度和边界划分不清楚，团队依赖严重，团队难以自闭环，敏捷组织打造困难重重；人力资源的配比没法做提前规划～
2、工程提效问题高途Arch项目
项目框架：用面向过程的开发写ddd → 极大的增加了项目的复杂度和人员素质的要求，增加了成倍的代码量
starger工具包：公用包的较少，缺少管理，导致不同项目之前代码重复率很高
RD的能力方差较大，经常一个接口需要1天+的时间，如果有经验的伙伴可能很快完成
3、业务价值评估和业务自迭代的体系
面向业务和运营好用的ABTest平台
