# 企业实践深度映射

本文件将 Google、Amazon、华为、字节跳动四家企业的软件项目管理实践，按维度映射到工作流规则和子工作流步骤。

## Google — 设计评审与代码质量

### 核心实践

| 实践 | 内容 | 适用条件 |
|------|------|---------|
| **Design Doc** | 任何非平凡功能实现前，必须撰写设计文档（1~3 页），包含目标、方案、替代方案、风险 | 技术选型、架构设计阶段 |
| **Code Review** | 所有代码变更必须至少 1 人审查，核心模块需 2 人； reviewer 不只是看代码对不对，更要看设计是否合理 | 开发实现阶段 |
| **OKR 对齐** | 项目目标用 OKR 格式定义，确保可衡量（Objective 有方向，Key Results 有数字） | 立项与目标定义阶段 |
| **Blameless Postmortem** | 事故复盘不追责个人，聚焦流程改进；每次复盘产出可执行的改进项 | 维护与演进阶段 |

### 映射到子工作流

| 子工作流 | 映射点 | 具体规则 |
|---------|--------|---------|
| 立项（initiation） | 目标定义 | 目标必须用"方向 + 量化指标"格式，参考 OKR 的 Key Results 写法 |
| 调研（research） | 技术调研 | 调研结论必须覆盖"替代方案"，不能只调研一条路线 |
| 架构设计（architecture） | 概要设计 | 架构文档必须包含：目标、方案、替代方案、风险、非功能需求覆盖 — 即 Design Doc 的最小结构 |
| 架构设计（architecture） | 技术评审 | 评审必须包含至少 1 个独立 reviewer，核心模块需 2 个 |
| 开发（development） | Code Review | Review 意见必须逐条回复（采纳/拒绝+理由），遗留项 = 0 才能通过 G6 |
| 开发（development） | 集成验证 | 合并前必须通过全部自动化测试 |
| 维护（maintenance） | 复盘 | 复盘必须包含：时间线、根因分析、改进项、负责人、截止日期 |

### 引用来源

