Engineering Culture

解决什么问题：让"做正确的事"成为团队的默认行为，而不是靠流程强制——避免"流程齐全但团队走捷径"，把工程文化当作 B7 演化的隐性基础设施。

它是什么

工程文化（Engineering Culture） 是一个团队的默认行为模式 + 共享价值观 + 隐性规则——它决定了"在没人看着的时候，团队会怎么做"：

• 可见的：流程、规范、工具、KPI
• 不可见的：价值观、默契、潜意识反应、失败时的第一反应

SE@G 全书的隐含主题就是 Google 的工程文化： "Culture is what you do when nobody is watching." "Sustainable software engineering requires both technical practices and a culture that supports them."

控制论 Ch 18 自适应系统的设计哲学： "自适应系统不是单靠控制律，是靠'系统在遇到未知时如何反应'的设计"——这正是文化——文化决定系统（团队）在遇到未知时的默认反应。

IDDD Ch 14 强调文化是 DDD 落地的关键： "The domain model lives in the heads of the team, not in the code—the code is a projection of the shared understanding."——领域模型的健康 = 团队文化的健康。

EDM Ch 17 自然演化的应用前提是文化： "架构顺应业务演化"——这要求文化允许实验、允许失败、允许改变方向。

V2 视角（V2.7 B7 段 5）：文化是 B7 演化的隐性基础设施——流程和工具是显性的，文化是隐性的；流程可以被绕过，文化决定是否被绕过。

关键属性

属性	含义	软件工程实例
默认行为	没人看着时怎么做	是否写测试 / 是否做 review / 是否更新文档
共享价值观	团队共识	"质量第一" / "数据驱动" / "用户体验优先"
隐性规则	不写在文档但被遵守	"上线前必须经过 staging" / "故障必须做 postmortem"
失败反应	遇到失败时的第一反应	blameless postmortem / 找替罪羊
学习倾向	鼓励还是压制学习	"我不知道" / "我知道"
可实验性	是否允许低成本试错	创新预算 / 失败容忍度
跨边界	跨团队协作的默认	"我们一起做" / "这是别人的事"
演化性	文化自身能否演化	"我们一直这样" / "我们试一下新做法"

怎么用

场景 1：识别文化的健康度

5 个标志：

1. 故障后第一反应是找人背锅，还是找系统根因？
   → 找根因 = 健康；找人 = 不健康

2. 新人加入后，是否能快速融入并提出改进？
   → 能 = 健康；新人沉默 = 不健康

3. 团队是否敢说"我们之前的决策错了"？
   → 能 = 健康；坚持旧决策 = 不健康

4. 跨团队协作是否需要"老板协调"？
   → 不需要 = 健康；需要 = 不健康

5. 团队是否在遇到新问题时，倾向于尝试新方法？
   → 是 = 健康；倾向于守旧 = 不健康

场景 2：工程文化的核心维度

维度 1：blameless culture（无指责文化）

规则：故障复盘只追系统根因，不追个人责任
好处：故障暴露率上升 / 隐藏问题减少 / 团队敢于试错
反例：追责文化 → 故障被隐藏 → 真错时崩盘

依据：SRE Book Ch 11 blameless postmortem

维度 2：data-driven culture（数据驱动文化）

规则：决策基于数据，不是基于权威或直觉
好处：决策可验证 / 减少争论 / 学习闭环
反例：拍脑袋决策 → 反复争论 → 决策质量低

依据：L4 iteration 数据驱动 + B5 反馈

维度 3：learning culture（学习文化）

规则：失败 = 学习机会；新知识 = 必须共享
好处：团队能力持续上升 / 抗脆弱
反例：知识集中在少数人 / 没人愿意分享

依据：Learning Org + Senge 五项修炼

维度 4：quality culture（质量文化）

规则：质量是每个人的责任，不只是 QA 的责任
好处：测试覆盖上升 / 技术债减少 / 长期演化能力提升
反例：QA 兜底 → 开发者不重视质量

