技术管理系列 研发效能破局之道

研发效能破局之道

研发效能综述

研发效能模型与理解

• 简单来说，就是开发者是否能够长期既快又准地产生用户价值。
• 包括有效性（Effectiveness）、效率（Efficiency）和可持续性（Sustainability）三方面
• 优秀效能例子：Facebook 在 2012 年达到 10 亿月活的时候，部署人员只有 3 个
• 提升研发效能使得开发者能够聚焦产出价值，更容易精进自己的技术，从而形成良性循环
• 对于提升研发效能努力：最初的瀑布研发流程到敏捷到精益，从持续集成到持续发布到持续部署，从实体机到虚拟机到 Docker，从本地机器到数据中心再到云上部署，从单体应用到微服务再到无服务应用
• 初创公司的普遍坑：盲目使用新技术：比如微服务
• 不阻塞开发人员几点小建议：1 本地构建脚本要快；2 好的商用软件要买；
• 研发效能模型：

1 优化流程
2 提升团队工程师实践
3 提升个人工程实践
4 通过管理和文化打造可持续学习型组织

效能度量困难

• 一个事物，你如果无法度量它，就无法管理它；我们先要有量化标准（这也是欧洲制造高品质原因）
• 效能度量的错误案例：1 全公司范围内推行一套效能度量指标(没有考虑不同团队不同特点)；2 中型公司推行质量方面指标（只从QA角度量化）；3 创业公司聚焦度量开发、测试、上线准确度指标（不能牺牲产品试错和快速迭代为代价）；
• 研发效能度量很难，首要原因：研发过程本身是一项创造性很强的知识性工作，非常复杂且伴随有大量不确定因素
• 一个复杂的系统，如果过于关注某几个参数，那么度量过程很可能会沦为数字游戏

• 研发效能度量很难的第二个原因：竖井效应（只考虑局部最优，使得在整个工程中，存在多处等待情况）

• 研发效能度量很难的第三个原因：技术产品输出与最终用户价值之间沟壑很难打通

效能度量指标选择

• 效能指标分类：1 速度；2 准确度；3 质量；4 个人效能；
• 速度：主要是衡量团队研发产品的速率，从任务产生到交付
• 准确度：需求和用户价值是否吻合；比如某个功能用户使用率
• 质量：包含性能、功能、可靠性、安全等方面
• 个人效能：开发环境构建速度、本地构建速度等

四类指标的参考项如下：

• 只需要选取适合自己的就行，千万别面面俱到
• 效能度量的原则：效能度量不要和绩效挂钩，只是作为参考和辅助工具来帮助团队提升效能

效能度量推荐方法

• 目标驱动，度量对的事（用户满意度、系统稳定性、紧急bug修复上线时长等）
• 先从全局找瓶颈，在深入细节（收集工程中每个阶段的时间，发现瓶颈再做优化）
• 通过主观的方式来评价，提高效能（递归思想管理方式）

• 关注个人维度的指标来提升效能（从本地提交到环境测试越快越好）

四种方法的总结如下：

1 度量只是工具，不是目的。切记度量的真正的目标是提高效能，不要舍本逐末。比如说，如果度量花费的时间超过了收益，那就不要去做。
2 虽然我们推崇数字驱动，但在效能的度量上，不要迷信数字，适当使用主观反馈效果反而更好

研发流程

流程优化

无论你们公司采用哪种开发流程（瀑布、迭代、敏捷、增量等），两个目标是要达成一致

• 目标一：寻找用户价值，利用MVP(最小可行性产品的思想，使用用户价值来衡量阶段成果)
• 目标二：提高用户价值的流动效率（小迭代，复盘，消除竖井，提倡全栈）

代码入库前

• 规范化、自动化核心步骤，主要分为三大步：开发环境获取，本地开发，入库前系统检查

1 开发环境获取：有条件的话，可以像大厂一样自己实现一套虚拟机自动申请释放管理系统统一管理开发机器；没有条件的话可以做个基础镜像，能够快速搭建开发环境进行开发
2 本地开发：有条件的话，自动化测试，代码检查等可以使用共享服务的方式提供，没有条件的话至少要利用一些IDE的工具插件做一些代码检查和使用热启动来提升效率
3 入库前系统检查：流程做到自动化，人工进行审查反馈，有条件的话可以构建沙盒环境，使用脱敏过的生产数据进行验证

