微服务、DevOps…不是效率银弹，请同时升级你的管理方式

“  对于正处于创业期的互联网公司来说，研发效率就是生命线。 员 工人数的增加并不等于公司在变好，一家没有效率的创业公司，将以最快的方式死去。 ”

在互联网快速发展的这些年，软件工程的协同方法也在同步升级：从传统的瀑布，到敏捷，再到微服务和中台化。但是先进的开发模式并非万能的解药，996几乎成为了 程序员 的标配，似乎有种效率不行、工时来凑的趋势。

前几天和同事聊天，谈到了一个特别有意思的现象：我们一起经历了两家创业公司，但是能明显感觉到新公司在研发效率和研发质量上都比前公司好太多，然而这两家公司的基础设施以及工程师水平差距并不大。 

下面这些现象更是在创业公司屡见不鲜：

• 研发团队人很多，大家也很辛苦，但是仍然被业务吐槽迭代速度慢。

• 开发、测试、产品彼此不信任，害怕背锅，整天各种扯皮 。

• 开发人员疲于应付新需求，同时线上故障频繁出现，一边做新feature一边改BUG，迭代节奏完全被打乱。

随着创业公司的快速发展，研发效率跟不上是最容易出现、也是最急需解决的问题。如何快速做出调整真的非常挑战组织 能力 和管理水平。

做好了，能为业务发展保障护航，让技术同学的投入更有价值；做不好，不仅会拖业务后腿，而且很有可能让团队氛围变糟，优秀人才流失，最终彻底击垮一个团队。

这篇文章，我将结合自己的经验和理解，分别从组织架构、流程制度、工程方法、团队文化4个角度聊聊：如何让研发团队的工作更加高效？

01 组织架构

做到和技术架构同步升级

组织架构决定了协作方式。当一个组织变成一个 「 利益共同体」 时，效率才能真正体现出来。否则组织之间只会相互推诿，人为增加各种流程制度来保护自己的利益，进一步降低效率。

《人月神话》这本软件工程领域的经典著作中，引用并推广了一个非常著名的定律：康威定律（Conway's law）.

设计系统的组织，其产生的架构设计等同于组织之间的沟通结构。

通俗理解就是： 组织架构需要和 技术 架构 相匹配。 在团队内部进行高频、细粒度的沟通，和团队外部，定义好契约，只进行粗粒度的沟通。 这一点和软件设计的高内聚、低耦合原则一致（看来组织管理和软件设计有时候是相通的）。

创业公司初期， 一般采用职能型组织架构，比如： 研发团队、测试团队、运维团队、产品团队等，各个团队彼此独立，早期 因为人数少、业务单一 ， 这种架构通常不会出现效率问题。

真正的挑战从此时开始：公司从单条成功的业务线裂变出不同产品和服务的过程，人员快速增加，业务逐渐复杂， 并行项目变多，如果继续维持职能型的组织架构就会出现资源冲突，沟通成本变高，进而引发一系列的协作问题，最终阻碍业务的发展。

此时，大部分公司的做法都是：推进微服务、DevOps... 殊不知这些手段能发挥出价值的核心因素并不在于技术本身。 而是需要 公司 顶层合理地划分服务边界，规划出相匹配的组织架构 ，但是能做到这一点的公司真不多，要么没经验，要么高层大佬们各怀心思、不想放弃自己的利益。

端到端的跨职能组织架构，是目前被广泛认可、并且适合推进微服务技术和敏捷开发的最佳组织形式，它同时能够满足业务快速、多变的特点。

职能线负责专业能力的培养与专业规范的制定，为业务线提供技术资源。每个业务线都是全功能的团队，有自己专属的运营、产品、研发和测试人员，大家围绕同一个业务目标不断的迭代开发。 这样的团队是全栈、自治和扁平的，能根据业务节奏自行决定迭代速度，同时绝大部分时间里可独立完成整个业务功能的全生命周期管理。

02 流程制度

从源头提升效率，对流程做减法

针对高频的工作流程设定制度是必须的 （ 比如基本的项目管理流 程 ） ，但是过细的过程管理则显得多余，反而会抑制工程师们的创新能力，降低工作效率。

太多的管理者，一出问题就喜 欢定 个 制度， 引入一系列 的流程和追责机制 来约束大家的行为 ，但是很多时候并没有抓住问题的本质，因此定出来的制度既蹩脚还不受欢迎。

从源头解决问题往往是最高效的，举几个例子：

• 一个复杂的业务，如果经常出现：改动 A 模块的代码引发 B 模块的BUG。很可能 就 是架构设计有问题，两个模块过于耦合。如果管理者认为是研发周期短没梳理到影响点导致的就是没抓住本质。

• 线上BUG频繁出现，管理者不抓研发质量，怪罪测试不仔细就是没抓住本质。

