# Complexity Equation

> 当团队扩张后效率反而下降、沟通成本暴增时；当创始人不理解"为什么人多了 反而更慢"时；当企业在扩张和稳定之间犹豫不决时；当组织设计要做调整时。 触发信号："三个人干得挺好的，加了第四个人反而乱了？"、"部门越来越多， 协调越来越难"、"增长要不要放缓？人多了是不是有问题？" 不适用于：个人层面的时间管理问题、初创期人数极少时的线性复杂度场景。

- Skill: `ace3000chao/complexity-equation` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ace3000chao/complexity-equation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ace3000chao/complexity-equation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ace3000chao (https://skillmd.com/u/ace3000chao)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ace3000chao/complexity-equation

---


# Complexity Equation（复杂度乘法方程）

## R — 原文 (Reading)

> "Add a third person, and the degree of complexity triples from two to six. Add a fourth, and it quadruples to 24. Expanding from three to four people grows the team only 33%, yet complexity may increase 400%."
>
> — Vern Harnish, Scaling Up, 第2章 Barriers

---

## I — 方法论骨架 (Interpretation)

复杂度乘法方程揭示了企业扩张的隐性代价：**人数线性增长，复杂度指数增长**。

公式的本质：每增加一个人，与所有人的沟通节点都要重新计算。
两个人=1条关系；三个人=3条关系；四个人=6条关系；五个人=10条关系。
这叫"组合数增长"——n个人产生的连接数 = n(n-1)/2。

**数字说话**：
- 2人 → 1连接
- 3人 → 3连接（+200%）
- 4人 → 6连接（+100%，但团队只增33%）
- 5人 → 10连接
- 10人 → 45连接

关键洞察：增长不是问题，**缺乏管理增长的系统**才是问题。
复杂度不是要不要面对的选项，而是成长的必然副产品。
解决方案不是"不增长"，而是"提前建立消化复杂度的机制"：
流程（Process）、规则（Disciplines）、沟通节奏（Rhythm）。

---

## A1 — 书中的应用 (Past Application)

### 案例 1: 团队从3人到4人的"死亡陷阱"
- **问题**: 3人团队运转流畅，加了第4个"聪明人"后反而频繁开会、协调成本暴增
- **方法论的使用**: 用复杂度公式解释——不是第4个人不行，是连接数从3跳到6，
  团队没有为此准备额外的流程和沟通机制
- **结论**: "4人门槛"需要引入明确的会议节奏和决策流程
- **结果**: 创始团队开始重视"加人不加乱"的组织设计

### 案例 2: 30人扩张到50人的中层管理危机
- **问题**: 快速扩张期，管理层抱怨"信息传不下去"，部门墙越来越厚
- **方法论的使用**: 50人产生的连接数是1225，30人是435——人增加了67%，
  连接数增加了近3倍。没有对应的信息流通机制，必然出现失真
- **结论**: 在这个规模必须引入结构化的沟通机制（周会、简报、可视化看板）
- **结果**: 引入Rockefeller Habits中的会议节奏工具，情况显著改善

### 案例 3: 复杂度的"隐性税"
- **问题**: 创始人抱怨"我明明雇了更多人来分担，怎么我还是这么累"
- **方法论的使用**: 展示数字：6人团队有15条连接，每条连接都在消耗
  创始人的协调能量。更多人意味着更多连接，更多连接意味着更多潜在冲突和决策节点
- **结论**: 解决方式不是减人，而是建立不依赖创始人的决策系统
- **结果**: 创始人对"系统化"而非"靠人"有了全新理解

---

## A2 — 触发场景 (Future Trigger) ★

### 用户会在什么情境下需要这个 skill?

1. **团队从3-5人向10人以上扩张的阶段**——开始感觉到协调成本上升，
   但还没意识到这是结构性的
2. **创始人在"要不要招人"的问题上纠结**——感觉招了人效率反而下降，
   怀疑是不是招错了人，而不是系统设计问题
3. **公司出现"部门墙"或"沟通断层"**——部门之间互相甩锅，
   信息在传递过程中失真或消失
4. **在做组织架构设计或汇报线调整**——想要理解增加一个层级
   或者增设一个部门会对复杂度产生什么影响
5. **讨论"公司可不可以再快一点扩张"**——需要量化理解
   扩张速度与组织消化能力之间的关系

### 语言信号 (用户的话里出现这些就应激活)

- "我们人也不多啊，怎么感觉协调起来这么累？"
- "加了一个人之后好像更慢了，是不是招错了？"
- "部门之间好像有墙，信息传着传着就没了"
- "我一个人扛不住了，是不是该招个副总？"
- "增长太快是不是有问题？要不要放慢脚步？"
- "三个人干得挺好，加了第四个反而出问题了"

### 与相邻 skill 的区分

- 与 `Growth Paradox（成长悖论）` 的区别: 成长悖论是"为什么越大越累"
  的哲学层面解释；复杂度方程是这个悖论的数学层面量化工具
- 与 `PACe（流程问责表）` 的区别: PACe是复杂度管理的具体落地工具，
  复杂度方程是"为什么要用PACe"的原因解释
- 与 `Rockefeller Habits` 的区别: Rockefeller Habits是复杂度管理的
  一套具体习惯清单；复杂度方程是这些习惯存在的理论依据

---

## E — 可执行步骤 (Execution)

当 skill 被激活后，agent 应按以下步骤执行:

1. **【量化现状】计算当前团队的连接数**
   - 公式：连接数 = n(n-1)/2（n=总人数）
   - 问用户："你现在团队有多少人？" → 计算并展示连接数
   - 完成标准: 用户看到连接数，理解"为什么现在协调成本这么高"

2. **【预测未来】模拟扩张后的复杂度增长**
   - 问："如果你计划扩张到X人，连接数会变成多少？"
   - 计算并对比：现在是多少，扩张后是多少，增长百分比
   - 判停条件: 若用户说"现在还早"，则聚焦当前规模，不需要预测

3. **【制定对策】引入复杂度消化机制**
   - 每个连接本质上需要三类机制之一来消化：
     ① **流程**（标准化，减少临时沟通需求）
     ② **节奏**（固定会议/周报，让信息定期流通）
     ③ **规则**（明确谁决策什么，减少关系协调）
   - 根据用户当前痛点，选择优先级最高的1-2个机制落地
   - 完成标准: 用户理解"加流程不是管束，而是降低每个人的协调负担"，
     并产出一个具体的"下月引入机制"清单

---

## B — 边界 (Boundary) ★

### 不要在以下情况使用此 skill

- **个人时间管理问题**：一个人管很多任务，复杂度方程不适用——
  这是个人认知负荷问题，不是人际连接问题
- **10人以下极度扁平的小团队**：此时连接数还处于可管理的范围，
  不需要过度工程化；这个skill的预警价值大于干预价值
- **纯创意/研发类工作**：当团队产出主要依赖少数人的深度思考而非协作时，
  复杂度方程的意义打折——不是所有连接都能产生价值

### 作者在书中警告的失败模式

- **用"增加人手"解决复杂度问题**：实际上增加了更多连接，
  让问题更严重；正确的应对是增加"消化复杂度的机制"
- **过早引入复杂组织架构**：在连接数还很低时就设立多层汇报线，
  人为制造不必要的连接，增加复杂度而非管理复杂度
- **认为"我们公司不一样"**：创始人总觉得自己的团队特殊，
  可以绕过复杂度规律；但这个规律是数学性质的，不以行业为转移

### 作者的盲点 / 时代局限

- 原书对"远程工作/异步协作"对复杂度的影响没有充分讨论；
  远程团队的部分连接转为异步，连接质量而非连接数量成为更关键的变量
- 方程是静态快照，没有考虑"连接强度"差异——
  有些连接是高价值的深度协作，有些只是低价值的例行通知
- 对"复杂度爆炸的临界点"没有给出精确的人数阈值；
  不同文化、不同流程成熟度的企业临界点差异很大

### 容易混淆的邻近方法论

- **彼得原理（组织层级增加导致的问题）**：关注"人放在错误层级"，
  不关注连接数本身
- **组织生命周期理论（Greiner）**：描述的是成长阶段与危机的对应关系，
  复杂度方程是这个理论中某个危机的解释机制而非完整框架
- **Mckinsey 7-S**：关注组织内部一致性，复杂度方程关注
  人际连接数量的可量化维度，维度不同但互补

---

## 相关 skills (阶段 3 填充)

- depends-on: [growth-paradox, pac-e]
- contrasts-with: [peter-principle, greiner-lifecycle]
- composes-with: [rockefeller-habits, fac-e, cash-conversion-cycle]

---

## 审计信息

- **验证通过**: V1 ✓
- **测试通过率**: N/A (待测试)
- **蒸馏时间**: 2026-04-26