在互联网软件企业，今年是一个大家都在非常努力降本增效的年份，包括且不限于人员优化、人员结构优化、技术成本优化，提高人效，提升研发效能等等。 这篇文章我们从研发效能出发，尝试梳理一下打造高效能研发团队的 5 个关键步骤：目标、流程、团队、个人、度量。

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

前一篇我们聊了优先级，以有限应对无限，今天再聊一聊经常会用到优先级的决策。

记得我刚开始带团队的时候，有位前辈和我说过，管理就是收集信息，做出决策。 这里的决策就是我们今天要聊的内容。

一个组织最有限且不可再生的资源是什么，就是成员的工作时间。 对于一个互联网企业或软件企业来说，人力成本是最大的成本。 而作为一个技术团队的管理者，其最大的作用是如何让研发同学的时间能产生最大的价值，也就是如何让这些成本的 ROI 最高。 为了提高 ROI 的时，我们经常要做出决策。那么什么是决策？

在说决策之前，我们先说一下决定，决策和决定是不同的。 在各种会上，或者平常的工作中，我们会做各种各样的决定，用哪种架构，做哪个流程或者用哪种方案等等。 只有这些决定产生了资源的分配，才是真正的决定，否则就只能算是一个「伪决定」，或者说根本没有改变什么，也就没有真正的决定什么。 上面所说的资源不仅仅是实体的资源，还有组织中最有限且不可再生的资源：组织成员的工作时间。

一个决定通常具备三个特征:

1. 有要达到的目标 —— 没有目标，任何决定都无所谓
2. 有选择或者说有不同的可选方案 —— 没有选择就没有决定可做；
3. 资源是有限的 —— 资源如果是无限的，我们就可以做任何我们想做的事，而不需要做选择。

综上所述，决定就是选择最好（最合适）的方案，以有限的资源达成目的，其本质是资源的分配。

那么决策是什么，决策和决定是什么关系？

决策是关乎未来的，决策是一组具有长远影响的决定，是一系列的资源分配。

如何决策？

为回答这个问题，我们按结构化思维，把整个决策分为决策前期，决策中期和决策后期。

1. 决策前期

「功夫在诗外」，收集信息，决策是面向未来的连续决定，每个决定都是有着资源的分配，技术管理者作为分配环节主导人之一，如何高效的决策是一个值得探讨的命题。

1.1 收集信息

我们的决策大多是基于已有的信息做的，为了让决策更优，需要持续地收集信息。 虽然在我们需要做出决策时会了解一些信息，但更多的是平常的工作中主动去收集信息，支撑后续可能遇到的决策。

1.1.1 我们需要收集什么样的信息

收集信息，其实也是一个决策的过程。 确认要收集什么样的信息是确认收集的目标，我们收集信息是为了辅助做下一个决定，基于这个决定再来看要收集什么信息。

1.1.2 如何收集信息

平常工作中我们信息的收集渠道主要有如下一些：

1. 从周报中收集；
2. 从 IM 等沟通工具中，关注各种群的信息；
3. 从文档中，历史的文档，团队的文档，此时要求有哪些文档；
4. 从会议中收集，如需求规划会、技术方案评审会，晨会，例会等；
5. 从平常的聊天中收集，正式的沟通或者非正式的聊天；
6. 外部用户、内部员工投诉或反馈的问题；
7. 从自建的一些质量监控报告，自动化测试报告，自动构建的结果和系统的告警、线上的事故；
8. 从服务于整个公司或部门的业务支撑系统，大数据系统等；

通过这些渠道我们将收集到很多信息，在收集的过程中要注意信息的适当性、正确性和全面性。可以考量如下一些方面：

1. 信息是否全面，是否包含了时间维的信息，如过来的信息和未来的假设；
2. 信息收集的范围是否全面，是否包含了不同角色的观点；
3. 信息是否是片面的，因为片面的信息可能会导致错误的推导，从而影响下一步的决定；
4. 信息中是否包含错误或有些偏误的部分，有没有和权威机构做一些对比。

1.1.3 如何使用这些信息

1. 通过收集到的信息评估我们过去对未来的假设是否正确；
2. 通过收集到的信息评估我们有没有往目标靠近，如果能达成目标，或者能向目标靠近就是好的决定，可以继续，否则就需要调整。

