很多人认为，世界上的人基本上可以分成两类，当然了，还有一部分人认为不止两类，应该更多。在工作与组织的问题上，也存在相类似的看法，有些人认为只有两种选择，那就是井然有序和混乱无序——也可以称为自由和压抑。而另一部分人觉得，事情绝不会这么简单，无论那些管理者和管理顾问怎样简化这个问题，在现实社会中，许多组织中的成员还是在不断地挑战这种简单的二分法则，他们试着打破这种一维的思考方式，寻找新的方法和途径。

一方面，对工作组织可以采用层次型模型（见第11章）；另一方面，完全相反的，还可以采用具有创造性的混沌模型（见第12章）。但是，在井井有条的传统主义和自由创意的革新主义这两种极端模型之间，存在着众多的其他模型，而许多项目也在使用这些模型。

当然，并不是每个组织都陷入了非此即彼的怪圈，有一些组织完全避开了这个问题，他们不会在这个有关组织模型的基本问题上犯迷糊，他们认为“二者都选”要比“只选其一”更好，他们说：“我们可以解决这个问题。”从他们的观点来看，无论是传统的保守主义还是自由主义的竞争风格，看起来都只不过是如何处理“我”和“我们”之间的关系而已。在传统的层次型模型中，个人的利益要服从于团队或组织的利益；在革新性的利己主义中，个人的利益占了上风，集体的利益被放到了后面。

但是，有些人认为在整体和部分之间不存在根本性的冲突，就像没有必要非得从变化和稳定中选择其中之一一样。他们使用的工作方式的正式的名称是“开放范型”，是一种基于平等主义的合作和交流之上的工作模型，并可以获得更大的适应性。我们可以非正式地把这种模型称为“适应性合作”模型，对人类组织来说，这是一种可以自由调整的体系结构。

时散时聚

在解决技术性问题时，可以对适应性合作进行精确裁剪。这样，既不会过于重视传统和稳固性，也不会过于重视革新和变化，按照项目和过程的观点来看，最重要的事情是，在做什么和怎样做之间进行必要的调整。如果我们今天的任务是进行独立的程序设计，那么就可以分开工作；到了明天，如果我们必须拿出一个通用的通信协议，那么我们就聚在一起工作；如果每个人都对于数据库的体系结构有些看法，那我们就举行会议，讨论这个问题。

这种团队的目的在于：通过松散管理、讨论来解决实际问题，并最终达到一致的目标。从某种意义上来说，他们一直在不断地调整自己，根据实际的工作需要变换工作的方式，以满足暂时的和长期的目标。谁“负责”和如何负责完全取决于团队当前正在做什么。

按照这种方式组织的开发团队，与那种金字塔形式相比，更像一种扁平化的结构形式。团队成员在工作中不断变换着角色。在那种过度自由的突破型团队中，成员之间独立性更强，甚至会相互竞争，而上述方式与突破型团队也是不一样的，团队成员之间的相互关系要密切得多，大家共同整理工作成果。决策是大家通过讨论、谈判和技术性妥协（参见本书第一部分）共同做出的，但这并不是说每个人对任何观点都要持赞同态度，而是说，技术性妥协的结果是他们开展后续工作的基础。技术性妥协是指：所有的团队成员基于基本事实，就某一问题达成一致意见，以决定团队下一步的选择和行动。这需要充分考虑每个成员的意见，技术性妥协可以确保每个合作者“买进”他人的成果，并因为在最终结果中包含了自己的意见而自豪。

由于团队是通过共同讨论来解决问题，所以在遇到复杂的难题时，他们的表现会显得特别突出，特别是面对那种需要进行大量的信息交换和验证的情况（在软件开发中，时常会出现听上去很正确，但实际上必须经过验证才能确认的信息）。事实上，问题所涉及的方面越广，涉及的信息越多越复杂，这种开放型团队的优越性就表现得越明显。相比之下，战术型团队对信息的控制过于严密；而突破型团队又过于忽视信息，致使大量信息在竞争和混乱中丢失。

突破型团队，由于过于重视自由创意，可能会使最终成果陷入华而不实的境地；而战术型团队，由于过分正规和遵循传统，开发出的产品在数据结构、算法和界面等方面都缺少新意；而协作性解决问题型团队恰恰弥补了上述二者的缺点，在解决问题时，依赖的是所有成员的意见，最终的解决方案是既实际又有新意。

