好的，伙计们，到组织起来的时间了！问题是：怎么组织呢？如果你一个人单独工作，可以按照你愿意的任何方式工作。你不需要就你的工作和别人的工作进行协调，也不需要与任何人处理好关系。你可以让每件事情都按部就班地进行，强迫自己按照软件开发生命周期模型的标准步骤进行工作：或者，只要你愿意，你可以在一个嘈杂的办公室环境中编程，也可以只在自己想干活的时候工作。但是，一旦你和两个或两个以上的人共同工作时，注意，是“共同”工作，那么，他们干的是什么，是怎么干的，都成了必须考虑的问题。

在本章中，我们将先探讨人类工作的组织和管理：工作是如何组织的，人们是如何协调他们的工作的（参见文献Constantine 1990a，1991c，1993c）。人类对于组织的想法就好像是软件的体系结构——相当于动态的管理程序组件。无论你是在组织一个新的软件公司，还是在组织一个新的软件项目，二者之间很多问题都是一样的。

那么，你是如何做的呢？你如何让一群人——无论是一个项目组还是一个完整的公司——共同工作呢？你是如何组织团队架构、分配工作、管理所有的活动的呢？什么是正确的方法呢？现在到了揭示一个标准的“咨询专家的回答”的时间了，那就是：因地制宜！寻找组织项目的正确方法就好像是寻找编写子程序的正确方法一样，完全取决于你的目的到底是什么（参见文献Constantine 1993c）。

如果有两个组织，其中一个组织的基本工作是编写一套打印驱动程序或者屏保程序，而另一个组织是开发一套既符合当前软件工程规范，还要支持面向对象软件设计的CASE工具软件，那么二者的组织和管理模型肯定是不相同的。有一本非常棒的有关团队的书，在那本书中，Larson和LaFasto（1989）明确指出了项目团队的几种主要差别，以及每种团队更适合于什么情况。现在，让我们来看看这4种完全不同的项目团队组织模型，每种都有它自己所适合的特殊场景，同时每种也具有明显的缺陷。

组织起来

那么，让我们组织起来吧！最简单、最安全的方法也是最可靠的、最真实的，这是一个标准的操作过程。当工作涉及多人参与时，传统的方法就是让某些人负责，让他们成为管理者。管理者的职责就是指导和监督他人的工作。这种结构可以逐步拓展，结果就是：形成一个层次性的管理结构。这种结构很简单、很稳定，是一种家族形式的组织结构，是一种基于层次授权的传统的金字塔式结构。那些按照此种模型管理的软件项目组织，他们的组织结构层次可能会很深，但它归根到底还是一种层次结构。从理论上来说，这种模型的效率应该是惊人的，但在实际应用中，这种模型也可能会发展成一个塔状的官僚主义结构，除了低效的官僚主义外，什么都干不了。

这种模型不仅仅可以应用于工作，甚至可能成为一种生活方式。我最近重新整理了磁带，以便腾出一些地方来放CD碟，我发现了一个真正的宝贝：一盘过时的“Paean”——IBM公司社团歌曲精选 。当我听到美国的英国秘书联合会（Association of British Secretaries in America，很好笑吧，但这却是乐队的真实名称）激动人心地演唱“IBM乡村俱乐部之歌”时，我开始思考企业文化的问题：我们工作的方式和生活中的其他方式一样，也在时刻影响我们看待世界的方式。

从传统的观点来看，这种金字塔式的组织模型应该具有稳定的性能，而管理的关键在于各级的控制。管理者负责做出决策，下属负责实施；下属应该表现出绝对的忠诚，并接受上级的领导。可以预见的是，可靠的性能是通过标准和过程、纪律和规范来保证的。每个人都各司其职、各尽其能。公司或者部门或者项目组的利益是首位的；个人如果能够出色地履行自己的职责，就应该获得奖励。

从基本的形式来看，这种模型真的非常简单。将某些人放到领导岗位上，让他们来发号施令，他们一般都是些对行业有较深了解的人。在传统的层次模型中，我们假定决策是严格地按照自顶而下的形式制定出来的。这样，当出现某个突发事件时，只需找到具体的负责人就可以了。在找个人的过程中，可能会有点麻烦，但是，一旦找到了，决策的制定还是很高效的。只要领导愿意，他就可以按照自己的想法随时做出决策，没必要和他人咨询，也没必要讨论、争论和探讨。很明显，这种模型有很大的优越性；但缺陷也很明显，它意味着所有的事情都是以上层领导的意愿为转移的，领导可以很快做出一个好决策，同样，他也可能很快做出一个坏决策。如果一个领导反应过慢或者太脱离实际，他的一个决策就可以让整个金字塔遭到毁灭性的倒塌。

