1. 找到正确的目标

技术最终都是通过业务产生价值，就算是技术类的产品，最终产生价值也是业务，只是这个业务是一个强技术属性的业务。

一个高效能的研发团队管理者，其首要任务是为团队找到正确的方向和目标。这里正确的目标可以分为业务目标和技术目标。

业务目标的设定可以分为两步：

1. 和业务方、上级沟通，弄清楚他们的目标是什么，以及明确他们对于研发团队的预期是什么；
2. 在业务方目标和上级预期目标的基础上，分解目标，内化为带有一定进取的团队目标。

技术目标的设定可以分为两类：

1. 解决过去留下来的问题，历史的问题我们通常称之为技术债，技术债分为主动债务和被动任务，主动债务大多数是在业务发展过程中为了追求速度而做的一种技术妥协，而被动债务大多数是团队能力或水平不足、业务的演化或技术的发展导致的代码或架构劣化任务，或者不再适用于当下的环境。技术债不一定是一个坏事，一个产品进化到要偿还技术债时，说明业务应该还不错了，在这个当下，找准时机，有计划的偿还一些技术债务是非常有必要的事情。
2. 解决将来可能出现的问题，将来的问题我们一般称为技术前瞻性，即对即将出现或已经出现但不是很成熟的技术做一些预研和准备，居安思危，提前布局技术投资。

2. 优化流程，做到极致

所谓流程，是基于时间线做一件事的过程，是指一系列的、连续的、有规律的活动，而这些活动以特定的方式进行，并导致特定的结果的产生。其关注的是过程，我们希望通过优化和设计过程来最终达到一个更好的结果。我们做任何一件事情时，都会有流程，只不过有些流程是自发的，有些是被设计出来的，或者说是优化后的。在团队演化的过程中，流程优化和流程管理经常会提出，这些操作都是为了提炼流程或优化流程，让效率更高，让质量更有保障。

流程最终目的在于创造价值，也就是增值，这里价值在研发过程中更多的是质量提高、效率提升等。

研发流程要重点关注两个问题：

1. 流程对于做正确的事的辅助作用，是否能通过「过程正义」得到「结果正义」；
2. 流程本身的效率，是否整个流程是顺畅且高效的。

在具体实施时我们可以考虑如下一些方式：

1. 提高流程的自动化水平或者说工程化水平，如快速的本地构建速度、完善的自测环境、自动化测试、持续集成、流程的系统化等等；
2. 减少流程的沟通成本，比如说 DevOps 减少的是研发和运维的沟通成本，又或者全栈，减少的是前后端的沟通成本；
3. 流程分层：针对不同的级别将流程描述清楚，高层次流程较为粗略，中层流程和操作级流程会非常详细，以方便项目各级管理者和基层员工按照相应的流程开展工作；
4. 大处着眼，小处着手：先全局出发找问题，再深入细节解决问题，比如我们希望提升研发流程的交付速度，可以收集产品周期中每一个阶段所占用的时间，包括计划的时间和最后实际花费的时间，然后通过对比寻找问题最严重的环节，再去解决这个环节。在具体落地时可以考虑流程的可视化。

3. 提升团队效能

我们是要打造一个高效能的研发团队，团队是作为一个整体存在，在团队之间有分工，团队成员之间有协同，沟通等等，如何让 1 + 1 > 2 是在团队层面要解决的问题。以下有一些方法可以提升团队的研发效能：

1. 减少团队认知成本：如统一开发 IDE；提供完善且性能强劲的统一开发环境和联调环境；团队分工以模块负责人为核心，一个小团队一直聚集于一个模块，不经常轮换；
2. 增加知识流通，促进知识共享：如知识库的建设、好用的文档系统、代码审查、机制化的分享会等；
3. 团队的技术债会慢慢累积，在尽量减少债务的前提下把业务跑出来后，在适当的时候偿还部分债务，出来混迟早都是要还的，技术债也一样。
4. 快速开发模式，尝试测试左移或测试右移。
   • 测试左移是指在研发流程中，把测试的覆盖范围从传统的测试节点中释放出来，将其向左扩展，介入代码提测之前的部分，如开发阶段阶段，需求评审阶段，让研发人员在架构设计时就考虑产品的可测试性，并尽量进行开发自测，同时评估需求的质量，比如分析需求的合理性以及完整性等。
   • 测试右移是指把测试的覆盖范围从传统的测试环节中切出来，将其向右扩展，更多地融入代码部署、发布，甚至上线之后的步骤中。
5. 灰度发布，监控，A/B测试，混沌工程
6. 专业的项目管理，研发人数达到 30 人以上时，由于缺乏项目过程中的沟通、控制能力，是造成开发项目混乱，需求返工，研发效率低下的重要原因。如果能够在产品规划时提前发现新产品的技术难点，就可以提前进行相关的技术研究和技术开发工作，减少产品开发项目实施过程中的技术风险。在项目过程中，加强沟通、协调，及时发现各种风险因素和意外情况并采取应对措施，有助于项目计划的顺利实施，从而提高研发的效率。

