公司操作系统

company-os
分类通用
作者Alireza Rezvani
许可MIT
评分4.60/5
使用8.1K

公司操作系统 (Company Operating System)

操作系统是指决定公司如何运作的一套工具、节奏和协议的集合。每家公司都有一个操作系统 —— 只是大多数公司意识不到它的存在。将其显性化，才能使其可优化。

关键词

操作系统, EOS, 企业家操作系统 (Entrepreneurial Operating System), Scaling Up, 洛克菲勒习惯 (Rockefeller Habits), OKR, 合同制/合议制 (Holacracy), L10 会议, Rocks (核心目标), 计分卡, 问责图, 问题清单, IDS, 会议节奏, 季度规划, 每周计分卡, 管理框架, 公司节奏, Traction, Gino Wickman, Verne Harnish

为什么这很重要

大多数运营功能紊乱并非人员问题，而是系统问题。当出现以下情况时：

  • 同样的问题每周重复出现：缺乏问题解决系统

  • 会议感觉毫无意义：缺乏结构化的会议节奏

  • 没有人知道谁负责什么：缺乏问责图

  • 季度目标无法达成：Rocks 并非真正的承诺

修复系统，人员在系统中的运行效率自然会提高。

六大核心组件

无论选择哪种框架，任何有效的操作系统都包含以下六个部分：

1. 问责图 (Accountability Chart)

它不是组织架构图。问责图回答的是：“谁为这个结果负责？”

关键区别： 每个职能由一个人负责。多人可以参与其中，但“所有权”意味着最终责任落在一个人身上。

结构示例：

code
CEO
├── 销售 (CRO/VP Sales)
│   ├── 入站线索 (Inbound pipeline)
│   └── 出站线索 (Outbound pipeline)
├── 产品与工程 (CTO/CPO)
│   ├── 产品路线图
│   └── 工程交付
├── 运营 (COO)
│   ├── 客户成功
│   └── 财务与法务
└── 人力 (CHRO/VP People)
    ├── 招聘
    └── 人事运营

原则：

  • 不允许共同所有权。“Alice 和 Bob 共同负责”意味着没有人负责。

  • 在早期阶段，一个人可以担任多个角色。这没问题，但必须明确。

  • 随着规模扩大，每季度重新审视。所有权会随公司成长而转移。

通过工作坊构建：
1. 列出公司执行的所有职能
2. 为每个职能分配一名负责人 —— 没有例外
3. 识别空白（无人负责的职能）和重叠（两人都认为自己负责的职能）
4. 发布该图表。一旦发生变化立即更新。

2. 计分卡 (Scorecard)

每周更新的指标，用于告知公司是否在正轨上。不是每月，也不是每季度，而是每周。

原则：

  • 最多 5–15 个指标。超过 15 个就无法集中注意力。

  • 每个指标必须有负责人和每周目标（是一个具体数字，而非范围）。

  • 状态用 红/黄/绿 表示，而不是写段落描述。

  • 计分卡在领导团队周会上讨论。只有红色指标才占用讨论时间。

计分卡结构示例：

| 指标 | 负责人 | 目标 | 本周 | 状态 |
|--------|-------|--------|-----------|--------|
| 新增 MRR | CRO | €50K | €43K | 🔴 |
| Ch... | ... | ... | ... | ... |
urn | CS Lead | < 1% | 0.8% | 🟢 |
| 活跃用户 | CPO | 2,000 | 2,150 | 🟢 |
| 部署次数 | CTO | 3次/周 | 3 | 🟢 |
| 待处理严重 Bug | CTO | 0 | 2 | 🔴 |
| 资金跑道 (Runway) | CFO | > 18个月 | 16个月 | 🟡 |

反模式： 测量所有指标。如果你追踪 40 个 KPI，你是在观察，而不是在管理。

3. 会议节奏 (Meeting Pulse)

驱动公司的会议节奏。这不是可选的——这种“脉搏”是维持公司生命力的关键。

完整节奏表：

| 会议 | 频率 | 时长 | 参与人 | 目的 |
|---------|-----------|----------|-----|---------|
| 每日站会 | 每日 | 15 分钟 | 各团队 | 仅讨论阻碍因素 |
| L10 / 领导层同步会 | 每周 | 90 分钟 | 领导团队 | 计分卡 + 问题讨论 |
| 部门回顾会 | 每月 | 60 分钟 | 部门 + 领导层 | OKR 进度 |
| 季度规划会 | 每季度 | 1–2 天 | 领导层 | 设定重点目标 (Rocks)，回顾战略 |
| 年度规划会 | 每年 | 2–3 天 | 领导层 | 1 年及 3 年愿景 |

L10 会议（每周领导层同步会）：
得名于每次会议的目标都是达到 10/10 分。固定议程：
1. 好消息 (5 分钟) —— 个人 + 业务
2. 计分卡回顾 (5 分钟) —— 仅标记红色项
3. 重点目标 (Rock) 回顾 (5 分钟) —— 每项目标是否在正轨
4. 客户/员工动态 (5 分钟)
5. 问题列表 (60 分钟) —— IDS 流程（见下文）
6. 待办事项回顾 (5 分钟) —— 上周的承诺事项
7. 总结 (5 分钟) —— 为会议打分 (1–10)，讨论下次如何达到 10 分

4. 问题解决 (IDS)

核心问题解决循环。每个问题最多讨论 15 分钟。

IDS：识别 (Identify)、讨论 (Discuss)、解决 (Solve)

  • 识别 (Identify)： 实际问题是什么？（不是症状，而是根因）用一句话陈述。
  • 讨论 (Discuss)： 相关事实 + 不同观点。限定时间。当讨论开始重复时，立即停止。
  • 解决 (Solve)： 一个负责人。一个行动。一个截止日期。记录在待办事项列表中。