金字塔的力量

当将传统的模型应用于软件项目或者项目团队时，如果应用对象是战术性工作，那么这种模型会发挥出最大的效能。所谓战术性项目，就是指在项目中所涉及的业务领域、工作范围和项目的可变因素都是团队所熟悉的，是团队可以掌控的。对于这种项目，最重要的事情是尽可能地分好工。我就是因为这种战术性项目才终止了我的编程生涯，我们当时开发了一些常用的商业系统应用，比如：薪金管理系统、计费系统、个人文件维护系统等。一旦你开发过几个薪金管理系统，那么所有的这类系统看上去就都差不多了。就算实际上有所差别，但这样想有助于你将这种系统简单化，可以使你方便地编制、维护、开发这种系统的标准。最后，你熟知开发中的每个步骤，就算是闭着眼睛也可以工作了。

对于战术型团队来说，“清晰度”是至关重要的问题——需求是否清晰，方向是否清晰，角色是否清晰。在这个世界上，如果能够准确定义模型，并配以清晰的标准和规范，那么开发模型所起的作用会更大。在一个详细规划的软件开发生命周期模型中，每个阶段都被定义了，我们清楚地知道下一个步骤应该是什么，那么，工作就会是准确而有效的。在这样的一个团队中，团队的重点到底应该放在什么任务上，成员最需要的就是从项目领导和管理者那里获得清晰的指导。合理地分解工作，并恰当地分配给每个团队成员，成员按照建议的方法来执行。

传统的层次模型可以让组织运转良好。在业界，许多公司和无数的软件项目都是按照这种模型组织的。在计算机界还流传着一些关于成功案例的故事，那些赞美了无畏的领导和忠心耿耿的成员的社团歌曲精选就是一个最好的证明。

这样一种中规中矩的环境应该是比较舒适的，但是，并不是每个人都适合在这种环境中工作。适应这种环境的是那些忠诚、顺从、勤恳的人。他们会比其他人更感到工作的重要性，而且他们会积极响应领导的指示，并且他们会将更多的注意力放到编程上。那些性格顺从的以及喜欢接受领导的人，只要告诉他们该做什么，他们就开始去做，对他们来说，战术型团队简直就像个天堂，与此同时，整个团队也运转良好。

另一方面，按照传统层次模型建立的团队很容易陷入惯例的怪圈，他们会抵制变革，他们会不断维护原有的稳固的旧体系，最终会将更多的精力耗费在维持和增强过程与标准上，而不是将更多的精力放到解决问题或者开发产品上。对他们来说，最好的情况也不过是高效和高产，而不可能是变革性的。他们的变革往往是建立在原有技术上的渐进式改进，而不是革命性的变革。观察工业界那些按照层次模型组织的大企业，我们会发现，它们的主要变革都是从外界获得的，或者是小规模的内部变革。

按照这种线性方式组织的公司和软件团队，一旦遇到牛仔程序员，就会面临极大的问题（参见第7章、第8章和第10章）。独立性强的个体和传统性的层次组织根本就是水火不容的。那些拒绝或者挑战权威的人，那些坚持自己的方法而偏离标准的人，很有可能发现自己已经不可能获得升迁的机会了，或者感到已经有人在给自己穿小鞋了。

如果站在金字塔的顶端或者其中任何一层角度来考虑团队的组织方式，看上去好像不可能有其他的组织方式了，毕竟，事情都是要有人负责的。你要么领导，要么服从，要么就离开，有些人还是没有看到人类组织形式的变化，好像就只有这一种方式可选。但是，我们也曾经认为，所有的子程序都必须由一个主程序控制是解决模块化程序的唯一方法，可现在我们已经可以使用通信对象构件和分布式数据库的点对点网络了。

人无论如何也应该比程序更容易改变。至少有些人是这样的。

摘自《软件开发》，第1卷，#3，1993年3月 IYGN09CYmIT5exZFwnO5Xk1Hxa1N2oqK+OArAM1oU3lsU2/mTQYZ6oxGJsjBRX+R