为什么工程经理不应该进行代码审查

飞书用户2634

2024年10月16日修改

作者：Emily Dresner

在讨论团队组织时，我经常被问到：“为什么不让技术负责人管理团队？”我的回应是像吸血鬼遇到圣水一样嘶嘶作响。接着，又会有人问：“既然你希望团队中有经理，那经理可以进行代码审查吗？”此时，我瞬间燃烧了起来。​

这个问题经常被提及，但我们可以深入思考这个问题（以及我的反应）。​

•
为什么技术负责人不应该管理团队？  ​

•
为什么工程经理不应该进行代码审查？  ​

像技术领域的其他问题一样，答案取决于具体情况。在这里，我尝试回答“为什么 TL（技术负责人）不应该管理团队，以及为什么拥有足够规模的团队时 EM（工程经理）不应该进行代码审查”这一长期存在的问题。​

在回答这个问题时，我们要考虑三个方面：角色定义、团队沟通复杂性和团队规模。让我们通过一些图解来剖析我的理由。提醒一下：前方有简单的数学。​

经理和技术负责人角色的区别

首先，我们需要解决角色定义的问题。工程经理和技术负责人是两个不同的角色，拥有不同的技能。一个人在其中一个角色表现优秀，但不一定适合另一个角色（反之亦然）。例如，团队中最优秀的程序员并不总是最适合组织工作的那个人。​

然而，团队需要两个角色才能高效运作。让我们来对比一下这两个角色的职责。​

TL 与 EM 的角色和责任区别

•
TL（技术负责人）：专注于技术架构、技术决策、执行技术任务  ​

•
EM（工程经理）：专注于团队管理、职业成长、沟通和协调工作  ​

这张表格展示了技术负责人和工程经理之间的合作关系——一种分工合作：技术负责人负责技术深度工作，工程经理负责组织和沟通工作。两个角色在团队中的地位和职责是平等的，但他们执行的任务不同，以支持团队的成功。​

为了使经理-负责人伙伴关系有效，他们需要在彼此之间建立信任。​

•
经理应将团队的技术领导权交给技术负责人，并退出技术细节。管理工作本质上是政策性的，经理应尊重边界。否则就会变成微观管理，破坏信任。  ​

•
技术负责人应将职业发展、团队成长、沟通和协调工作委托给工程经理，自己专注于架构、技术选择和推动执行。​

O(n²) 的沟通复杂性

接下来，我们谈谈沟通。一个经理通过扎实的沟通基础来建立一个高效运作的团队。随着团队成员的增加，团队中的沟通路径会成倍增加。我们通常直观地认为团队沟通的复杂性随着 O(n) 线性增长，但实际上，这里的 “人月神话” 是 100% 准确的。​

团队中的沟通复杂性以 O(n²) 的速度增长，也就是通信路径的数量是 n * (n-1) / 2。​

•
一开始，你是团队中的唯一成员，整天只和自己对话。此时沟通路径为 0。  ​

•
增加一名成员 A，现在你和 A 互相交流，沟通路径变成 1 条。  ​

•
增加另一名成员 B，现在你管理 3 条沟通路径：你—A，你—B，A—B。  ​

•
再增加一名成员 C，沟通路径增加到 6 条。  ​

随着团队成员的增加，沟通路径呈现指数级增长。当团队达到 5 人时（总共 6 人，包括你），经理需要管理 26 条沟通路径，以确保团队能够顺利执行任务。​

所有这些沟通联系都需要投入大量时间。经理在复杂的沟通网络中扮演“蜘蛛”的角色，包括：​

•
明确优先级  ​

•
推动团队执行  ​

•
与利益相关者协调状态和发布进度  ​

•
确保团队的流程顺畅  ​

为什么工程经理不应该进行代码审查​