如果团队想要做到真正的协作开发，就一定要有合适的领导。这种领导应该鼓励自由讨论，并能够帮助成员从讨论中得到技术性妥协。对这种开放型的团队来说，最好的领导应该表现得像他们中的一个同事一样，能够参与所有的技术问题讨论，包括分析、设计和系统构建。特别是，他们不应该作为会议或者技术性讨论会的主持人，因为那样他们的言论会对大家各自的想法形成一种引导性效果。他们应该让大家畅所欲言，并从中汇总出一个最好的结论。他们必须坚信：众人拾柴火焰高；三个臭皮匠，顶个诸葛亮！有些管理者，总自认为是项目组中最棒的人，就算其他的人都加起来也比不上他一个，而这种管理者不适合担任这种协作团队的领导。他们如果自己单干，或者当传统战术型团队的领导，可能会更好一些。

不要吃惊，就算是这种适应性很强的解决问题型团队也会产生很多问题。这些人会在讨论中浪费大量的时间。当原定一个小时的讨论没有按时结束时，他们就准备花上更多的时间继续讨论。他们不但讨论技术问题，还讨论技术问题背后的哲学思想；不但讨论开放方法，还讨论方法的使用前提。当他们在验证所使用的方法和结构并试图调整以适应实际问题时，他们甚至恨不得将问题碾碎了来研究。（“嗨，伙计，也许我们需要就系统的这部分问题分成几个小组，分开工作几天，然后再重新讨论。”）

下面是一些在解决问题型团队中如何削弱空谈倾向的方法。应该对讨论时间加以限制。如果在预定时间内未能达成一个技术性妥协，那么就把问题放到一边；或者按照某种默认的方法，成员把问题交到管理者手中，由他来决定。尽管上述方法在某种程度上都与技术性妥协的本意有所背离，但只要这种情况不是经常出现，那么由于问题解决效率明显提高，最终结果完全可以弥补某些成员的失落感——怎么我不再是主人翁了？

但这些方法都是因团队而异的，并不能简单直接套用，如果想保持团队的开放性，每个团队都应该去找适合自己的团队的方法，讨论正常情况和意外情况的处理方式。

敞开大门

在我接触的团队中，协作得最好的是一个叫做“理论结构工作组”的团队，他们是附属于某个职业社团的、保持松散形式的一个独立工作组。在这个团队中，成员之间在一种自由讨论和相互尊重、相互支持的气氛下共事，试着开展一个理论结构的通用计划。他们的会议是完全公开的，无论是谁，只要对建立更好的理论有兴趣，都可以参加。会议的内容和形式可以通过团队内部的讨论来确定。不可避免的，在几乎每年的事务会议上，都有一些新人，他们一方面对自己能够加入这样一个精彩的组织感到兴奋；另一方面，他们会提出一些措施，建议将组织形式进行重组——比如，社团化、会员制、制定规章制度、确定工作步骤等。每年我们都会认真讨论这些建议，而每一年，这类建议都会被否决，最后的意见是：继续让组织保持公开、非正式、灵活。

有一年，未经太多思考，我提交了一个疯狂的建议。那就是，为了不再在这类问题上浪费时间，以后任何将组织形式固定化或者正式化的建议都不再被考虑。还没等我念完自己的建议，我本人就被这个自相矛盾的提议逗笑了。这个组织之所以受人欢迎，正是由于我们能够真诚认真地对待每个人的建议，无论他的资格有多新。当场的每个人都笑了，我坐了下来，然后我们又开始讨论最近的一个关于将组织正式化的建议。如果想要开放，必须保持一个开放的过程。

Steven Sondheim在他的戏剧《周日，与乔治在公园》中，以一句极棒的话作为结束语：“白色，白纸或者画布，他的最爱：存在无数的可能。”

这也是我的最爱。

摘自《软件开发》，第1卷，#6，1993年6月 Ka/D6gW5Y2Nn1mfqpiSw8yaX22S1tsVF/1ohGgpbOcX1hsITfPveXqX/LDzQGSgH