Software Development as a Wicked Problem

评分: ★★★★★

软件工程领域的深度反思：为什么大规模软件开发本质上是一个"恶劣问题"（wicked problem），以及为何解决方案往往不在技术层面，而在人际层面。

核心内容

作者引用了1973年 Horst Rittel 和 Melvin Webber 在 Policy Sciences 期刊上的论文，介绍了"恶劣问题"的10个特征，并将这些特征映射到软件开发项目中：

1. 没有唯一正确的定义 — 冲突的描述取决于提问者：是企业权力游戏还是标准化报表？
2. 没有停止规则 — 数据仓库永远不会"完成"，它随用户需求持续演进。
3. 解决方案不是对/错，而是好/坏 — 数据库设计没有"正确"或"错误"，只有更好或更差。
4. 没有即时的或最终的测试 — 没有客观的"正确答案"。
5. 每个解决方案都是"一次性操作" — 没有试错机会，每次尝试都意义重大。
6. 解空间不可枚举 — 原则上可能的设计方案数量庞大。
7. 每个恶劣问题本质上都独一无二 — 每个数据仓库都是特殊的。
8. 每个恶劣问题都可以被视为另一个问题的症状 — 根本上是组织变革问题。
9. 同一偏差可以用多种方式解释 — 解释的选择决定了解决方案的性质。
10. 规划者没有犯错的权利 — 数据库设计者最终要为设计决策的后果负责。

方法论不是答案

作者引用 Robert Glass 的《软件工程的事实与谬误》指出：项目延期和超预算的两大原因是估算能力差和需求不稳定——两者都与"恶劣性"相关。

瀑布模型（1970年 Winston Royce 最初提出，比后来的漫画版更精细，包含迭代反馈）和敏捷宣言（2001年）都试图解决这些问题，但敏捷的脆弱性在于：组织可以轻易忽略使其成功的原则（例如实施管理层强加的截止日期而非协商的截止日期）。

"敏捷宣言强调的 essential truth：复杂软件项目的成功取决于基于信任的沟通。"

IBIS 方法：管理恶劣问题

作者推荐使用 Issue-Based Information System (IBIS) 可视化框架管理恶劣问题。使用三种节点类型：

• 问题 (Questions) — 捕捉正在讨论的问题
• 想法 (Ideas) — 对问题的响应
• 论点 (Arguments) — 支持和反对想法的论据

作者在真实的数据仓库会议中使用了 IBIS，将热化的讨论客观化，将意见与持有者分离，最终达成共识。

"The problem is not truth, the problem is trust." — Heinz von Foerster

关键洞见

软件开发是一个恶劣问题，需要利益相关者协调对产品应该做什么和如何构建的不同看法。作者认为：

• 方法论（瀑布、敏捷、Scrum、Kanban）本身不是答案
• IBIS 只是一个框架，核心是管理恶劣问题的心态
• 要理解利益相关者之间的实质性分歧，找到共同点
• 信任是沟通的前提，沟通是管理恶劣性的关键

原文 →