可持续集成和持续交付 CI/CD

• 三条基本原则：1 测试尽量完整自动化；2 耗时少；3 环境架构尽量与生产保持一致
• 不要教条，根据自己内部特点优化和调整

以下是几个持续性工作的关键点：

分支管理

• Facebook的代码分支管理和部署流程（主干分支策略）

除了主干分支策略外，还有其它一些管理策略：Git-flow，Fork-merge工作流等

• PS：之前团队采用的是git-flow流，后来根据多数开发者习惯都切换到了Fork-merge流

全栈思维

• DevOps：打通开发和运维的文化和惯例
• SRE：是 DevOps 的具体实践之一，软件工程师和系统管理员的结合
• 全栈思维要解决的问题：使得多岗位的目标达成一致（前端，后端，运维，测试）
• 利益的统一，开发人员职责要修改为快速开发和上线稳定的高质量产品
• 优化开发到部署的整个上线流程，落地时首先要从人出发，然后是流程，最后才是工具
• 具体落地措施：1 对团队目标达成共识，并重新定义职责；2 设计 CI、CD、快速反馈，以及团队沟通独立群等流程；3 引入工具，实现自动化

落地过程中的任务和推荐工具：

全栈开发就是让工程师不再只是对某一个单一职能负责，而是对最终产品负责。全栈开发是一个很好的抓手，逐步提高全栈开发的程度，大家的目标自然就会对齐，从而主动去提高，那其他方面的提高就容易得多了

懂得开发的运维人员，会越来越重要；同时，更关注部署、测试，甚至产品的全栈工程师，也会越来越受欢迎。

高效信息流通

• 实现高效沟通首先要解决的，就是团队成员的意愿问题，让他们愿意沟通
• 在团队内部建设机制，来鼓励共享的行为，从而形成共享的文化
• 针对研发流程中流动的各种信息，我们要做好分类，针对性地设计合适的流程，并选用恰当的工具，最大程度地共享给团队成员

工程方法

研发环境

• 配置出高效的研发环境
• 必要的测试环境和类生产环境
• 流程尽可能自动化与高效

代码审查

• 作用：1 尽早发现问题；2 提高个人工程能力；3 知识共享；4 针对性提高；5 统一编码风格
• 审查方式：1 面对面审查；2 线下异步审查
• 代码审查的成功案例：1 由5个开发者组成的初创团队采用了1v1面对面代码审查；2 由30个人团队，使用Gerrit、Jenkins、SonarQube来管理代码质量和审查代码，以工具为辅助的进行线下1V1的代码审查，偶尔进行多对一审查；3 由百人以上的团队，GitLab来管理代码，Phabricatgor作为审查代码

各种审查方式的优缺点：

网上参考文章推荐：(Gerrit、Jenkins、Gitlab、SonarQube联动)
https://www.jianshu.com/p/160b260d8956
https://www.jianshu.com/p/e111eb15da90

• 代码审查应该计入工作量，并且纳入绩效
• 机器审查和人工审查相结合

• 推进代码审查的关键操作：1 提高提交的原子性；2 提高提交说明的质量(标题，描述，测试情况，其它关联信息)
• 可以使用git的提交模板功能来对提交说明格式进行限制
• 成功推行代码审查两个关键原则：1 互相尊重，为对方考虑；2 基于讨论，而不是评判

质量与速度的均衡

• 虽然天下武功为快不破，但是好的产品讲究的还是持久发展，不然开发的代码只有几个月的生命周期，开发者对工作的热情也会消散
• 控制技术债，在适当的时候进行偿还
• 养成良好的设计、编码、开发习惯，减少技术债生成

A 公司：只关注业务，不偿还技术债
B 公司：持续关注技术债，但对业务时机不敏感
C 公司：持续关注业务和技术债。对业务机会很敏感，敢放手一搏大量借贷，也知道什么时候必须偿还技术债

A 公司在开始的时候，业务产出会比较多，但由于技术债带来的影响，效率会逐渐降低
B 公司在开始的时候，业务产出比较少，但由于对技术债的控制，所以能够保持一个比较稳定的产出，在某一时间点超过 A 公司
C 公司在有市场机会的时候，大胆应用技术债，同时抽出一小部分时间精力做一些技术债预防工作。这样一来，在一开始的时候，C 的业务产出介于 A 和 B 之间，但和 A 的差距不大
随后，在抢占到一定的市场份额之后，C 公司开始投入精力去处理技术债，于是逐步超过 A。另外，虽然 C 公司此时的生产效率低于 B 公司，但因为市场份额的优势，所以总业绩仍然超过 B。在高优先级技术债任务处理好之后，C 公司的生产效率也得到了提升，将 B 公司也甩在了身后