• 一个迭代，研发平均要花费20%的时间去修复线上故障。管理者 不去提高 线上质量 ，而是认为每个迭代都需要预留出足够多的时间去改BUG就是没抓住本质。

分析问题入木三分， 从 源头把控好质量，是技术管理者最应该做的，它能保证团队不偏离方向，减少无效劳动。从项目的交付过程来看，需求的质量是第一位，其次是技术设计的质量，然后是代码和自测的质量，最后才是测试质量，前一步做到位了，后一步的效率才能有保证。在制定项目流程时，我认为明确好每个环节的交付目标即可，而不是非常细的执行要求，这样各个环节的执行者能选择自己最高效的方式去操作。

另外，管理者要定期review制度的执行效率，多听听底层的声音。 对于工程师而言，如果 没办法将大多数时间投入到技术环节 ，那么 流程制度一定是有问题的。 比如说：每天要参加 大量的 会议，一项工作要频繁汇报细节， 决策层级太多等等，这些是最常见的 效率杀手 。

对于一个高效的团队， 高素质的研发人员加上一些基本的制度是最理想的状态。日常工作中的 很多案例，如果仅仅是因为个别工程师的经验或者能力不足导致的，做好复盘和培训远比一个新制度有效。

03 工程方法

标准化、自动化、 工具 化

用技术性思维解决日常研发过程中的效率问题应该是技术人的特长。受益于开源软件、虚拟化技术以及各种实用工具，我们基本不需要自己造轮子，结合自己的实际需求用好这些就已经可以大大提高研发效率了。

基础设施建设、运维自动化、服务治理与监控，这3个方面都是利用开源红利日趋成熟的体系化方案，一般都有专门的架构运维团队和工程效率团队不断地迭代升级。

• 基础设施建设： 分布式框架、存储中间件、消息队列 、任务调度平台、日志平台等。

• 运维自动化：源代码管理、持续集成、配置标准化、 自动化部署 、 测试环境管理、灰度发布、虚拟化等。

• 服务治理与监控：服务注册和发现、集群协同、调用链跟踪、服务质量监控等。

除此之外，还有很多事情可以进一步通过标准化、工具化和自动化来提高效率。参考懒人思维：重复的事情尽量让机器来做。

「 标准化 」 主要是为了拉齐团队的沟通界面，将常规性的工作采用统一的输出方式，从而减少理解成本，比如：技术设计文档模板、周报模板、团队周例会模板、项目迭代报告等等。

「 自动化 」 更多和DevOps结合起来，让研发测试工作进一步提效。比如：集成代码时 自动 进行编码规范的检查、利用脚手架自动生成 新项目的 框架代码、定时执行业务监控程序、各种测试自动化（包括：单元测试、接口测试、核心流程的集成测试）。

「工具化 」则是通过技术手段将重复性的工作用程序来实现，比如：线上问题的排查工具、测试数据或者线上数据的构造工具等等。

另外，我认为测试左移和测试右移是非常好的工程实践方法，如果能让团队中的每个成员意识到它们的好处并推动落地执行，将会使得研发质量更有保障，真正做到 「 唯快不破 」 而且快得更加持久（此时你就不会苦恼如何推行单元测试了 ） 。

04 团队文化

信任、主动、知识 共享

要想车子快，全靠车头带，和高效的人一起工作，你也会变得更加高效。当高效成为了团队基因，它能不断影响新加入的同学，变成一种传递的力量（道理有点虚，不过我认为是最实用的一点。如果你是管理者，请先反思自己是不是一个高效率的人） 。

「 信任 」 是高效协作的第一前提。管理者交代清楚目标，确定好执行计划即可，不做执行上的干预，这是绝大部分技术同学最喜欢的工作方式，不被束缚，有发挥空间，同时管理成本低。

之前看过一个研究分析，一项工作如果员工的心态是Want to d o，而不是Have to do， 最终的工作效果差 4倍。 如何让组员更加 「 主动 」 ，提供3点参考意见：

• 交代清楚工作的价值（这个价值尽量和员工的核心诉求产生关系，比如能力提升、升职、加薪或者精神层面的认可）。

• 有相应的奖励机制或者绩效措施作为牵引，做得好与坏必须要区别对待。

• 如果前面两点还没有效果，可以直接淘汰。

「知识共享 」 对于构建一个开放、自学习的团队非常关键，如果团队具备了快速成长的能力，将获得更长期的高效。 通过知识沉淀和分享， 一方面可以将有用的经验或者技能传递给更多人，形成团队的长期资产；另一方面，在这种文化牵引下，每个人都会变得更加自驱，并不断突破自己的思维和认知边界。

写在最后的话

如何让研发团队更加高效？有无数条路径和上千个细节，而每一点都和 「 人 」相关 。是的，当大家都认可了当前所做的事情，认可了 时间是一种 稀缺资源，高效似乎也挺简单。