软件工程的13条“定律”：从Hyrum定律到康威定律，再到Zawinski定律
每周跟踪AI热点新闻动向和震撼发展 想要探索生成式人工智能的前沿进展吗？订阅我们的简报，深入解析最新的技术突破、实际应用案例和未来的趋势。与全球数同行一同，从行业内部的深度分析和实用指南中受益。不要错过这个机会，成为AI领域的领跑者。点击订阅，与未来同行！ 订阅：https://rengongzhineng.io/
这些“定律”中，有的非常著名，有的则相当小众，但对于工程师和管理者来说，每一条都极具参考价值。以下逐条介绍这13条定律、其含义、相关漫画以及为何它们对工程管理至关重要。
1. 帕金森定律（Parkinson’s Law）
内容： 工作会扩展到你给它分配的所有时间里。
为何重要： 用于解释设置“假”截止日期的常见做法。虽然有时候能提高效率，但若滥用，会带来过度压力。帕金森定律是时间管理与项目预估中不可忽视的心理模型。
2. 霍夫斯塔特定律（Hofstadter’s Law）
内容：即使考虑到霍夫斯塔特定律，事情仍然会比预期更花时间。
为何重要： 软件项目几乎总是超时。它提醒管理者应在预估时保持现实主义，而不是仅靠“紧凑计划”驱动进度。
3. 布鲁克斯定律（Brooks’ Law）
内容：向已经延误的软件项目增加人力，只会让项目更晚完成。
为何重要： 人员新增会引入协作与知识传递成本，反而拉慢整体速度。这对临时“救火”式的管理思路是重要警示。
4. 康威定律（Conway’s Law）
内容：系统的结构往往映射其开发组织的沟通结构。
为何重要： 组织结构对架构设计有深远影响。反过来，通过改变团队结构，也可以有意地塑造系统架构（反康威法则）。
5. 康宁汉定律（Cunningham’s Law）
内容：在互联网上，获取正确答案的最好方法是先发一个错误答案。
为何重要： 能有效利用“他人纠错”的心理机制来获得反馈。应用在技术团队中，比如提交“错误”的PR以引发讨论，也是一种快速打破信息瓶颈的方法。
6. 斯特金定律（Sturgeon’s Law）
内容：90%的任何事物都是垃圾。
为何重要： 产品开发中，大部分功能对业务毫无价值。识别和聚焦真正有价值的10%，是高效团队的核心能力。
7. 扎温斯基定律（Zawinski’s Law）
内容：每一个程序最终都会扩展到能读取邮件为止；不能这样扩展的程序将被能做到的程序替代。
为何重要： 揭示了“功能膨胀”的常见趋势，尤其在AI时代，添加聊天机器人、自动摘要等功能变得异常容易，导致产品变得复杂且难以使用。
8. Hyrum定律（Hyrum’s Law）
内容：当API有足够多的用户时，无论文档写了什么，所有可观察的行为都会被某些人依赖。
为何重要： 说明即使是“边缘功能”，也可能形成长期的技术债。产品功能一旦发布，就很难移除，哪怕对大多数人无效。
9. 普莱斯定律（Price’s Law）
内容：在一个团队中，50%的产出来自平方根比例的人。
为何重要： 提醒管理者产出是非线性的。在扩大团队时，仅靠人数增长往往不能线性提升产出。
10. 林格尔曼效应（Ringelmann Effect）
内容：当一个团队的人数增加时，每个人的平均生产力会下降。
为何重要： 团队协作越复杂，成员的积极性与协同效率越容易丧失。小团队通常更具高效执行力。
11. 古德哈特定律（Goodhart’s Law）
内容：一旦某项指标成为目标，它就不再是一个好的衡量标准。
为何重要： 所有绩效指标（如PR数量、交付速率）都可以被“游戏化”，从而扭曲原本的激励作用。
12. 吉尔布定律（Gilb’s Law）
内容：任何需要量化的事物，总能以某种方式被测量——哪怕这种方式并不完美。
为何重要： 是对古德哈特定律的反平衡。尽管度量不完美，也比完全不测量更有益。通过持续迭代改进度量方式，能不断优化团队与产品。
13. 墨菲定律（Murphy’s Law）
内容：凡是可能出错的事情，最终一定会出错。
为何重要： 在软件开发中，低概率错误一旦出现，往往是灾难性的。这条定律提醒团队做好边界条件与错误处理，不能仅依赖“不会发生”的心理预设。
结语
这些“定律”虽非严格意义上的科学定律，但作为认知模型，它们帮助工程团队更理性地面对协作、计划、架构设计与决策问题。掌握这些“定律”，能有效提升工程经理和团队的工作效能与应变能力。对于想了解更多内容的管理者，也可进一步探索相关实践社区或加入专业学习会，共同提升软件工程管理能力。