测试变革

• 传统的开发模式，测试只能被动（需求质量或开发质量差时，只能被动接收），但大锅却一般在测试头上，对于测试很不公平
• 测试左移：让测试介入代码提测之前的部分，参与需求质量与合理性讨论，在架构设计时就考虑产品的可测试性，并尽量进行开发自测等
• 测试右移：让测试介入代码提测之后的部分，利用线上的真实环境测试，通过线上监控和预警，及时发现问题并跟进解决，将影响范围降到最低
• 测试左移的原则：调整测试人员的观念和态度；测试参与需求讨论和用户故事编写；频繁测试快速测试；

五颜六色的发布

• 蓝绿部署：采用两个分开的集群对软件版本进行升级的一种方式（交替）
• 红黑部署：与蓝绿部署类似，但是不同点是升级前的机器资源会被释放掉
• 灰度发布：也被叫作金丝雀发布，属于增量发布，服务升级的过程中，新旧版本会同时为用户提供服务

研发流程未来趋势

• 团队远程办公、灵活工时办公，会越来越普遍
• 聊天工具和其他工具的集成，会越来越普遍
• Docker 和 Kubernetes 带来的各种可能性

备注：CaaS（Containers as a Service），是允许用户通过基于容器的虚拟化来管理和部署容器、应用程序、集群，属于 IaaS 平台的范畴
Kubernetes 出现后，提供了强大的容器管理和编排功能，事实上是实现了一种基于容器的基础设施的抽象，也就是实现了 IaaS 的一个子类。所以通过它，我们终于可以方便地建设定制化的 PaaS 了，一个具体的例子是 FaaS（Function as a Service）。Kubernetes 的出现，极大地降低了建设 FaaS 的工作量，所以很快出现了基于它的实现。比如OpenFaaS、Fission。

正是基于 Kubernetes 提供的构建 PaaS 的能力，预期将来越来越的产品会构建在基于 Kubernetes 和 Docker 的 PaaS 之上。可能会出现整个公司运行一套 Kubernetes 作为 IaaS，上面运行多个不同的 PaaS 平台，支持各种服务的运行。

• 分布式计算会越来越流行，从微服务演化到服务网格
• AI技术应用会越来越普遍，门槛也将越来越低

个人效能

个人高效工作三原则

• 抽象和分而治之，将复杂的任务或问题拆分处理
• 快速迭代，不要过于追求完美
• DRY，不要重复自己，对任何重复事情进行自动化

三个原则的实践举例：

聚焦与深度工作

• 工作中常遇到问题：1 工作从早忙到晚，但一直被业务拖着跑，绩效一般，个人也得不到成长；2 碎片时间很努力地学习相关技术，似乎学了不少，但不成系统，学完也就完了，没什么效果；3 作太忙，没有时间锻炼、放松，效率越来越低，可能自己还察觉不到；4 工作总是被打断，无法静下心来工作和学习
• 实现聚焦于深度工作的三个步骤：1 以终为始，寻找并聚焦最重要的任务；2 追根究底，寻找最高效的解决方案；3 安排时间和精力，高效执行解决方案
• 以终为始：自己定义任务，聚焦目标，无情的筛选；将个人成长，团队提升，业务增长三个统一起来；例如：利用自己的技能帮助团队工作提升，带来业务增长；最保留最重要的3个任务
• 寻找高效解决方案：对任务和问题多问几个为什么，找到根本原因和目标
• 高效执行：安排整块的时间，排除手机等其它因素干扰，制订自己番茄钟，强制锻炼

效率工具

• 熟悉操作系统的各种快捷键和常用技巧
• 使用云笔记来安排与记录工作
• 使用云盘来管理自己的资料和工具
• 用一款好的鼠标与键盘(可以多买几套放置在不同地方)

• 对浏览器网页标签收藏与管理（推荐google的papaly）

