# 05 再谈帕金森定律

英国作家诺斯古德·帕金森(C．Northcote Parkinson)于 1954 年引入了一个概念，认为工作会自动膨胀，占满一个人可以用的所有时间，这被称为帕金森定律。

倘若你不知道其实很少有管理者接受过管理方面的正规培训，你可能会错以为他们都是科班出身，在学校就学过帕金森定律及其分支理论。即使管理者对管理一无所知，他们也极为认同帕金森定律这一针对员工及其态度进行管理的公理。定律为他们提供了强有力的证据，只有设定不可能完成的交付日期，才能保证工作的完成。

### 帕金森定律和牛顿定律

帕金森定律离公理还差得远呢。牛顿定律才是公理，从这个角度看，帕金森定律显然不是。牛顿是一位科学家，他对重力的研究遵循了一系列严格的科学方法。定律的提出经过了严格的验证和测试，并且通过了接下来几个世纪的后续研究。

帕金森不是一名科学家，他没有收集数据，甚至可能根本就不知道什么是统计推论规则。帕金森是一位喜剧作家，他的“定律”被接受并非因为它是真理，而是因为它有趣。

当然，帕金森定律还是有真实成分的，要不然就不会那么有趣了。帕金森说，他的定律是通过观察一个虚拟的政府官僚机构得出的，一些人认为原型就是英国邮局。

官僚机构很容易产生这样的问题，因为员工很少从工作中收获满足感。但你很可能不在官僚机构工作，就算你在，你可能也花了不少力气保证你的员工不这么做，否则他们不会有任何产出。结果就是大家都可能从工作中得到莫大满足。因此，一个简单的事实值得澄清：

帕金森定律基本不可能运用到你的工作中

生命苦短，不能在工作中虚度光阴。只要大家热爱工作，就不可能让一项工作变得遥遥无绝期——这会推迟获得他们向往的满足感。在不需要降低标准、牺牲质量的时候，他们和你一样，期望工作能快点完成。

### 如果经历了我们的见闻，你就不会这样说了

每一位管理者在职业生涯中一定会遇到一个员工不想工作，或者完全达不到质量标准，又或者无法完成工作。对此，帕金森定律管用吗？

在一个健康的工作环境里，要是某人表现欠佳，可能是因为能力不足、缺乏自信，或者无法理解项目中别人的想法和项目目标。通过增加进度压力无助于解决上述问题。一旦某位员工表现出工作低效，对工作质量漠不关心，就是发出了明确的信号，说明这个可怜的家伙快被工作困难给压垮了。他需要的不是更多的压力，而是调换工作，或者跳槽到另一家公司。

即使在极端情况下，依靠某人是唯一的出路，管理者也应该将此作为最后的选择。团队发出的声音会更好，我们见证了一些良好团队的管理者和大家站在一起，共同批评那些不与别人协作的员工。

在随后的几章中，我们会就团队以及怎样促进团队良好的化学反应展开讨论。这里，我们不会讨论什么方法有效，而是讨论什么方法无效：把你的团队成员当做帕金森型的员工是不可能奏效的。这只能消磨他们的意志，让他们失去前进的动力。

### 来自新南威尔士大学的数据

当然，帕金森定律的思维观念并不会因为它不应该存在而消失。要帮助管理者认识到帕金森定律并不适用于大多数员工，方法是通过严格收集得到的数据。（且不提帕金森本人并没有提供任何数据来支撑他的定律，仅仅是花了几百页内容来阐述观点。）

两位备受尊敬昀新南威尔士大学研究员——迈克·劳伦斯和罗斯·杰斐逊在上个世纪 80 年代和 90 年代进行了年度调查。他们按照通行的数据收集标准对正在进行的项目进行了度量。每一年，他们会专注于不同的项目工作方向。1985 年的数据调查结果显示：帕金森定律并不具备普适性。虽然结果不能完全推翻定律，但至少提供了足够的理由来质疑。

劳伦斯和杰斐逊设定的目标是比较各种估算方法给产能带来的影响。他们想证明（或推翻）大众认为的开发人员（调查对象是程序员）会更加努力工作去达成他们自己给出的估算。对他们调研的 103 个项目中的每个项目，劳伦斯和杰斐逊计算出了一个产能的加权度量值( weighted metric)。然后他们将项目按照原始的估算方法进行归类。部分结果参见表 5-1。

