我应该做些什么呢？我应该怎样利用你今天与我共享的这一切？”
“呃，我们要从你的直觉库中挑选一些元素。要从你的‘仓库’里搜索出有用
的管理直觉，简单的办法就是给它一点挑战。所以，我来讲一些无法容忍的事情，
然后问你为什么这些事情是无法容忍的。”
“好，来吧。”
“假设我是你的老板。你告诉我，10 个人工作1 年就可以完成某项工作。但
是对于这个产品，我不能等得太久，所以我给你20 个人，让你在从现在开始的6 个
月之后把产品交给我。”
汤普金斯先生控制不住自己的愤怒：“我会叫你去跳湖。”
“你的直觉告诉你：20 个人工作6 个月与10 个人工作12 个月是不同的。”
“何止是直觉啊。”汤普金斯先生大声说道，“这是毫无疑问的。”
项目管理通俗读物 最后期限 ID2002
77
贾米德博士拿起一本黄色的便笺簿，在上面飞快地画了一幅图。画完以后，他
把便笺簿推给汤普金斯先生，用笔指着上面的图。
“那么也就是说，两倍的人力配置不能在一半的时间里完成同样数量的工
作？”
“绝对不能！”
“这边的产品生产力总量和另一边的不同？”
“完全不同。”
贾米德博士露出一脸的狡猾：“唔。。有多大的不同？”
“什么意思？”
“它们之间有多大的区别？我们举个例子吧，假设10 个人用1 年的时间可以
制造的软件产品是1 000 个某种单位。别担心我现在使用的度量单位，就当它是个
适当的软件度量单位吧。如果10 个人在1 年中可以完成1 000 单位的产品，那么
20 个人—— 假设他们有同样的能力—— 在6 个月里面能开发多少单位的产品？”
“少于1 000。”
“少多少？”
“少很多！”
“很多是多少？”
“非常多。那20 个人会给自己制造麻烦。他们绝对干不了更小的团队在更长的
时间里干的那么多活。”汤普金斯先生有点生气了，“难道你看不出来吗？”
“噢，我能看出来。很明显。我并非不同意你的直觉，韦伯斯特，只是试图让
你量化它而已。这个大团队在6 个月中能完成的工作会少多少？”
汤普金斯先生摆摆手：“一半。或者1／4。我不知道。”
“别开玩笑。”贾米德博士友善地笑着。
“好吧，我想我不知道。我是说，我不能确切地知道。”
“尽管已经知道了两个因素中的一个。”
“为什么你对这个问题有那么大的兴趣？”
“因为你需要知道。人和时间之间的权衡是管理者几乎每天都必须关心的事情，
项目管理通俗读物 最后期限 ID2002
78
你总是在做这种权衡。你是怎么做的？”
“呃，我想，我对此有一种感觉。”
“这种感觉就是你的模型。你看，你已经有了一个模型，但是到目前为止，它
还完全是内在的。它埋藏得如此之深，以至于你想看的时候都找不到。让我们把它
公开出来，让我们在这个模型中再现你的‘感觉’：向团队中添加新员工会对生产率
造成怎样的影响。”
“好。”
“你只管对我说，然后我会把它裁剪成建模程序和模拟程序能够理解的形式。
当你向团队中增加一个人的时候，会发生什么？”
汤普金斯认真考虑了一下。“初期的影响是负面的。”他开始了，“第一天，
这个新来的家伙干不了任何有用的事情。为了学习，他还会占用其他人的时间。所
以，团队的总生产率会受到打击。”
贾米德博士一边听，一边在电脑上建模。
“然后，逐渐地，他成为了团队中的一员。”汤普金斯拿起黄色便笺簿和笔，
飞快地画出了他的概念，“就像这样。”
贾米德博士凝视着这幅图。然后，一阵键盘的敲打和鼠标的点击之后，他将图
中的概念结合进了自己的新模型中。
汤普金斯先生继续说：“不过，如果以前的团队有6 个人，那么新加入一个人
的作用就不如5 个人的团队中加入一个人的作用那么大。所以，我想，可能存在某
种与团队大小相关的损失。团队中的人越多，人与人之间的交流就越多，所以浪费
的时间也就越多。”（译者注：在软件开发过程中，最重要的两种角色无疑是开发者
和测试者。其中，开发者需要更多的交流，所以交流的成本更大；测试者的工作相
对独立，所以交流的成本相对较小。而作为一种智力产品，软件开发中人员之间的
交流成本是软件的主要成本之一。微软公司的典型团队组成是1 名经理、3 名开发
者、5 名测试者，这可以说是深得软件开发之道的团队组成。而如果希望靠增加人
员来提高软件团队的生产力，则无疑是南辕北辙。）
“阐明你的观点。同样的，给我画幅图。”
“好吧，我看看。如果我们把总的生产率看做团队大小的一个函数，” 他一
项目管理通俗读物 最后期限 ID2002
79
边说一边画，“那么，理想的情况应该是45°的斜线。如果保持这条线，就说明每
个新增加的人都与以前的人做出了同样大的贡献。如果是这样，给团队配置两倍的
人就能得到两倍的生产力，而没有交流造成的损失。但是，实际的生产力比理想的
要少，像这样。”
“实际情况与无法达到的理想情况之间的差异就是因为人与人之间的交流所
造成的损失。”
贾米德博士凝视着这幅图：“我明白了。或多或少地，我可以把你的图复制到
模型中来。”他把一根手指放在“实际情况”的曲线上，在图表的中部位置，“告
诉我，当团队的规模有多大时，交流损失就会达到1／3？”
“唔？”
“我在你的曲线上选取了一个点，此时交流损失值大概是实际生产力值的一
半。也就是说，在这一点上，理想生产力中大约1／3 被浪费掉了。”
“到目前为止，我同意。”
“在这一点上，团队的规模有多大？”
“我不知道。”
“你当然不知道。到目前为止，我们只是在尝试找出你知道的东西。我们在尝
试找出你感觉到的东西。问问你的肠胃，当团队有多大时，就会有1／3 的生产力
被浪费在交流损失上？”
“我恐怕没法给你很准确的答案。”
“相信自己。多大？”
“好吧，我认为，大概4 个人。”
“也就是说，4 个人在一起工作的总生产力比一个人单独做这整个工作时的生
产力的4 倍要低大约1／3。”
汤普金斯先生耸耸肩：“当然，我不能肯定，不过在我看来，答案差不多就是
这样。”
“好。”贾米德博士又在膝上电脑里输入了一些东西。完成以后，他把结果显
示出来，把屏幕转给汤普金斯先生看：“这就是我们得到的模型，关于团队规模的
直觉。”
项目管理通俗读物 最后期限 ID2002
80
“我们把整个项目描述为努力将‘工作’从一个容器转移到另一个容器的过
程。开始的时候，‘剩下的工作’这个容器是满的，‘完成的工作’是空的。另外，
还必须用某种人为规定的单位来衡量工作的规模。。”
“代码行吗？或者类似这样的单位？”
“好吧，如果找不到更好的单位，那就用它吧。在模型中，完成工作的生产力
用一个叫做‘总生产率’的阀门来表示。这个阀门的值设置得越高，工作从‘剩下
的工作’向‘完成的工作’的流动速度就越快。很明显，‘总生产率’值的度量单
位应该是与容器中衡量工作量的单位一样的。”
“我明白。”汤普金斯先生说道。虽然他还没有完全弄清楚贾米德博士做的这
些东西。
“最后，这些箭头表示依赖关系。比如说，它们可以告诉我们，总生产率依赖
于四个因素：团队可用人员数、还没有融入团队的新成员数、交流损失和融合开销。”
“我猜，这里的‘融合开销’是指为了帮助新成员上路而损失的那部分生产力
吧？”
“是的。现在，我要针对每个阀门或者圆形测量表，编写方程式、或是建立图
形定义。比如说，这就是我对‘交流损失’测量表的定义。”
“就像你看到的，人数从零开始逐渐增加。当团队中有4 个人的时候，交流损
失大概达到了1／3。至于曲线的其他部分，是我自己估计的，我想你会同意。”
汤普金斯注视着这张图。在团队规模增大造成的损失上，它是否准确地反映出
了他的直觉？
贾米德似乎看出了他的念头：“在模型运行的过程中，你可能需要调节某一条
曲线，甚至还可能需要修改整个模型。”
“使它真正符合我的直觉。”
“完全正确。”
“好吧，现在我的直觉库告诉我，需要做一点改变。问题在于‘交流损失’是
一个静态的值，也许损失值应该是时间的动态函数。不管怎么说，人们总是逐渐学
着在一起工作的。”
项目管理通俗读物 最后期限 ID2002
81
贾米德博士点点头，表示同意：“跟我说说这个。”
汤普金斯先生细想了一会儿：“唔，在我看来，团队有一种潜力—— 随着共同
工作的时间越来越长，团队能够逐渐消除交流损失。成员们在一起经历很多事情，
团队就会变得越来越健壮，甚至能够克服交流的损失。作为一个整体，团队能够比
单个个体的简单加和做得更好。团队在一起，并且。。我想，他们成为了一个整体。”
过了一会儿，阿布杜尔又把屏幕转向汤普金斯先生：“就像这样？”
“嗯，是的，就像这样。很明显，按照你的说法，这儿应该有一个‘凝聚效应’。
现在，我们必须回去重新定义‘融入团队的开销’。”
“当然。”
汤普金斯先生盯着屏幕研究了好一阵：“你看，我想这就是我的模型。当我想
估计团队完成任务的能力时，在我脑海中出现的大概就是这样一幅图。当然，这也
有可能是完全错误的，有可能根本无法反映出团队的真实情况。。”
“当然。但是现在，起码你还有办法验证它。你可以运行模拟程序，看看所有