1.2 确认目标

做开始决策时，先思考自己的目标，我们经常说「以终为始」，用想要的结果来反推现在的工作，用目标来标注现在的方向。

一个好的目标包括三个部分：

1. 明确的目的 — 我们最终要的是什么，方向在哪里，目的地在哪里，「以终为始」；
2. 明确的范围和边界 — 包括什么，不包括什么，没有范围和边界的目标不是目标；
3. 明确的视角 — 我们从谁的角度/观点看事情，做决定，视角决定了方向。

对于目标我们一定要思考我们目标是否和组织的目标一致，是否和公司的战略一致。

技术管理者的责任是要用有限的资源去达到组织的目标，即使在处理眼前问题的时候，也必须以目标为思维的起点去思考，做决定，以终为始，这样才可能达到目标。

确定目标后才开始做决策。

2.决策中期

因为资源是有限的，而我们要面对的是一个无限的世界，以有限应对无限，就需要有优先级。

2.1 确认优先级

在确认优先级之前我们需要先明确未来的目标和现状有多大的差距，这个差距需要做哪些事情才能达成，哪些事情是最重要的，如果是最后一博，应该做哪件事？

把所有的事情拉通了来看，是否现在做的是最重要的，有没有更重要的事情要做，有没有重要不紧急的事情要做，如果有，那么就先做重要的，尽量做重要的事情不做紧急的事情，。

如果几件事的重要程度相当，从它们可能造成的影响或风险的角度来区分轻重，先做正面影响大、风险小的事情。

需要有所取舍，不要只看到短期的收益，对于长线的收益也不能忽视。

2.2 可选方案

在明确了目标，确认了优先级，下一步的核心的思考是有没有更好的方案。 更好的方案就意味着有多个方案，往往最终的方案不是某一个方案，而是多个方案综合起来后的方案。

我们在做决策时，常常落入只有一个方案的陷阱中，然后去思考这个方案有没有问题，或者如何让方案更优。 此时我们更应该做的是按「 MECE 原则」，尽可能的穷举行业内的，公司内的所有可能的方案，评估这些方案的优劣，成本收益，再确认方案是什么。

在评估方案时，列一个表格，设定必要项，可选项及其权重，对可选项进行评分，加权汇总，最终可量化的得出一个方案。 然后在这个得出的方案基础上再去完善。

2.3 影响决策的心理学

2.3.1 锚定效应

锚定,是指人们倾向于把对将来的估计和已采用过的估计联系起来。

我们在做决策的时候，当评估好坏时，经常会和一些锚定的东西对比，或者和一些先入为主的信息作对比，因为本来也不存在绝对意义上的好和坏，一切都是相对的，关键看我们如何定下基点。 基点定位就像一只锚一样,它定了，评价体系也就定了,好坏也就评定出来了。

2.3.2 惯性思维

先看一个关于惯性思维的小故事，这个小故事里的逻辑在我们在给人出脑筋急转弯的时候也会经常用到，故事是这样的：

心算家阿伯特·卡米洛从来没有失算过。有一天他做表演时，有人上台给他出了道题：“一辆载着283名旅客的火车驶进车站，有87人下车，65人上车；下一站又下去49人，上来112人；再下一站又下去37人，上来96人；再再下站又下去74人，上来69人；再再再下一站又下去17人，上来23人……”

那人刚说完，伯特·卡米洛便不屑地答道：“小意思！告诉你，火车上一共还有……”。
“不，”那人拦住他说，“我是请您算出火车一共停了多少站口。”
阿伯特·卡米洛呆住了，这组简单的加减法竟成了他的“滑铁卢”。
阿伯特·卡米洛是心算家，不论是算车上还有多少人，或火车一共停了多少站口，都是难不住他的。

惯性思维也称为思维定势，也就是我们常说的手里拿了一个锤子，看到什么都是钉子，总想敲一敲。 在环境不变的条件下，思维定势使人能够应用已掌握的方法迅速解决问题。

惯性思维是人类进化过程中形成的对人类有帮助的思维定势，能减少日常中很多时候思考问题的繁琐步骤，快速解决问题。 但是它不会一直正确，可能在我们做决策的时候把方向引导到一条偏僻或者不正确的路上，此时我们就需要打破惯性，重新出发。