表 5-1 估算方法的对应产能（部分结果）

| 工作量估算人   | 平均产能 | 项目个数 |
| -------- | ---- | ---- |
| 仅程序员     | 8.0  | 19   |
| 仅管理人员    | 6.6  | 3    |
| 程序员和管理人员 | 7.8  | 16   |

至少结果证明了大众的观点：相比管理人员的估算，程序员自己给出估算对应的产能会高一点。若二者一起做估算，对应的产能结果处于二者之间。

在同一年调研的 21 个项目中，估算由第三方完成，通常为系统分析师。在这种情况下，程序员的产能持续高于前面提到的由程序员或簪理人员来做估算（见表 5-2）。

表 5-2 估算方法的对应产能（部分结果）

| 工作量估算人   | 平均产能 | 项目个数 |
| -------- | ---- | ---- |
| 仅程序员     | 8.0  | 19   |
| 仅管理人员    | 6.6  | 23   |
| 程序员和管理人员 | 7.8  | 16   |
| 系统分析师    | 9.5  | 21   |

最后一条数据出乎意料，未能证实大众的想法。为什么程序员要更努力工作去达成分析师给出的估算，甚至超过他们自己给出的估算呢？可能我们会觉得这是收集的数据不够准确造成的。但如果你跟我们一样，相信不准确的估算是伤害士气的一个原因，那么其实这些数据并不需要过多解释。系统分析师其实是比程序员或管理人员更好的估算者，他们既了解工作的细节，又不会陷入构建者那种自然的乐观或者老板们通常在政治或经济方面的偏执中。另外，系统分析师通常会有更多的估算经验，因为他们过去做过，而且从中吸取了经验教训，因而能够估算得更加准确。

不准确的估算，或者根本不现实的估算会消磨掉构建者的精力。Capers Jones，以他对开发项目度量的研究成果著名，他这样说道：“当一个项目的时间计划制定得根本毫无道理或不现实，甚至不可能通过加班来达成时，项目团队会变得愤怒和烦躁……他们的士气会跌到谷底。”这种“根本毫无道理或不现实”的计划不管来自于老板还是构建者自己部没啥区别。既然明知不可取胜，人们自然就不会高效地工作了。

在 1985 年劳伦斯一杰斐逊的研究报告中，最后一部分让人尤为吃惊。他们调查的 24 个没有做估算的项目在产能方面远比其他项目强（见表 5-3）：

表 5-3 估算方法的对应产能（全部结果）

| 工作量估算人   | 平均产能 | 项目个数 |
| -------- | ---- | ---- |
| 仅程序员     | 8.0  | 19   |
| 仅管理人员    | 6.6  | 23   |
| 程序员和管理人员 | 7 8  | 16   |
| 系统分析师    | 9.5  | 21   |
| （没有评估）   | 12 0 | 24   |

老板不给任何时间压力（“你们做完了告诉我一声就行。”）的项目产能最高。当然，这并不能说明帕金森定律不适用于程序员，但应该足以让你产生怀疑了吧？

是否在一个项目上采取时间进度压力，应该像是否惩罚你的孩子一样来决定：如果惩罚比较少见，而时间点也能够掌握得恰到好处，惩罚就可能起作用：若需要经常施以惩罚，就说明你自身是有问题的。

### 帕金森主题的变异

只要让帕金森定律变异一点，就能在很多组织中造成惊人的事实：

一个组织的工作如果都忙忙碌碌，就会膨胀以至于占满整个工作日：

在一家公司刚成立时，这种现象就开始了，随着时间的推移问题会变得越来越严重。倘若荷兰东印度公司（1651 年成立时最大的公司）仍然存在，他们的员工可能会花一周 40 小时的时间来填各种表格。大家注意，在这种情况下，帕金森式的行为在于公司而非员工。在第二部分，我们会再讨论这个主题。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://doc.shiker.tech/ren-jian/di-yi-bu-fen-guan-li-ren-li-zi-yuan/05-zai-tan-pa-jin-sen-ding-l.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
