按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
“我用一个矩形‘容器’来表示你的可用人员。容器装得越满，你能用的人就
越多。我们把初始值设置为100。
“这就是一个模型，但是还不是动态的，因为还没有人员的流动，例如人员离
开项目、新的员工进入等等。如果我们就这样运行模拟程序，它会告诉我们：可用
人员始终保持在100 人的水平上。
“下一步，我们添加一个管道来表示离开项目的人员流。另外并且再添加一个
阀门，它的值决定了人员离开的频率。我们把阀门的初始值设置为每月4 个人。
“旁边的云形小图标表示：当员工离开之后，他们就离开了我们模型。最后，
我们再添加一个管道，表示新员工通过‘雇佣率’这个阀门进入项目，我们可以直
接把入口阀门的值与出口阀门的值联系在一起，这样，在特定的某个月里，不管有
多少员工离开，我们都会雇回同样数量的新员工。在‘雇佣’阀门和进入项目的人
员流之间，我们放置了两个月的培训时间。于是，我们就看到了这个最终的模型：
“为了表示从5 月开始的‘退出率’突然上升，我们设置了一个‘退出率’的
方程式，让它在5 月之前保持每月4 个人的水平，然后从5 月开始突然上升到每月8
个人。现在，选择‘运行’命令来看看模拟运行的结果。”程序运行的过程中，汤
项目管理通俗读物 最后期限 ID2002
76
普金斯先生一直如痴如醉地看着动画显示的“可用人员”容器变化。当程序稳定之
后，贾米德博士停止了运行，用鼠标点了几下，让系统显示出整个过程中的可用人
员数。
“噢，的确跟我猜想的不一样。”汤普金斯先生承认，“它在几个月中持续下
降，然后到7 月又保持恒定，但是就再也不会回到原来的水平。我很奇怪，为什么
会这样？”
贾米德博士沉思了一会儿：“我也不是很明白。也许是因为更多的人陷入了培
训中？我的意思是：如果没有模拟程序的帮助，即使这样简单的一个相互关联的网
络也是很难预测的。模拟程序为我们提供了他们之间的联系，不费吹灰之力就能完
成这种问题所需要的算术分析。”
汤普金斯先生大笑起来：“这种我们的骨头算不好的问题。现在我真的明白你
的意思了。”
贾米德博士没有说话。汤普金斯先生离开了屏幕，漫无目的地盯着天花板上面
的某个地方。所有这些，对于他和他在摩罗维亚的那个小世界，对于要生产六个产
品的项目，有什么帮助呢？为了完成目前的工作，需要做些什么呢？虽然他还不能
完全肯定，但是他已经开始发现：这些模型和这个模拟程序很可能有用。
他转头看着自己的新朋友：“就算我已经完全被你讲的这些说服了，阿布杜尔。
我应该做些什么呢？我应该怎样利用你今天与我共享的这一切？”
“呃，我们要从你的直觉库中挑选一些元素。要从你的‘仓库’里搜索出有用
的管理直觉，简单的办法就是给它一点挑战。所以，我来讲一些无法容忍的事情，
然后问你为什么这些事情是无法容忍的。”
“好，来吧。”
“假设我是你的老板。你告诉我，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？”
“唔？”
“我在你的曲线上选取了一个点，此时交流损失值大概是实际生产力值的一
半。也就是说，