- Google Engineering Practices Documentation: https://google.github.io/eng-practices/
- Software Engineering at Google (O'Reilly, 2020)

---

## Amazon — 逆向工作与深度文档

### 核心实践

| 实践 | 内容 | 适用条件 |
|------|------|---------|
| **6-Pager / Narrative** | 重大决策用 6 页以内结构化文档论证，不用 PPT；结构为：背景、问题、方案、收益、风险、时间线 | 技术选型、架构设计阶段 |
| **Working Backwards (PR/FAQ)** | 从用户视角写"新闻稿"和"常见问题"，先定义用户价值再定义技术方案 | 立项与目标定义阶段 |
| **Bias for Action** | 在 70% 信息时就可以决策，不必等到 100%；决策可逆时快速推进，不可逆时深度论证 | 全阶段通用 |
| **Bar Raiser** | 招聘和评审引入独立第三方（Bar Raiser），确保标准不因团队压力降低 | 技术评审、验收阶段 |

### 映射到子工作流

| 子工作流 | 映射点 | 具体规则 |
|---------|--------|---------|
| 立项（initiation） | 目标定义 | 必须包含"用户价值陈述"（从用户视角描述项目成功后的样子）和"常见问题"（预期的质疑和回答） |
| 立项（initiation） | 范围边界 | "不做什么"列表必须包含至少 1 条"看起来应该做但决定不做"的事项 |
| 技术选型（selection） | 方案论证 | 选型文档必须包含：背景、问题、方案对比、收益分析、风险评估、时间线 |
| 调研（research） | 信息充分度 | 调研深度按决策可逆性调节：可逆决策（框架选择、工具切换）用 70% 信息即可推进；不可逆决策（数据模型、核心 API）需 90%+ 信息 |
| 架构设计（architecture） | 评审 | 评审引入至少 1 位项目外部的独立 reviewer |
| 版本发布（release） | 发布决策 | 发布决策用"可逆性"分类：可逆发布（灰度/回滚容易）快速推进；不可逆发布（数据迁移/Schema 变更）深度论证 |

### 引用来源

- Working Backwards: Insights, Stories, and Secrets from Inside Amazon (St. Martin's Press, 2021)
- Amazon's "6-Pager" practice: widely reported in business press

---

## 华为 — 门控治理与自我批判

### 核心实践

| 实践 | 内容 | 适用条件 |
|------|------|---------|
| **IPD 门控** | 每个阶段有正式的 TR（Technical Review）门控点，门控未通过不得进入下一阶段；门控有量化评分 | 全阶段，strict profile |
| **蓝军机制** | 重要决策引入"蓝军"角色，专门挑战方案的假设和漏洞 | 技术选型、架构设计阶段 |
| **自我批判** | 定期组织团队复盘，要求每个人提出自己的不足和改进计划 | 维护与演进阶段 |
| **让听得见炮声的人呼唤炮火** | 一线人员有权根据实际情况调整执行方案，不需要层层上报 | 开发实现、运营阶段 |

### 映射到子工作流

| 子工作流 | 映射点 | 具体规则 |
|---------|--------|---------|
| 全阶段 | Gate 检查 | strict profile 下每个 Gate 需要量化评分（0~5 分），≥3 分通过，<3 分阻塞；standard profile 下用通过/未通过/有条件通过 |
| 技术选型（selection） | 蓝军审查 | 选型阶段必须指定 1 人担任"蓝军"，负责列举方案的风险和失败场景 |
| 架构设计（architecture） | 蓝军审查 | 架构评审中，蓝军必须提出至少 3 个"如果...会怎样"的挑战问题 |
| 开发（development） | 执行自主权 | 开发阶段遇到技术方案偏差时，开发人员可以在不改变架构意图的前提下调整实现方案，记录在决策日志中即可 |
| 运营（operations） | 反馈闭环 | 运营阶段发现的问题，必须在 48 小时内记录到问题清单并分配处理人 |
| 维护（maintenance） | 自我批判 | 复盘必须包含"自己做得不好的 3 件事"和对应的改进计划 |

### 引用来源

- 华为 IPD（集成产品开发）流程：公开资料广泛记载
- 华为自我批判文化：《华为基本法》及任正非讲话

---

## 字节跳动 — OKR 驱动与数据验证

### 核心实践

| 实践 | 内容 | 适用条件 |
|------|------|---------|
| **OKR 全员公开** | 公司所有 OKR 公开透明，任何人可以看到任何人的目标和对齐关系 | 立项与目标定义阶段 |
| **A/B Test 验证** | 功能上线前必须通过 A/B 测试验证效果，用数据决策而不是主观判断 | 测试、运营阶段 |
| **Context not Control** | 管理者提供上下文信息而非微观控制；团队成员在理解上下文后自主决策 | 全阶段通用 |
| **坦诚清晰** | 信息最短路径传递，减少层级过滤；鼓励直接反馈 | 全阶段通用 |

### 映射到子工作流

| 子工作流 | 映射点 | 具体规则 |
|---------|--------|---------|
| 立项（initiation） | 目标定义 | 项目目标必须能向上追溯到上级目标（对齐），Key Results 必须有基线数据和目标数据 |
| 立项（initiation） | 透明度 | 项目目标、范围、进度对项目所有成员可见（对应 workflow 的统一事实源原则） |
| 调研（research） | 数据驱动 | 调研结论必须包含可量化的数据点，不接受纯定性结论 |
| 架构设计（architecture） | Context 传递 | 架构文档必须包含"为什么这样设计"（决策上下文），不只是"设计成什么样" |
| 开发（development） | 自主决策 | 开发人员在理解架构上下文后，可以在实现层面自主决策，只需记录决策 |
| 测试（testing） | 数据验证 | 测试报告必须包含量化结果（通过率、覆盖率、性能数据），不接受"测试通过了" |
| 运营（operations） | A/B 验证 | 功能上线后，运营数据必须与上线前基线对比，量化改进效果 |

### 引用来源

- 字节跳动 OKR 实践：公开报道及飞书 OKR 产品文档
- Context not Control: 字节跳动管理理念，广泛报道

---

## 通用维度汇总

四家企业的实践按维度交叉映射：

| 维度 | Google | Amazon | 华为 | 字节 |
|------|--------|--------|------|------|
| **目标定义** | OKR 对齐 | Working Backwards | IPD 目标分解 | OKR 公开透明 |
| **方案论证** | Design Doc | 6-Pager | 蓝军挑战 | Context 传递 |
| **质量门控** | Code Review | Bar Raiser | IPD TR 门控 | 数据验证 |
| **决策速度** | 审慎 | 70% 信息决策 | 集中决策 | 快速迭代 |
| **复盘改进** | Blameless Postmortem | Working Backwards 验证 | 自我批判 | A/B 验证 |

## 与原 6 条通用经验的关系

本文件替代了原有的 6 条通用经验（单一真实来源、阶段门禁、证据驱动、决策留痕、风险前置、持续改进）。原 6 条规则仍然有效，现在有了更具体的企业实践来源支撑：
- 单一真实来源 → 字节"坦诚清晰"、Google 统一事实源
- 阶段门禁 → 华为 IPD 门控、Google Gate
- 证据驱动 → 字节 A/B 验证、Google Code Review
- 决策留痕 → Amazon 6-Pager、Google Design Doc
- 风险前置 → 华为蓝军机制、Amazon 风险评估
- 持续改进 → Google Postmortem、华为自我批判、字节 A/B 验证