4. 强化单兵能力

研发最终是要落在人身上，强化单兵能力，对于提升整个团队的效能有极大的促进作用，单兵能力的高低能决定团队总体效能的高低。

一个人的单兵能力可以从目标、效率和初心三个方面来分析：

4.1 目标

高效能人士的七个习惯的第 2、3 个习惯分别是以终为始和要事第一，当我们需要做一件事情的时候先明确本质的要解决的问题是什么，规避掉「XY Problem」，寻找到解决方案以及实现方案的过程中聚焦最重要的任务。

在个人的目标中，我们常见的目标包括业务成功、帮助团队、个人成长。这三个目标是有递进关系的。

• 业务成功是我们工作的最根本目标，也是基础；
• 在业务成功的基础上，下一步考虑帮助团队成长；
• 在帮助团队的同时，给自己带来一些直接或间接的成长机会。

4.2 效率/速度

可以仔细评估个人研发过程中哪些部分可以提速，如在开发前、开发中和开发后：

1. 开发前：完善而友好的开发环境，不要过度设计，在保证一定扩展性的够用就行，鼓励方案的讨论，并将其机制化；
2. 开发中：熟悉而高效的编辑工具和代码管理工具（如 Vim、Git，需要有一些刻意练习）让你能高效的编码，个人技能的边界扩展（如前端懂一些后端，在沟通交流中障碍就会很多；甚至全栈，沟通交流在自己脑袋里面完成）；
3. 开发后：尽快让代码跑起来，快速的本地构建、完善而快速的联调环境，使用单元测试和持续集成。

4.3 初心

对于业务，对于当下手上的事情能自驱的完成，最好是将目标和兴趣结合起来，主动的提出自己的想法并推动实施。

5. 合理度量但不追逐度量

著名管理大师德鲁克有句名言：“没有度量就没有管理”。

当我们开始想把研发过程的效能管理起来的时候，一定需要明确度量，即哪些指标可以表示效能的高低，并以此来判断是否有改进。 我们可以从三个方面来度量：

1. 研发效率/速度：开发的速度，构建的速度，需求的吞吐率，需求的周期，代码行数，平均修复时间等；
2. 研发质量：测试 BUG 数、新旧 BUG 比，缺陷率、缺陷修复率、线上 BUG 数、线上事故数，性能、安全等；
3. 业务价值：营收、NPS、功能使用用户数、客服反馈数等。

度量的大概过程是从研发过程中获取数据，并用这些数据来评估过程的效率，质量和价值。 通过度量来评估研发团队的表现，发现对研发工作效率有阻碍的地方，了解流程是否有待改进的关键点并寻求改进的方案。

在我们度量的过程中，度量指标尽量不要与绩效挂钩，而是应该作为参考和工具，帮助团队提高效能。 不要过度追逐度量，不要让度量最后变成一个「数字游戏」，避免只关注一些局部指标而导致局部优化和全局优化脱节的情况，对于过度的不顾大局的局部优化说 No，因为这种局部的优化可能导致整体效能的降低。

6. 小结

我们实现一个系统或一个需求，其实就是在生产一个产品，需要若干个「工序」，从产品需求出发，经过开发、测试、发布、运维等环节，从一种工种流转到另一个工种，最后交付给用户。 在整个研发过程中，把每道工序定义清楚，明确输入和输出的标准，保证每个工序产出的质量，提升每个工序的速度，衔接好工序与工序，就能让整个过程更高效能的流转。

从这里可以看出一个高效能的过程包括如下三个方面：

1. 清晰的「工序」定义、每个工序有标准的输入和输出；
2. 保证每个「工序」的质量和速度，做到极致；
3. 保障「工序」之间连接的有序；

转化成研发过程，一个高效能的开发过程包括如下四个方面：

1. 清晰定义每个环节，明确每个环节的输入和输出的标准，做好自测；
2. 保证每个环节的质量，产品需求有需求的质量要求，设计有设计的质量要求，研发有研发的质量要求；
3. 强化每个环节中个体的单兵能力，提升每个环节的速度；
4. 通过专业的项目管理，保障环节之间的有序进行，不快一步也不慢一步。

那么如何简单评估一个研发团队是否是高效能的呢？

看这个研发团队的一个需求从想法到上线，全流程平均生命周期需要多久，上线后的质量如何。

你好，我是潘锦，超过 10 年的研发管理和技术架构经历，出过书，创过业，带过百人团队，也在腾讯，A 股上市公司呆过一些年头，现在在一家 C 轮的公司负责一些技术方面的管理工作。早年做过 NOI 和 ACM，对前端架构、跨端、后端架构、云原生、DevOps 等技术始终保持着浓厚的兴趣，平时喜欢读书、思考，终身学习实践者，欢迎一起交流学习。微信公众号：架构和远方，博客： www.phppan.com