创新“特区”项目的管理之道

type

status

date

slug

summary

category

comment

icon

password

自从 2017 年从学术研究转向工业界以来，我参与了两个软件项目。每个项目最初都是一个小型的、从零开始的秘密项目，由 2-3 人参与，并逐渐扩展为一个大型的、传统的软件工程项目，拥有数十名工程师。其中第一个项目（2017 年至 2021 年）是 Meta 的 Delos，一个类似 Chubby/ZooKeeper/etcd 的控制平面存储系统。第二个项目是一个新的 Kafka 引擎（2022 年至 2024 年），它可以在任何解耦的存储层上运行（并驱动 Confluent Freight 产品，其中 S3 被用作该存储层）。截至 2025 年，Meta 的几乎所有系统都以某种方式依赖于 Delos（例如，这篇文章描述了一个依赖链）；Confluent Freight 刚刚成为通用产品，而时间将告诉我们它是否在商业上成功，尽管早期结果很有希望。

虽然这些系统在构建和运营方面技术难度很大（尤其是考虑到它们在各自公司堆栈中的关键作用），但我发现这些项目的挑战主要在于管理。即使是世界上最具创新性的公司，其（主管和工程师的）激励机制也与从零开始的秘密项目创新不兼容。在过去几年与各种管理人员的讨论中，我发现自己在形成一套关键原则，我在本文中概述了这些原则。我希望这些规则对其他寻求为他们的秘密项目定义一套共同原则的工程师和管理人员有所帮助。

一些注意事项：我是一个工程师，不是管理者，我一生中管理的最多只是几个实习生和研究生；这只是作为一个技术项目主管/架构师对我需要管理者做的事情的愿望清单。这些规则可能非常具体于在大公司构建新的存储服务。在某个时刻，项目必须退出秘密项目模式，这些规则将不再适用。我的样本量是 N=2，很难证明这些规则与项目成功有因果关系（甚至只是相关性）。

A. 没有非编码的架构师： 如果你想参与系统设计，你必须写代码。（注意，如果你带来了一些特定的专业知识，不写代码是可以的：例如，如果你是一个世界级的纠删码理论家。如果你是一个世界级的运维专家，可能也可以，尽管根据我的经验，这样的人通常对代码非常熟悉）。如果团队里有任何人唯一的任务是分配工作给其他人，那出大问题了。

B. 没有个人的“所有权”： 每个人都对一切负责。如果船翻了，每个人都跟着完蛋；没有独立赢或输的方式。我们希望人们互相加速和赋能，扩大蛋糕，而不是在固定的蛋糕上互相竞争。我们容忍自我推销活动为零：这是管理者和团队领导者的责任，要确保人们根据他们实际做的事情得到公平的奖励。这样 teams 的最佳管理者告诉他们要尽可能快地完成工作；并完全将证明评分的负担从工程师身上移开。如果需要保护工程师的评分开始影响项目的优先级，那出大问题了。

C. 依靠优势而非弱点: 我们希望每个人专注于自己真正擅长的事；而不是自己最不擅长的事。后者在大型公司中常见，工程师想晋升时，经理会让他们专注于那些阻碍他们发展的领域。如果工程师问经理什么能让他们晋升，答案必须是“跑得越快越好，让团队成功上线”。如果在这种情况下这个人客观上无法晋升，那就出大问题了：项目不够有影响力，不值得采用“特种部队”模式；或者这个人根本不适合这个项目（比如他们的技能不适用于该项目，或者他们在假设的专业领域不够专业等）。

D. 正式沟通（对外）必须极其精确、高质量且经过审核: 用杰夫·贝索斯的话来说，我们希望“简洁的文档和混乱的会议”。不同的利益相关者需要不同类型的消息：有些人可能需要了解技术上的亮点；其他人可能想知道商业影响；有些人可能需要知道下个月会发生什么，而有些人可能需要知道三年内会发生什么。即使是经验丰富的写手，写一份具有这种多功能性的文档也要花费数月。团队公开说的话会影响其声誉和可信度，并限制其未来的行动。请注意，这与透明度并不矛盾：非正式沟通应该在所有层级上以最大程度的透明度进行，因为非正式讨论时通常更容易传达细微差别和背景。

E. 避免“第一个文档胜出”的文化。 由一个人写一份面向公众的文档会对团队的设计参与度产生抑制作用；它会“污染池子”。我们希望团队中经验较少的成员体验到发现（或重新发现）想法的兴奋感；这是培训过程的一部分。面向公众的文档应在设计过程完成后由团队共同撰写。我们不应该将文档作为交付成果来奖励。（这些都不适用于团队内部的沟通，团队内部的沟通可以以任何形式和任何质量水平进行）。

F. 按影响奖励: 团队中的每个人都遵循同样的规则：当项目以某种形式上线时，他们会得到奖励。没有上线就没有晋升（除非团队中有人已经到了该晋升的时候）。另一方面，即使没有上线的影响，我们也保证合理的基准评分。基本上，我们为工程师移除了上线前的一切风险和收益。

G. 最小化依赖: 依赖会花费大量时间（外部团队通常有多个优先级）。它们会导致项目质量不均。设计上可能会出现“空气间隙”。一种失败模式是外部团队通常专注于特定解决方案而不是问题领域；因此，要求外部团队“构建一个组件来解决 X”往往意味着“修改我们现有的解决方案 Y 来解决 X”，这会增加大量的意外复杂性。请注意，“按影响奖励”的激励机制迫使团队小心依赖：如果他们做得完美但依赖没有出现，团队将不会得到奖励。实际上，这确保了团队只有在绝对合理且他们能接受风险的情况下才会引入依赖。

