研发效能是什么？为什么现在都在谈如何提高研发效能？研发效能对于一个企业到底有多重要？本文按照Why、What、How三步走沉淀梳理了研发效能相关的知识点。
一. 为什么要提升研发效能
- 传统的职能部门组织架构带来的效率竖井问题
- 人力的增加没有让项目进度加快
- 长久加班导致团队士气低落，后续的效率降低
- 上线前加班、熬夜，压力大
- 上线后Bug、事故频发，实现效果与需求不匹配
- 各种重复低效工作，疲于应付业务
- 想要有限的人力做更多的产出
二. 什么是研发效能
对于一个企业来说，追求的是企业效能的最大化，包括：利润、用户规模、客户满意度、运营效率等。而对于需要研发自有产品的互联网公司来说，研发效能则是服务于企业效能的至关重要的因素。
一个软件研发的完整流程如下图所示：
此流程交付期望产品的效率和能力，即研发效能。更进一步的《研发效率破局之道》中将研发效能定义为团队能够持续地为用户产生有效价值的效率，包括 有效性（Effectiveness）、效率（Efficiency）和可持续性（Sustainability） 三个方面。其增加的可持续性指出研发效能应该着眼于长期效果。
一句话来讲，研发效能就是持续快速交付价值的能力。
三. 如何提升研发效能
对应于第一部分中讲述的软件开发流程，如果想要提升研发效能，那么需要落实到研发流程（组织结构、项目管理、持续交付）、工程方法、个人效能以管理和文化的实践上。本文重点从研发流程、工程方法两方面来讲。
3.1 衡量指标
评估一个组织持续快速交付价值的能力，需要一组可量化的数据或参数，用来跟踪和评估开发过程的“健康”状况。
3.1.1 指标分类
- 持续发布能力
- 发布频率：单位时间内的有效发布次数
- 发布前置时间：从代码提交到功能上线花费的时间
- 需求响应周期
- 交付周期时间：从确认用户提出的需求开始，到需求上线经历的平均时长。
- 开发周期时间：从开发团队理解需求开始，到需求可以上线所经历的平均时长。
- 交付吞吐率
- 单位时间交付用户需求数量：单个团队的对比
- 交付过程质量：质量内建
- 缺陷创建和修复时间分布：缺陷能够持续和及时地被发现，并在发现后尽快修复。
- 缺陷库存：开发过程控制缺陷库存量，让产品始终处于接近可发布状态，是持续交付的基础
- 交付质量：系统的可用性
- 单位时间问题数目
- 线上问题解决时长
3.1.2 通用目标
- 2：2周交付周期。从想法提出并确认到上线的时间。【跨职能、组织的协调一致和紧密协作】
- 1：1周开发周期。从需求设计完成（对开发就绪）到达到可上线的时间。【需求的拆分和管理，开发团队的分工协作模式，持续交付实践】
- 1：1小时的发布前置时间。代码提交后可以在1小时内完成发布。【持续交付流水线】
3.1.3 选择优化指标
流程中总是有一个核心瓶颈。分析关键路径、定位瓶颈，针对优化
- 使用指标来发现问题而不是做绩效考核
- 使用指标来检验优化效果
- 使用价值流图/累积流程图发现全局瓶颈，从而确定需要提升的度量指标
3.2 组织结构&&项目管理
3.2.1 组织结构
避免“效率竖井”： 采用以业务为单位的组织架构，保证业务线全栈配齐，目标一致。并从全局定位瓶颈进而进行优化工作。
3.2.2 项目管理
使用敏捷开发来提升研发效率
- 敏捷 = 价值观 + 原则 + 一系列符合价值观和原则的方法。
- 软件应该一直处于可工作状态
- 每个迭代都能将软件部署到一个类生产环境中，并向用户演示
- 迭代长度不超过两周
- 透明性、协作性、纪律性和持续改进
- 使用MVP，度量驱动开发
- 流程尽快流动：工程方法支撑
- 发现整个流程中的瓶颈，并解决：可视化工作流、事故复盘
- 避免“小瀑布”
- 价值排序
- 满足客户需要
- 需求拆分成能够独立测试的需求！！！
- 看板
- 从个人转变到关注价值流动：待开发->设计->开发->开发自测->代码评审->测试->完成
- 明确的“完成的定义”DoD，明确了状态迁移必须完成的活动
- 从实际出发、以终为始：以实用主义的态度，从原则出发，灵活优化流程
一个可供参考的项目管理标准动作可见：项目管理标准模板
3.3 持续交付
持续交付指的是在短周期内完成软件产品，以保证软件保持在随时可以发布的状态。让每一个变更都经过一条自动化的检验流水线，来检查每一个变更的质量，通过就进入下一个阶段。其不是一种工具，而是一种实践！
- 不要阻塞开发人员
- 每个团队指定构建负责人或者发布工程师：优化交付流水线，提升交付效率
- 项目状态，应该对参与整个过程（包括构建、部署、测试和发布）的所有人都是可见的
- 风险管理
- 迭代增量式交付是有效风险管理的关键
- 手工测试环境、试运行环境和生产环境总是需要严格的访问控制
- 让风险识别成为每日立会的一部分
- 审计
- 手工测试环境、试运行环境和生产环境总是需要严格的访问控制：指定谁能够访问“特权”环境。
- 要求每次部署都要进行审计，以确切知道到底修改了哪些内容。
- 文档自动化、自文档
具体可见：持续交付这点事
3.3 工程方法
3.3.1 技术债
在开发产品或者功能的过程中，没有使用最佳的实现方法而引入的技术问题。需要持续关注业务和技术债。对业务机会敏感，敢放手一搏大量借贷，也知道什么时候必须偿还技术债。
- 利用技术债的好处，必要时要大胆“举债前行”
- 控制技术债，在适当的时候偿还适当部分的技术债。
3.4.2 云计算
利用好云计算带来的服务化、自助化和弹性伸缩三大优势。初创公司在业务刚起步时，使用 SaaS 或者 PaaS 快速开发业务；业务成长到一定规模之后，再逐步转到 IaaS 以及私有云降低成本。
- 细节抽象得越多，云服务商负责的部分就越多，我们就越能够聚焦自己的业务，从而提高研发效能
- 使用云资源时，通过工具或者 API 调用来完成工作，减少人工参与，达到自动化
- 资源共享、弹性伸缩
- 容器：不可变基础设施；基于K8S建设PaaS
在使用云计算时，要妥善处理它带来的挑战，比如分布式系统带来的安全和控制方面的问题。
- 自治和集中管理相结合：信息可视化（系统整体的质量看板、调用链追踪）
- 错误处理
3.4.3 测试机制
上文持续交付一部分中最关键的其实就是测试部分，只有具有完善、可靠的测试机制，才能保证研发质量和交付效果，才能从根本上提高研发效能。
- 测试左移：质量内建，即持续交付中的测试机制。
- 按照功能的维度管理团队，让整个功能团队对产品负责；改变团队成员对测试工作的认知
- 把测试添加到开发和产品需求步骤中
- 频繁测试，快速测试：提升测试运行的速度，并行运行、提高构建速度、精准测试、分层测试、减少不必要的用例
- 测试右移
- 利用线上的真实环境测试：需要有完备的数据隔离机制
- 测试人员介入线上监控和预警，及时发现问题并跟进解决
- 混沌工程：即在真实环境中通过模拟各种不可预期的故障来验证系统稳定性
3.4.4 平台化
通过抽象共性组件、功能，达到代码、功能复用，从而减少重复开发，提高研发效能。
- 技术平台：技术设施的复用
- 数据中台：数据沉淀和输出能力
- 移动中台：前端组件、跨平台开发、插件化、热加载
- 业务中台
- 业务能力的复用
- 赋能业务
相关资料可见：中台简谈
3.5 个人效能
如何提高开发人员自身的开发效率，除了每个人自身的天赋能力外，也有一些可以刻意使用的高效工具和方法。
- 高效工作方法
- 抽象和分而治之
- 快速迭代
- DRY
- 番茄工作法
- 高效开发工具
- 好的IDE
- 操作系统快捷键
- 思维导图软件
- 学习笔记软件
- 文档撰写工具
- 持续学习：不断地学习新的开发技能，从而提升自己的开发效率
此外，还可以通过技术管理从外部驱动个人效能的提升，这在下面的技术管理部分会讲。
3.6 管理和文化
3.6.1 技术管理
管理包括：看方向、管人、管事。做好技术管理是提高研发效能的关键部分。其中，3.4节个人效能部分的数字驱动也是技术管理的一部分。主要步骤包括：
- 制定目标：兼顾业务目标和技术目标
- 目标管理：使用OKR等目标管理方案
- 计划并执行去实现目标
此外，技术管理中一个很难的问题是如何进行考核。这里可以使用数字化的方式，以驱动个人效能的提升。
- 选择个人效能度量指标
- 根据代码提交日志自动生成工作日报和周报、个人贡献值
- 综合多维数据构建个人的数据画像
- 社会地位：用排名、榜单来实现；
- 工作本身：用复合型报告去综合评价，告知员工究竟做得好不好
- 自我改变：通过雷达图，进行多维度的数据分析，精准提炼员工的优点与不足，员工可以有针对性的取长补短。
需要说明的是，如果指标不能全方面的衡量，就不要做为考核指标，仅仅用于发现问题，解决问题！
一个可参考的技术管理标准动作模板见：技术管理标准模板
3.6.2 团队文化
团队文化是团队成员共同认可的价值观和行为准则，良好且有效的文化是保障团队高效产出的关键部分。很多互联网公司都是工程师文化主导的，包括Facebook、Google、百度等。他们也都具有自己独特的企业文化价值观，如百度的简单可依赖、谷歌的不作恶、Netflix的自由和责任。建立团队文化的步骤如下：
- 定义：总结、明确自己团队的文化，提炼出简单易记的文字。
- 主张：各种形式的传播。从我自己的经历来看，不断地念经是其中最有效的方式。
- 追求：在奖惩中体现出文化价值观的作用。如对于文化价值观贯彻优秀的同学给与公开的肯定与奖励。