• 尽量使用正版软件，一般正版软件能提供更多更好功能和可靠性，减少自己在这块的精力投入
• 使用高效的工作工具，包含：IDE编辑器(VS CODE,vim,JetBrains系列产品)，命令行工具(git shell,cmder)，文件夹标签管理(clover)，测试工具(postman)，SSH工具(termius),VPN工具，linux下的快捷工具(目录查看tree，exa；zsh，tmux，mosh)
• 推荐一个工具集参考：https://www.cnblogs.com/hi-linux/p/11580086.html
  一些工作场景和常用的工具列表：

GIT提高原子性提交技巧

• 1 把工作区里的代码改动的一部分转变为提交（主要是为了按功能点提交，让每次的提交都完成一个小功能点）关键命令：git add -p xxx文件
  参考链接：https://johnkary.net/blog/git-add-p-the-most-powerful-git-feature-youre-not-using-yet/
• 2 对当前提交进行拆分，解决一不小心已经把不同功能点改造代码一并提交了，关键命令：git reset HEAD^，注意创建一个备份分支
• 3 修改当前的提交，可以是提交的备注或提交的文件，关键命令：git commit --amend git add git rm
• 4 交换多个提交的先后顺序，解决只想把后面的提交推送到远程，关键命令：git rebase -i origin/master, 注意创建一个备份分支

提交了A和B两次

执行rebase后的示意图，可以选择基准后A和B的顺序，甚至舍弃某次提交

git rebase -i 的功能非常强大，除了交换提交的顺序外，还可以删除提交、和并多个提交
参考链接：https://git-scm.com/book/zh/v2/Git-%E5%B7%A5%E5%85%B7-%E9%87%8D%E5%86%99%E5%8E%86%E5%8F%B2

• 5 修改非头部提交，为了方便实现原子性，我们常常需要修改历史提交，也就是修改非头部提交，关键命令：git rebase -i origin/master
  我要对A比较进行修改

修改后提交

Git 学习曲线比较陡而且长，帮助手册也可以说是晦涩难懂，但一旦弄懂，它能让你超级灵活地对本地代码仓进行处理，帮助你发现代码仓管理系统的新天地。git rebase -i 命令，就是一个非常典型的例子。一开始，你会觉得它有些难以理解，但搞懂之后就超级有用，可以帮助你高效地解决非常多的问题。所以，在我看来，在 Git 上投入一些时间绝对值得！

管理与文化

业务和技术两手抓

提高团队的研发效能，还要通过管理和文化让之前的原则和方法真正在团队落地。管理是提高团队研发效能的基石，而文化是持久高效的保障。同时，管理又决定了文化，如下图：

• 技术管理的三个步骤：1 寻找目标；2 目标管理；3 计划并执行
• 寻找目标：技术团队的根本目标就是业务目标，但为了支撑业务增长还需要有技术目标（重构、归还技术债，新技术推行）
• 目标管理：用SMART 原则执行目标，用OKR对目标进行管理（OKR不是绩效管理方法，只是目标管理工具）
• 任务执行：关键还是人，调用人的主观意愿；采用康威定律来组织团队结构

工程师文化

• 定义自己需要的文化，别人家的不一定是适合你的
• 一个团队能否高效产出，文化起到关键作用
• 文化更像是潜规则，写到横幅上的标语并不一定是公司文化
• 文化的建设，更是技术活和力气活的合体，绝不是喊几句口号就可以完成的
• 工程师文化是创造力引擎
• 工程师文化的特点：黑客之道，优化无止境，持续进步，代码为王，能力为王，打破常规，突破界限
• 需要特别注意，公司自身发展要好，不然很难发展公司文化
• 工程师文化实践三大支柱：1 做感兴趣的事；2 拥有信息和权限；3 绩效调节
• 绩效调节方式：1 面对面沟通反馈；2 360度绩效考评（自己选评价同事，主管指派，自评，主管，所有直接下级）
• 绩效评定原则：对公司的贡献而不是团队，保持客观与公正（事例或数据支撑，多人评价）

总结

超越昨天的自己，享受成长的快乐
国内的软件行业，值得优化的地方比比皆是。国内软件研发人员的能力和创造性，绝不亚于硅谷那些高效能公司。只要我们的方向对了，并不断提高，就一定可以大幅提高团队和个人的研发效能，从而把时间花在最值得的地方

PS：本文主要是对葛俊老师在极客时间专栏《研发效能破局之道》学习过程的整理，以及自己的一些感悟和体会与实践。推荐感兴趣的同学去订阅专栏进行更加系统和全面的学习