H. 理解新项目的需求层次： 对于某些技术问题，进度曲线是连续的：容易得到一个初步能运行得还算不错的版本，然后逐步改进它，但很难达到理想版本（例如，一个多租户负载均衡器可能需要数年的政策调整）。其他问题则具有离散的进展：很难得到一个合理的 v0，但之后你几乎可以不管它（例如，一个仅在重新配置时使用的共识协议）。在一个成熟的 1 到 10 系统中，管理和工程师将把大部分时间花在前一类问题上；因此，在 0 到 1 系统中优先考虑相同的问题可能很有诱惑力。但在一个全新的数据库（例如）中，拥有一个工作的共识协议远比在首次发布中拥有出色的负载均衡更重要。

I. 招猪不招鸡： 猪是全身心投入项目的工程师；而鸡是兼职参与项目的工程师。我们倾向于少数猪，而不是大量鸡。请注意，这不是能力问题：即使是最好的鸡也会损害速度并削弱项目的共同命运感。

J. 残酷地消除流程： 这一点应该很明显：小团队不需要流程。不要给团队强加任何形式主义活动。让他们自由执行。在这种设置下，管理者的角色是提供鼓舞人心的领导力并激励团队，而不是管理/限制风险。

K. 逐步给团队施加压力： 为团队设定雄心勃勃且略带不可能的目标。这有两个效果：一，它迫使团队无情地优先级排序，你会在成功中砍掉任何不必要的东西；二，它推动团队通过系统设计找到杠杆，你找到新的方法在不那么多的代码/复杂性的情况下交付相同的结果，因为你实际上没有时间编写代码/管理复杂性。

L. 不要过早退出秘密项目模式： 一旦执行风险开始主导设计风险，退出秘密项目模式是有道理的。然而，还有第二个考虑因素：理想情况下，团队应保持在秘密项目模式中，直到它取得某种实际成功，即某物发布。要理解为什么，请考虑创建秘密项目的一个关键原因是孵化现有组织内的一种新文化。随着时间的推移，我们可以围绕核心项目创建更多传统外观的辅助团队，创建新文化和现有文化的一个复合体。但时机至关重要；如果我们发布前就扩张，现有文化将淹没新文化（这很合理，因为新文化没有成功来支持它）。

M. 快速失败与僵尸模式： 新、风险项目经常必须在不确定的环境中运营，其中我们的假设（关于市场、硬件、客户）正在迅速变化。与其追求完美的决策，不如快速行动并尝试；并且快速停止，而不是允许项目游荡，消耗资源/注意力，并承担机会成本。如果我们能快速失败并快速恢复，坏决策就不那么重要了；并且我们为下一次尝试获得数据。任何事业的快速失败都需要我们在开始工作之前，为在某个短期框架内（例如，3-6 个月）确定其成功的具体标准。快速失败适用于整个项目，也适用于项目内较小的决策（例如，人员分配），甚至可以作为构建系统的哲学（实际上，我们可以通过快速迭代失败来将吞吐量转换为好吞吐量）。

我们想要研发，而不是非研发： 研发项目常常陷入无人管理的境地，部分原因是难以追究这些项目的责任和衡量其成功。理想情况下，我们希望项目既有好的“研究”（能在顶级会议上发表），又有好的“开发”（能成功上线）。一种反模式是外部研究人员认为项目必须是“开发”（因为它显然不是好的“研究”），而外部开发人员则认为项目必须是“研究”（因为它显然不是好的“开发”）。

同步、频繁、非正式的沟通至关重要： 优先安排每日同步沟通至关重要。请注意，这个会议不是用来列和管理工作项（没有人想在秘密项目中进行压力巨大的每日站会）；它的目标是构建对设计空间的共同理解；以及一套用于评估该空间各点的共同价值观。我们希望鼓励对设计、长期策略和短期策略的自由辩论；并培养工程师协作思考和讨论设计的技能。为了管理会议负担，取消所有其他广播会议。这一原则是我们倾向于小团队的原因之一。

人员不可替代。 团队构成至关重要。我们的运营模式是一个体育团队，我们根据团队的需求和技能选择特定位置的成员。即使一个守门员技术再好，多一个守门员对足球队也帮助不大。好的管理者往往会尽力让工程师变得可替代，以降低项目的人员风险；但在真正的秘密项目团队中，没有人是可替代的。

主动面对风险。 在秘密项目模式下，目标是尽快减少技术风险。因此，团队必须在高风险领域猛攻。抵制在系统低风险、已理解部分稳步前进的诱惑。

保持团队小。 这一点看似明显，但在大公司中却很难执行，原因有很多。一个有善意的管理者可能会增加工程师来 1）加快项目进度；2）奖励工程师。但我们已经知道（！）50 年了，如果给软件项目增加人员，项目实际上并不会更快 2。而且增加错误类型的工程师往往会损害项目和工程师的职业生涯（参见规则 P 关于守门员的规则）。关键在于，保持团队小确保它始终资源受限（参见规则 K 关于无情优先级的规则）；同时也保护项目免受削减成本计划的影响（因为公司不会通过关闭项目来显著降低成本）。

我希望这些规则能帮助管理者和工程师找到共同点——祝你们开始自己的干净 slate 秘密项目顺利！

注释：