依据：SE@G 全书 / XP 实践

维度 5：evolution culture（演化文化）

规则：业务变了，架构必须跟着变；不演化 = 死亡
好处：架构保持可演化性 / 不积累技术债
反例："我们一直这样" → 架构僵化

依据：V2 B7 自然演化 + EDM Ch 17

场景 3：文化的反模式

反模式 1：KPI 唯一导向文化

症状：只看结果指标，不看过程指标
后果：团队走捷径 / 不学习 / 长期能力下降
例：把"上线数量"作为唯一 KPI → 团队倾向于"上线烂代码"

反模式 2：英雄主义文化

症状：关键故障靠"某个人"解决，并被表彰
后果：知识集中在少数人 / 单点故障（人）
例：表彰"故障处理英雄" → 团队不分享知识

反模式 3：零故障文化

症状：把"零故障"作为目标
后果：故障被隐藏 → 真错时崩盘
例：把"故障数"作为 KPI → 团队隐藏故障

反模式 4：加班文化

症状：把加班作为"敬业"标志
后果：长期能力下降 / 团队流失 / 错误率上升
例：表彰"周末加班" → 团队倾向于低效工作

反模式 5：权威文化

症状：决策完全依赖权威（资深 / 老板）
后果：决策质量低 / 团队不思考 / 不敢挑战
例：架构决策完全靠"架构师" → 团队不参与架构

场景 4：建设文化的工程实践

实践 1：以身作则（Leader sets the tone）

- leader 在故障后做 blameless postmortem，团队跟随
- leader 在决策时说"我不确定"，团队敢说"我不知道"
- leader 跨团队协作，团队也会协作

实践 2：仪式化（Make it routine）

- 每周技术分享
- 每月 retro
- 每季度一次"团队健康度"自评
- 每次故障必须做 postmortem
- 每次重大决策必须有 ADR

实践 3：把文化写入流程

- Code review 流程化 → 知识共享文化
- postmortem 流程化 → 学习文化
- ADR 流程化 → 决策文化
- 故障演练流程化 → 抗脆弱文化

实践 4：奖励正确行为

- 表彰 blameless postmortem 的团队（不是"故障处理英雄"）
- 表彰跨团队协作
- 表彰知识共享（写文档 / 做分享）
- 表彰承认错误并学习的团队

常见误区

1. "文化 = 流程" ——错。流程是显性规则，文化是隐性规则——流程可以被绕过，文化决定是否被绕过
2. "文化 = KPI" ——错。KPI 反映结果，文化决定团队怎么达成结果——只看 KPI = 走捷径
3. "文化 = 老板的事" ——错。文化是每个团队成员共同创造的——leader 影响，但不能强制
4. "文化可以一次性建好" ——错。文化是持续演化的——业务变了，文化必须跟着变
5. "文化 = 价值观口号" ——错。文化是行为，不是口号——"用户第一"是口号，"上线前必须做可用性测试"是文化

关键洞察

工程文化 = 团队的默认行为模式 + 共享价值观 + 隐性规则。文化是 B7 演化的隐性基础设施——流程和工具是显性的，文化是隐性的；流程可以被绕过，文化决定是否被绕过。 5 个核心维度：blameless / data-driven / learning / quality / evolution——五个共同构成健康的工程文化。 关键纪律：leader 以身作则 + 仪式化 + 把文化写入流程 + 奖励正确行为——四件套缺一不可。 SE@G 全书 + IDDD Ch 14 + EDM Ch 17 + V2 B7——四源共同指向：工程文化是演化的前提，不是结果。

相关链接

• Conway——文化的结构维度
• Team Topology——文化的团队落地
• Learning Org——文化的学习维度
• [V3 涌现之时] · 演化——文化的演化视角
• [V3 涌现作为] · 反馈——文化的反馈机制
• SE@G 全书——Google 工程文化范本
• IDDD Ch 14——DDD 团队文化