反模式：

  • “我们线下讨论” —— 大多数被移至线下的事项永远无法解决

  • 只讨论不决定 —— 没有行动项的精彩讨论是浪费时间

  • 重新讨论已决议的问题 —— 一旦解决，即从列表中移除。除非有新信息，否则不再重启。

问题列表 (Issues List)： 一个持续更新、按优先级排序的所有未解决问题列表。由领导团队所有。每周回顾并精简。如果一个问题在列表中出现 3 次以上会议且未被讨论，那么它要么不是真正的问题，要么是太可怕而不敢面对——两者都值得关注。

5. 重点目标 (Rocks, 90天优先级)

Rocks 是每个人在接下来的 90 天内必须完成的 3–7 件最重要的事情。它们不是工作职责，而是能推动公司前进的事项。

为什么是 90 天？ 足够长，可以取得实质性进展；足够短，能保持真实感。

Rock 规则：

  • 每人：最多 3–7 个 Rock。超过 7 个，则没有一个能完成。

  • 公司级 Rock（共同优先级）：领导团队设定 3–7 个。

  • 每个 Rock 都是二元的：完成了或没完成。没有“完成 60%”这种说法。

  • 在季度规划会上设定。每周回顾（是否在正轨）。

糟糕的 Rock： “优化我们的销售流程”
优秀的 Rock： “在 3 月 31 日前实施 Salesforce CRM，包含完整的管线阶段和每周报告”

Rock vs. 待办事项： 待办事项只需一次行动；Rock 需要 90 天的持续努力。

6. 沟通频率 (Communication Cadence)

谁在何时通过何种方式获取什么信息。

| 受众 | 内容 | 时间 | 形式 |
|----------|------|------|--------|
| 全体员工 | 公司更新 | 每月 | 书面 + 问答 |
| 全体员工 | 季度结果 + 下阶段优先级 | 每季度 | 全员大会 (All-hands) |
| 领导团队 | 计分卡 | | |
| 目标 | 内容 | 频率 | 形式 |
| :--- | :--- | :--- | :--- |
| 董事会 | 公司业绩 | 每月 | 董事会备忘录 |
| 投资者 | 关键指标 + 叙述 | 每月或每季度 | 投资者更新 |
| 客户 | 产品更新 | 每个版本 | 版本发布说明 |

默认原则： 如果你在犹豫是否要在内部共享某项信息，那就共享它。在公司内部，沟通不足的成本永远高于沟通过度。

---

操作系统选择

完整对比请参阅 references/os-comparison.md。快速指南如下：

| 如果你是... | 考虑选择... |
|---------------|-------------|
| 10–250 人规模、创始人领导、处于运营混乱状态的公司 | EOS / Traction |
| 有雄心增长、需要严谨战略传导的公司 | Scaling Up |
| 技术公司、工程文化、假设驱动 | OKR-native |
| 去中心化、扁平化、高度自治 | Holacracy（仅当你足够耐心时） |
| 以上都不太合适 | 定制混合模式 |

---

实施路线图

不要一次性实施所有内容。完整 90 天计划请参阅 references/implementation-guide.md。

快速启动（前 30 天）：
1. 构建职责图（1 场工作坊，2 小时）
2. 定义 5–10 个每周计分卡指标（领导团队达成一致，1 小时）
3. 开始每周 L10 会议（无需准备 —— 直接开始）

仅这三项带来的协调提升，就将超过大多数公司一年的成效。

---

常见失败模式

部分实施： “我们执行 OKR，但跳过了每周检查。” 半套操作系统比没有更糟糕 —— 它创造了没有问责制的“形式主义”。

会议疲劳： 在现有会议基础上增加全套节奏。应从“替换”会议开始，而不是“增加”会议。

指标过载： 因为“都很重要”而一开始就设定 30 个 KPI。请从 5 个开始，在节奏稳定后再增加。

目标（Rock）膨胀： 因为“ everything are priorities”而为每人设定 12 个目标。当所有事情都是优先级时，就没有优先级。硬上限：7 个。

领导层不执行： 领导团队缺席 L10 会议或不遵循 IDS 流程。操作系统反映了领导层对它的重视程度。如果领导层不认真对待，没人会认真。

年度计划缺乏季度回顾： 设定年度目标后直到年底才检查。季度是任何有意义目标的最低回顾周期。

---

与 C-Suite 的集成

公司操作系统是连接组织各部分的组织纤维。所有其他角色都依赖于它：

| C-Suite 角色 | 对 OS 的依赖 |
|-------------|---------------|
| CEO | 设定愿景，并将其转化为一年计划和目标 (Rocks) |
| COO | 负责会议节奏和问题解决频率 |
| CFO | 负责计分卡中的财务指标 |
| CTO | 负责工程目标和技术计分卡指标 |
| CHRO | 负责计分卡中的人力指标（流失率、招聘速度） |
| 文化架构师 | 将文化仪式融入会议节奏 |
| 战略对齐引擎 | 验证团队目标是否由公司目标传导而来 |

---

操作系统关键自测问题

  • “如果我询问五个不同的团队负责人本季度公司的前三大优先级是什么，他们的答案是否一致？”
  • “上周领导层会议中提出的最重要问题是什么？解决了还是依然悬而未决？”
  • “能否列出一个指标，让我们在周五就能判断本周是否表现良好？我们是否在追踪它？”
  • “谁负责客户流失？你能否毫不犹豫地叫出那个人的名字？”
  • “我们上一次更新职责图是什么时候？”

详细参考

  • references/o
  • s-comparison.md — EOS vs Scaling Up vs OKRs vs Holacracy vs 混合模式
  • references/implementation-guide.md — 90 天实施计划