亚里士多德·科诺罗斯总是起得很早，他通常总是第一个到公司的人。这天早
上，汤普金斯先生一到办公室，比尔齐格女士就告诉他：这位摩罗维亚的第一个程
序员正在办公室里等着他。汤普金斯先生走进办公室，看见他正坐在桌子旁边，盯
着自己在白板上画的一张矩阵图，
“这是一张成绩单。”科诺罗斯对他说．“我根据团队内的设计成果给他们打
了分。这不是为了考察设计的质量，只是看他们是否做出了设计。如果你有了一个
低层的设计，能够起到蓝图的作用——也就是说、它能够确定所有的代码模块和接
口——那么科诺罗斯就给你一个‘A’。如果你什么都没设计出来，就只能得个‘F’
了。设计程度在这两者之间．也就得到中间的分数。看这张表。”
汤普金斯先生坐下来，搅拌着咖啡，研究着这张表。
产 品 A 团队B 团队C 团队
Notate F A A
PMill F A A
Paint．It F A B
PShov F A A
Quirk F B A
QuiekerStill C A A
“再跟我说…遍，F是什么意思?”
“F的意思通常是指：项目制造出了行政性的文档，并把它叫做设汁。一般来说，
这些文档只是用文字描述了对软件内部结构的一些早期设想而已。，”
“用你的话来说，不是真正的设计。”
项目管理通俗读物 最后期限 ID2002
173
“对，当然，以后会有一个设计出现，作为编码的副产品。但是被叫做‘设计’
的行为却没有制造出真正的设计，所以只能得到一个F，”
“嗯。所有的小团队都得了A和B，大团队则都得了F，这是怎么回事?”
“我还想问你呢。这是个难题。”
“首先，我注意到：如果没有一个好的设计．那么‘先贤’所说的‘最后一分
钟实现’就没有可能。”
“非常好，韦伯斯特，你开始进入状态了。”
“我还不敢肯定为什么A团队都这么惨。我可以肯定的是：他们根本不可能像我
们希望的那样进行编码之前的设计。”
“完全正确。实际上，他们根本不会实施‘最后一分钟实现’。这六个团队都
已经开始编码很久了。我没能说服他们推迟实现。我试过了，但是没有成功。”
“其他团队呢?”
“虽然程度不同，但是所有的B、c团队都在尝试先贤的方法。他们都在努力推
迟实现，并且在写下任何一行代码之前先尽可能地检查。其中的一些团队甚至严格
地将编码推迟到了最后的6个星期。”
“A团队没有这样做?”
“没有。”
“好吧．我认输了，这是为什么?’
科诺罗斯重重地坐在汤普金斯的安乐椅上，咧嘴笑着，但是没有回答。
汤普金斯又催问了一遍： “为什么A团队都没能做出设计?”
“太大了。”
“什么?”
“这就是我的理论。这些团队太大了。在本应该做设计的时间里，他们有太多
的人牵涉进来。设计是应该由小团队来做的，你可以让三个、四个或者五个人聚在
白板周围，一起进行设计。但是，你无法让20个人围在白板周围。”
“我还是不知道这会对设计有什么影响。你可以让三个、四个或者五个人去做
设计，其他人去做别的工作。为什么不呢?为什么他们不能去做别的事?”
“有什么别的事?”
项目管理通俗读物 最后期限 ID2002
174
“我不知道，总有什么事可做吧。”
“设汁是将整体划分为部分的关键。只要做完了这一步，你就可以把小块的工
作分配给手下人，让他们分别去完成。但是在此之前，你没有小块的工作，只有一
个整体。既然问题是一个整体，员工们就只能作为一个整体团队来处理它了。”
“这也无法解释他们为什么跳过了设计阶段。如果这件事必须做，那就必须先
做好它。经理可以让一支小团队去工作，让其他人都耐心等着。如果没有别的事可
做，就让他们到一边坐着去。”
“对。我想这就是Quickerst-A团队的情况。”科诺罗斯说道，“但是，请从项
目经理的立场来想想你的‘解决方案’。假如你正在管理一个大型项目，你的团队
从第一天开始就有30个人，你还有一个紧迫的时间安排——这正是他们给你那么多
人的原因。现在，你能让25个人到一边去坐两个月吗？”
“我明白你的意思了。他们会造反的。”
“当然。而且，你会成为众矢之的。想象一下，你要怎么去见你的老板，还有
你老板的老板?你可以在六月一号之前完成任务，但是一大半的人都在消磨时间。”
“嗯。我看上来不像一个真正的经理。”
“你不像。那么，你想怎么做?，’
“好吧，我得给那些人找点事干。”汤普金斯说道，“我想，我应该去把整个
的问题切成小块，再分配给他们。”
“对。既然根据定义．设计就是按照合理的方式将问题切分成小块，那么你就
应该尽早完成切分，从而缩短设计的过程。”
“我明白了。早期，我为了分配工作而进行的任务划分反倒成了设计的笑柄。
必须这样做吗?”
“不完全是，但是很大程度上是这样。的确，在设计完成之前．总会有些小事
可以消磨时间的。但是，如果你想让大量的人都有工作，这些小事根本就不够。”
“为了让所有人都能做关键路线上的工作，我必须将设计本身适当划分。”
“现在，你该明白他们为什么最后没有任何设计了。”科诺罗斯说道，“你粗
略地把整个工作分成五块或者十块，这样你就可以让五个或音十个设计团队一起工
作。粗分是一个设计步骤，但是你并没有把它当成一个设计步骤。你其实是把它当
项目管理通俗读物 最后期限 ID2002
175
成一次人员划分。”
“而最初的这次粗分，就像你说的，正是设计的核心。”
“是的。．而且，既然没有人直接负责复审它的逻辑，它就会一直是设计的核
心。结果就是没有设计。更糟的是，编码和测试是最能消耗人力的工作，所以总会
有一种诱惑。让经理们想立刻开始这些工作，哪怕根本还没完成任何设计。”
汤普金斯先生还不相信：“如果真是像你说的这样，那么大多数项目在设计阶
段都存在严重人员超编。所以，大多数项目都无法真正完成设计。”
科诺罗斯苦笑着：“恐怕事实正是如此。就在某个地方．就在今天，某个新的
项目又开始了，它从第一天起就严重超编。这个项目会走过所有的步骤，起码看上
去是这样，但是根本不会有真正的设计。软件内部的结构会不断发展，但却不会有
真正的设计思考或者复审。然后，也许几年之后的某一大，需要重新做这个产品的
时候，新项目组的一个成员会对设计进行彻底的整理，他会重新组织出真正的设计。
而下面会发生的就非常可悲了。”
“什么可悲的事情?”
“以后重新工作的人才是第一个真正看到产品设计的人。”
在这天的大部分时间里，汤普金斯先生反复地想着“早期的超编妨碍了明智的
设计”这个概念。如果科诺罗斯的工作在某种程度上是正确的话，它就已经远远超
出了爱德里沃利。这意味着整个软件工业都处在非最优的状态，即注重早期的团队
建构，并因此做一些隐瞒真正的核心设计的工作。
贝琳达在午饭出去散步的时候，汤普金斯把这整套思想都告诉了她。她看上去
并没有被打动：“还有什么新的?管理就是不断的妥协折中，一件需要折中的事就是
设计。为了让人们有事做，你就必须接受不够完美的设计。”
“不够完美，起码也有吧。但是，假如你根本得不到设计，又怎么办?”
“总会有设计的，只是不够好而已。哪怕设计阶段完全是虚构的，也会有个设
计，否则，未来的项目组成员就永远无法从代码中重新设计。”
“好，我接受。我们讲的不是有没有设计的问题．而是在讲设计质量高低的问
项目管理通俗读物 最后期限 ID2002
176
题。既然需要模块划分的时候没有人真正考虑设计问题，那么模块划分这部分就是
做得不好的。”
贝琳达把白板擦干净。“现在，这就是我们要处理的，就像这样。”她飞快地
画着，“这是我们系统的整体，这是各部分的划分。”
“这只是一种划分方法。还有无数种别的方法。比如说．这儿就是另外一种。”
她又在第一种划分方法的旁边画上了第二种，“为了判断哪种划分方法更好，我们
需要考虑最后的接口。不必太正式，我们都知道：接口越多，系统就越复杂，划分
就越差。”
“当然，的确如此。”汤普金斯先生补充道，“不管划分的是什么。不管是在
划分系统还是在分配工作。”
贝琳达点点头：“你算说对了。现在，我们加上各部分之间的接口，我们现在
做的就是所谓的‘设计评估’．因为我们要选择接口组合最简单的划分方法．”
“那么，我们会选择右边的这个。”汤普金斯先生像一个过于热切的孩子那样
大声说道。
“对。我们会选择它，因为各部分之间的接口更少。现在，我们把这些部分分
配给团队的成员。人员的划分形式跟系统的划分形式是相同的。”她又画了一些。
“团队中人与人之间的接口跟系统各部分间的接口是同型的，所以……”贝琳
达指指两边的接口图，“……比如说，3号和4号这两个人之间的接口，就跟产品的3
号和4号这两个部分之间的接口是同型的。”
她坐下来，回头看着这些图：“现在我有点沮丧。如果模块划分的工作在设计
之前完成．人与人之问的接口肯定比真实的需要复杂得多。”
“肯定的。”韦伯斯特表示赞同，“如果在模块划分之前先做设计，人与人之
间交流的信息肯定会少得多。如果先划分模块．那么为了完成任何工作，人们都不
得不更多地与同事交流，交流也更加复杂。结果他们各自独立工作的可能性更小，
会有更多的电话、更多的会议和更多的挫折。”
她做了个鬼脸：“嘿，我想这正是我们以前的故事，韦伯斯特。拙劣的接口，
挫折，太多的会议。这一切都是因为早期的人员超编吗?”
“我已经开始这样想了。”
项目管理通俗读物 最后期限 ID2002
177
比尔齐格女士敲敲门，告诉他们PShop-C项耳的经理爱弗瑞尔·阿特贝克来了。
汤普金斯先生赶紧招招手，让爱弗瑞尔进来。
“嗨，朋友们，能让我说两句吗?”
“当然可以。”汤普金斯对她说。他指指贝叭琳达对面的椅子：“有什么事?”
爱弗瑞尔坐下来；“需要管理层介入了，需要你们帮忙。”
“噢。行，你需要什么?”什么都可以，除了时间，他暗想着。
“很多很多的人。”
“啊。”汤普金斯先生呆了一会儿，回忆着他“保持B、c项目组紧凑”的理论。
“我们保持你的项目组紧凑，爱弗瑞尔，不是为了省钱。我们是担心你的团队超编。
你看．就在你进来之前，我们正在讨论一些不幸的结果……”他站起来，走到白板
旁边，准备开始讲课。
“我全都知道，韦伯斯特。”爱弗瑞尔打断了他，“我知道这些道理。但是我
的项目发生了一些变化。我们已经完成了一个激动人心的设计，非常漂亮，就连亚
里士多德也说这是他所见过最漂亮的设计。当然．他给了我们很多帮助．使这个设
计更加优雅、更加完善。在最近几个星期里，我们对它做了书面审查和测试。证明
了它的可行性。当然．这些工作还没有做完，但是已经快了。我们可以看到，下一
步的工作都将是非常细节的。这就是我们需要人手的原因，韦伯斯特。我手下有7
个人，现在正好够用：5个设计师和2个技术支持人员。但是．从现在开始的2个月，
我们需要增加20个人。”
贝琳达兴奋地对他说：“你看不出来吗．韦伯斯特，这是硬币的另一面。刚才
那几个小时里，我们一直在谈论设计之前人员超编的害处。但是，他们的设计已经
快完成了。如果我们把设计看成关键的功能划分工作，那么他们已经完成了。现在，
爱弗瑞尔需要更多的人，把划分好的工作分配给他们。”
“对，我只是想给你一些建议……”
贝琳达已经难以自制了： “你们划分了多少块，爱弗瑞尔?”
“嗯，l 677个模块，l 300多个数据项，18个文件结构，20个····”
“听起来，就算给你20个人也不够用的。”
“的确。我不想那么贪心，但是我大概需要35个人。我们有大量的模块需要编
项目管理通俗读物 最后期限 ID2002
178
码，需要构造大量的接受测试，有很多代码审查要做，还有一些文档整理工作。所
有这些工作都已经做好了说明，就等着分配人来做了。大概再有6～8个星期……”
贝琳达站了起来：“给她，韦伯斯特，绐她35个人。这就是我们的突破点。”
“稍等一分钟，我们不能在2月份一下子就交给爱弗瑞尔35个人。这样会打断她
的进度，她将不得不把所有的时间都用来带这些新人上路。”
“那就给她35个了解她的项目的人。”
汤普金斯有点迷惑：“我们上哪儿去找35个了解Pshop细节的人呢?”
“当然是A团队。”贝琳达说道。
爱弗瑞尔走了以后，贝琳达和韦伯斯特留了下来，讨论着这件事的前前后后。
“我不怀疑你的正确性，贝琳达，毫无疑问。如果我们不受约束，一定会这样
做的。但是像现在这样的情况下，我们不知道……”
“‘有原则的人会怎样做?’难道这不是你以前问的问题吗?而你得到的答案肯
定是：首先满足项目的要求，尽量帮助他们把工作做好，让他们尽快完成任务。这
是你一直遵循的原则。现在，你就应该拆散A团队，让这些人到B、c团队中去工作，
很明显这是所有人的要求。”
汤普金斯先生努力稳住声音：“贝洛克会把我们生吞掉的。就在周末之前．你
建议我向贝洛克挑战，同时也给他对此视而不见的选择。如果我们再用这个向他挑
战，他就没法再视而不见了。他将不得不有所行动，是我们在逼他行动。。”
“不管怎么说，我们早晚都得这样做的。”
“早晚，对，但不是这个星期。爱弗瑞尔说她可以等2个月，那就给我2个月，
到时我就会拆散A团队，我保证。”
“她要求2个月之内给她这些人，但是真实情况是：最好现在就给她四五个人，
构成团队的核心，以后再逐渐扩展。”
“我知道，但是我们必须等待。我非常希望能再等一到两个月……”他放低了
声音。再过一两个月，莱克莎就会回来了，这才是他希望的。也许元首也会重新掌
权，把贝洛克再次送回他以前的笼子里去。
项目管理通俗读物 最后期限 ID2002
179
贝琳达皱起了眉头： “爱弗瑞尔的项目不是关键问题，Pshop是个相对比较大
的项目。如果她希望在2月份增加35个人，那你猜猜看，QuickeStjll的B团队和C团
队、PMill的 B团队和c团队现在是什么情况?那些比较小的项目可能比爱弗瑞尔走得
更远。我们必须拆散所有的A团队，韦伯斯特，必须现在就开始。”
他低头盯着手看了好大一会儿。“我知道。”他低声说道。
贝琳达又走到了白板旁边：“当详细的低级模块设计完成以后，就到了划分已
经进行的工作的时候了。不光我们的项目如此，所有的项目都如此。这告诉了我们
这些年一直都忽略了的某些事情，也是我们的整个产业都忽略了的某些事情。你看，
我们习惯了像这样组建项目团队。”她飞快地在白板上画着，“但是理想的组建团
队的曲线却是完全不同的。”
汤普金斯先生努力把注意力集中在她的图上，不去想人员转移的难题：“晤……
理想的人员配置。对，我想你是对的。这正是眼下的事实所说明的．而这肯定是和
传统观点背道而驰。我承认，我从来没有像这样配置过人员。到目前为止，从来没
有过。”
“我倒是这样想过，现在我也正在这样想。但是．这种让我一直保持紧凑、直
到很晚才加人大量人员的项目一般都是不那么重要的。我从来没有在关键的项目开
发中这样做过。也许，现在我应该这样做。”
“嗯。”
“韦伯斯特，也许这能解释我一直感到疑惑的一些事情。我一直暗自怀疑也可
以说是极度厌倦的怀疑：不管什么时候，如果项目的时间安排太紧，它们都会失败。
我是指那些成员被明确告知时间安排紧迫的项目。我总是觉得，如果这些项目开始
时的时间安排不那么紧迫，它们反而能提前一两个月乃至一年时间完成。”
汤普金斯先生笑着说：“我们还应该做这样一个实验：哪个项目创建完全相同
的产品，其中一个时间安排很紧，而另一个则比较合理。’’
“安排合理的项目会更早完成，我敢保证。”
汤普金斯先生的日记：
项目管理通俗读物 最后期限 ID2002
180
人员安排：
.. 在早期，人员超编会迫使项目跨过关键的设计阶段（这是为了让
所有的人有事可做）。
.. 如果在设计完成之前，工作先被分给了很多人，那么人与人之间、
工作组之间的接口就会很乱套。
.. 这会使团队内部耦合度提高，会议时间、重复劳动和无效工作都
会增加。
.. 理想的人员安排是这样：在项目的的大部分时间里由小型核心团
队来做设计工作，在开发的最后阶段（时间安排的最后1/6）加入
大量的人手。
.. 可怕的猜想：时间安排紧迫的项目，与时间安排比较合理的项目
比起来，完成的时间发而会更长。