2.3.3 沉没成本

沉没成本，是指由于过去的决策已经发生了的,而不能由现在或将来的任何决策改变的成本。

从决策的角度看，以往发生的成本只是造成当前状态的某个因素，当前决策所要考虑的是未来可能发生的成本及所带来的收益，而不考虑以往发生的成本。

人们在决定是否去做一件事情的时候，不仅是看这件事对自己有没有好处，而且也要看过去是不是已经在这件事情上有过投入。我们把这些已经发生不可收回的支出，如时间、金钱、精力等称为「沉没成本」。

有一个叫亚克斯的心理学家说过：“一个人生的90%以上的不幸都是因为不甘心造成的”，在生活中我们常常为了逃避损失带来的负面情绪而一味的沉迷于之前的付出当中，我们会选择一种非理性的思考方式。决策时我们需要特别注意。

2.3.4 确认偏误

确认偏误也称为「证实偏差」，它一般指在一大堆证据里面，人更容易注意，记住和相信对自己有利的证据，忽略相反的证据。

中国古代有句老话叫：“情人眼里出西施”，当你喜欢一个人的时候，她的一切都是这样的美好，你会找出她的各种优点在你的朋友面前描述她。

2.3.5 X-Y PROBLEM

X-Y PROBLEM 大概是这样：

• 某人想要解决 X
• 他不知道怎么样才能解决 X，但感觉 Y 可以解决
• 他同样不知道怎么样才能解决 Y
• 他寻求 Y 的解决办法
• 其他人想要帮助他解决 Y，但是摸不着头脑为什么要使用 Y
• 经过漫长的交流，终于明白了原来他是想要解决 X，而 Y 并不是解决 X 的合适的方案

做决策往往是要解决一些问题，而问题可能并不是根本的问题，只是一个表象，需要我们找到问题的根本原因再去做决策，否则就会在一个方向性的错误上浪费资源。

3.决策后期

在方案确认后就进入决策的后期，也就是决策的执行环节。 在执行决策过程中，还要持续地收集信息，对人员进行管理，对风险进行管理

3.1 人员管理

任何决策都是需要有人去执行的，项目管理中经常用到的 RACI 矩阵表能较好地解决人员管理的问题。

RACI 矩阵表解释如下：

• 谁负责（R = Responsible），即负责执行任务的角色，他/她具体负责操控项目、解决问题。
• 谁批准（A = Accountable），即对任务负全责的角色，只有经他/她同意或签署之后，项目才能得以进行。
• 咨询谁（C = Consulted），拥有完成项目所需的信息或能力的人员。
• 通知谁 (I =Informed)，即拥有特权、应及时被通知结果的人员，却不必向他/她咨询、征求意见。

有了 RACI 矩阵的表，我们就可以知道资源是谁在分配，谁来拍板，谁能够给我们提供帮助，谁能给我们提供输入，谁来具体执行，出了问题应该找谁，做好了找谁去汇报或通知。

3.2 过程控制

决策不是一个一次性的事件，是一个不断进步或者演变的过程。 决策是面向未来的，而其依据的却是已经发生了的事实和我们对于未来未知的假设。

在执行决策过程中，我们需要持续地收集信息，观察事项发展的态势和环境的变化，主动评估当时的决定对未来所做的假设是否还成立，评估实施后的效果是否达到预期，如果发现假设不成立或不达预期，要及时调整决策。

过程中可以设置如下一些机制以对整个过程进行控制：

1. 假设实验的机制，因为决策是基于一些过去的事实和对未来的假设做出的，未来是不可知的，因此我们需要基于假设做一些实验，小范围试点，现在流行的数据驱动，A/B 实验是一个比较好的落地方案。这种机制是为了把未知转化为可能的风险，然后通过实验降低、控制、管理风险。
2. 复盘的机制，每到一个里程碑做一次复盘，确认成果，并检查我们之前的假设是否正确，是否需要调整，复盘之后再重新出发。

4. 后记

技术管理的工作就是在不确定性中寻找平衡，通过不断地收集信息，决策，改变资源从而改变团队、架构，让组织的 ROI 更高。

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