康威定律
设计系统的组织，其产生的设计等价于该组织的沟通结构。——梅尔文·康威（Melvin Conway），1967
定义
康威定律（Conway’s Law）由计算机科学家梅尔文·康威于 1967 年提出：组织设计的系统，其结构必然镜像该组织的沟通结构。换言之，如果一个组织有 4 个团队分别负责编译器的前端、后端、优化器和运行时，那么编译器必然会有 4 个对应的中间表示层。
这条定律最初发表在 Datamation 杂志上，后被 Fred Brooks 在《人月神话》中引用而广泛传播。
核心机制
为什么组织结构会”编码”进产品？
- 信息流决定架构边界：团队之间的沟通成本直接决定了模块之间的接口设计。沟通频繁的团队产出紧耦合模块，沟通稀疏的团队产出松耦合模块。
- 决策权的分布：谁有权力做技术决策，决定了系统中哪些部分会被优先设计、哪些会被忽略。
- 激励机制的传导：如果团队被按行数代码考核，系统必然充斥冗余代码；如果被按交付速度考核，技术债务必然堆积。
反向推导
康威定律的逆用同样成立：从产品的缺陷可以反向推导组织的缺陷。例如：
- 产品中多个模块重复实现相同功能 → 组织中团队之间缺乏沟通
- 产品界面风格不统一 → 组织中设计和开发分属不同部门且缺乏协作
- 产品功能频繁”改元” → 组织中决策权过于集中且缺乏用户验证机制
不同素材中的观点
《置身钉内》中的案例（来源：2026-06-18-dingtalk-one-product-thinking）
钉钉 AI 项目 ONE 的产品缺陷——定位摇摆、决策随意、短视迭代、缺乏同理心——并非偶然。它们恰恰映射了项目所处的组织环境：
- 高压 + 控制 → 产品中”已读焦虑”功能（管理者监控员工的工具化思维）
- 一言堂 → 产品方向频繁因高层个人偏好改动（LOGO、视觉体系、核心定位不断”改元”）
- 短期产出导向 → “每日一包”制度导致只打磨表层 UI，技术债务越滚越大
原文总结：“一个高压、控制、一言堂、以短期产出为考核导向的团队，最终设计出的产品必然是冰冷、压迫和工具理性的。“
相关概念
- 路径依赖：组织的成功经验形成惯性，进一步强化既有的沟通结构和决策模式
- 逆康威定律（Inverse Conway Maneuver）：有意识地调整组织结构来引导期望的系统架构
实用信息
- 适用场景：产品架构评审、组织变革诊断、技术债务根因分析
- 实操建议：在做产品架构决策前，先审视组织结构是否支持期望的架构；如果组织结构是瓶颈，先调整组织再调整技术
- 延伸阅读：《人月神话》（Fred Brooks）、《Team Topologies》（Matthew Skelton & Manuel Pais）