60年设计经验的总结：Frederick Brooks 告诉你什么是真正的设计
摘要：Frederick P. Brooks 是《人月神话》的作者，IBM System/360 和 OS/360 的项目经理。在《The Design of Design》中，他跨越计算机架构、软件、建筑、书籍、组织五个领域，分享了60年的设计经验。本文提炼了书中核心理念和实用建议，帮助工程师、架构师和项目管理者重新思考"设计"这件事。
一、设计到底是什么？
Brooks 引用 Dorothy Sayers 在《The Mind of the Maker》这本书中的框架，将创造过程分为三个层面：
| 层面 | 英文 | 说明 |
|---|---|---|
| 理念 | Idea | 心智中的概念构建 |
| 实现 | Energy / Implementation | 在真实媒介中的落地 |
| 交互 | Interaction | 与用户的真实互动 |
莫扎特在回复父亲关于歌剧进度时曾说："所有东西都已经创作完了，只是还没写下来。"
但对我们大多数人来说，只有在实现过程中，想法的缺陷才会暴露。
二、理性模型：工程师的天然陷阱
工程师天然倾向于将设计理解为这样一个过程：
目标 → 需求 → 约束 → 设计树 → 搜索 → 最优解这就是所谓的理性模型（Rational Model）。
但它错在哪里？
Brooks 给出了几个致命缺陷：
markdown
❌ 我们开始时并不知道真正的目标
→ 最难的是决定"设计什么"，而非"如何设计"
❌ 设计树不是预先可知的
→ 是在设计过程中边做边发现的
❌ 需求会不断演化
→ 一个简单问题"客人的外套放哪里"可能颠覆整个方案
❌ 约束也会变
→ 设计到一半，环境变了、技术变了、规范变了引用建筑师 Donald Schön 的话：
"设计师塑造情境，情境也会'回话'。在设计过程中，设计师必须进行'行动中的反思'。"
三、Co-Evolution Model：更好的过程模型
既然理性模型不成立，Brooks 推荐协同演化模型（Co-Evolution Model）：
信息交换
演化
演化
问题空间 Problem Space
解决方案空间 Solution Space
问题理解
方案发展
核心洞察：问题理解和方案发展是同时演化的，不是先有需求、后有设计。
四、约束是朋友，不是敌人
"Form is liberating."
Brooks 用多个例子证明：约束不是限制，而是创造的催化剂。
| 设计师 | 约束 | 产出 |
|---|---|---|
| Bach | 给自己设 BACH 音型约束 | 一系列杰作 |
| Michelangelo | 被废弃的有裂缝的大理石 | 大卫像 |
| Wren | 伦敦教堂的朝向约束 | 27座风格各异的教堂 |
实用建议：
python
# 设计开始前，列出所有约束并分类
constraints = {
"real": ["building codes", "budget", "site setback"],
"obsolete": ["previous tech assumptions"],
"misperceived": ["specified topology when what mattered was reliability"],
"artificial": ["self-imposed for creativity"]
}识别约束
| 类型 | 说明 | 对待方式 |
|---|---|---|
| 真实约束 | 不可改变的现实（物理定律、法律、预算） | 必须遵守，设计围绕它展开 |
| 过时约束 | 曾经真实，但技术已变 | 必须识别并抛弃 |
| 误以为的约束 | 假设存在，实际不存在 | 必须识别并挑战 |
| 自设的人工约束 | 为了激发创造力而主动添加 | 可以自由使用，也可以随时取消 |
对约束进行不断提问
| 问题 | 有效约束的回答 | 无效/危险约束的回答 |
|---|---|---|
| 1. 这个约束如果消失，设计会变成什么？ | 会有本质不同 | 没什么变化 |
| 2. 违反这个约束最可能的后果是什么？ | 具体的风险 | "项目会被取消"/"老板会不高兴"（抽象恐吓） |
| 3. 这个约束是谁提出的？ | 有直接责任的人（用户/法律/物理） | "公司规定"/"以前就是这样" |
| 4. 这个约束服务于什么目的？ | 清晰的目的陈述 | 说不清楚或循环论证 |
| 5. 可以换一种手段达到同样目的吗？ | 可以（说明约束是手段，不是目标） | 不可以（警惕） |
五、预算资源：比钱更重要的是什么？
每个设计都有一项稀缺资源需要精打细算。它不一定是钱。
| 设计场景 | 预算资源 |
|---|---|
| 海边别墅 | 临海面的英寸数 |
| 航天器/背包 | 盎司的载荷 |
| 计算机架构 | 控制寄存器中的位、指令格式中的位、内存带宽 |
| OS/360 内核 | 内存空间（后来变成了磁盘访问次数） |
| 芯片设计 | 引脚数 → 后来变成功耗 |
"如果你想让团队设计有概念完整性：显式命名预算资源、公开追踪、严格控制。"
六、团队设计与概念完整性
现代设计几乎都是团队设计，但概念完整性最容易在这里丢失。
如何保持概念完整性？
yaml
方案1: 任命一位系统架构师
- 必须有最终决定权
- 代表用户
- 关注概念完整性
方案2: 用户界面由一个人控制
- 例子：Google 的 Marissa Mayer 控制首页格式
方案3: 两人团队是神奇的
- 结对编程的研究表明：错误率显著下降，原创想法翻倍设计概念验证
markdown
# 设计概念陈述书
## 1. 一句话概念
- [用一句话说明这个设计解决什么问题]
## 2. 核心用户
- [谁是主要用户？他们的特征？]
## 3. 核心场景（Top 3）
- 场景1：[描述]
- 场景2：[描述]
- 场景3：[描述]
## 4. 核心概念模型
- [用户理解这个系统所需的核心抽象是什么？]
## 5. 正交性声明
- [哪些维度是独立的？]
## 6. 不做什么（同样重要！）
- 功能A：[为什么不做]
- 功能B：[为什么不做]
## 7. 预算资源
- [这个设计的稀缺资源是什么？]
- [如何追踪？]
## 8. 一致性规则
- [贯穿设计的统一规则是什么？]
## 9. 示例
- [给出 3 个"正确的用法"示例]
## 10. 反例
- [给出 3 个"违背概念"的用法示例]
版本: 1.0
所有者: [架构师姓名]
日期: [YYYY-MM-DD]设计评审必须跨学科
markdown
- 设计师 × 实现者 × 维护者 × 用户 × 制造商
- 关键是：不同视角看到不同的问题
- 造船厂工头的一句话可能改变整个设计核心建议
七、为什么伟大的设计来自流程之外？
Brooks 观察到一个现象：
| 有粉丝的产品 | 无粉丝的产品 |
|---|---|
| Macintosh | Microsoft Windows |
| UNIX | OS/360 MVS |
| Apple II | IBM PC |
| FORTRAN | COBOL |
有趣的是，所有右列的产品都来自正规产品流程，而左列的明星产品几乎都来自流程之外------小型分离团队、叛逆者、闭门实验室。
流程为什么压抑创新？
markdown
❌ 流程是保守的，它"打的是上一场仗"
❌ 流程追求可预测性，与创新天然冲突
❌ 流程是"否决制"的，每个专家都可以说"不"
❌ 流程用会议吞噬了设计师的时间但 Brooks 并非反流程：
"对于跟随型产品，流程是有价值的。但对于真正的创新，你必须走出流程。"
八、用户模型的铁律
"Better wrong than vague."（错误但具体，胜过模糊）
团队设计中最常见的问题是：每个设计师带着不同的隐性假设在工作。
解决方案
markdown
1. 显式写出用户和使用模型
2. 不知道的数值就"猜"
3. 让整个团队讨论这些假设
4. 把敏感性分析做出来例子：设计校车路线调度软件
python
user_model = {
"school_districts": ["urban", "suburban", "rural"],
"bus_count_range": [5, 50],
"scheduling_frequency": "daily",
"five_year_growth_rate": "+20%", # 猜的
"driver_availability": "constrained" # 猜的
}九、设计师的成长之路
如何培养伟大的设计师？
yaml
教育:
- 在批评中实践（critiqued practice）是唯一的方法
- 不是先上完所有科学课再学设计，而是从第一年开始
组织:
- 建立真正的双轨晋升通道
- 保护设计师不被推上管理岗
- 保护设计师不被日常杂务打扰
个人:
- 主动规划自己的成长
- 大量研究典范设计（exemplars）
- 保持设计日志
- 寻求专家批评Seymour Cray 的榜样
markdown
- CDC 6600 团队"包括清洁工在内 35 人"，远居深山
- Cray 成功后主动脱离 CDC，去大草原创立 Cray Computer
- 成功后再次脱离，去科罗拉多创立 Cray Research
- 他亲自掌控从电路、制冷到编译器的所有层面
- 反复拒绝被推上管理岗位十、一个自练项目
Brooks 推荐的自修练习（来自北卡州立大学设计学院）：
设计一个 1000 平方英尺的家庭住宅
markdown
程序：
- 家庭：父母 + 3岁儿 + 6岁女
- 地块：北弗吉尼亚郊区，临街50英尺，进深70英尺，朝南
- 有树木
要求记录日志：
- 推演更详细的建筑程序
- 识别约束条件和预算资源
- 记录所有决策和理由
- 分析自己的设计轨迹这套练习的价值在于------无论你是软件架构师、硬件工程师还是产品经理，都能在这个小规模任务中演练完整的设计思维。
写在最后
这本书不是一本"快速上手"的手册，而是一位老工程师六十年后的沉思录。
Brooks 最后写道：
"感谢并赞美那位伟大的设计师（Great Designer），祂慷慨地赐给我们创造的媒介、日日的供应和创作的喜悦。"
如果你正在设计一个复杂系统------无论是代码、芯片、建筑还是团队------这本书值得你在书架上留一个位置。
扩展阅读
| 书名 | 作者 | 要点 |
|---|---|---|
| 《The Mythical Man-Month》 | Brooks | 软件工程、概念完整性、团队组织 |
| 《The Sciences of the Artificial》 | Herbert Simon | 理性模型的原典 |
| 《The Reflective Practitioner》 | Donald Schön | 行动中的反思 |
| 《The Cathedral and the Bazaar》 | Eric Raymond | 开源 vs 闭源设计过程 |
| 《Peopleware》 | DeMarco & Lister | 影响设计质量的非技术因素 |
💡 本文内容基于 Frederick P. Brooks《The Design of Design: Essays from a Computer Scientist》（2010）。如需精读原书，建议重点关注 Part I（设计的过程模型）、Part III（设计视角）和 Part V（伟大的设计师）。