“条条大路通罗马”，任何事情都可以有多种解决方法！在我的整个职业生涯中，我将这个简单信条作为指路明灯，它指引我采用变通的方法来考虑怎样组织软件和人员。但是，我们必须意识到，多种选择也会带来负担，那就是——如何从众多选择中做出正确的决定。开发好的软件就意味着从多种选择中做决策，甚至是从多种选择中挑选出各自的优点，并对其进行创造性的综合以达到超出各种选择的优势效果。那些基于“一致意见”（consensus）的方法来做出决策和解决问题的团队可以看做是组织优良的团队，如果他们知道如何避开那些对于团队来说是常见的陷阱，那么他们可以做出高质量的决定，并且可以达到创造性综合的目的。探讨这种基于“一致意见”原则进行决策的团队的秘密是非常值得的。

我一直将决策能力作为基本生活能力中的核心能力之一，但若要学习并获得这种能力，除了不断实践外，没有其他更好的途径。也就是说，就像那些成功的家庭和公司一样，它们都是从众多机会中不断地进行决策实践而产生的。在到达职业生涯中期之前，典型的职业程序员都必须解决无数个问题，因而要做出几千个决定。很自然地，我们期望从业人员的这种决策能力越来越强。但是，大部分决定都是由程序员个人独立做出的，而在团队中做出决策和解决问题则是由不同的个体共同进行的。

中庸的风险

当我在麻省理工学院的Sloan学校第一次学习管理和团体动力学（group dynamics）时，分析那些基于团队做决策和解决问题的方法所提出的假设性缺陷，耗费了我大部分的学习精力，特别是所谓的风险转移（risky shift）和团体反倾向（counter-tendency of groups）这两种缺陷，以致我对于团队决策的理解达到中庸的地步。在那个保守的年代，就算是那些有民主主义思想的管理者，最为担心的问题也都是风险转移，而不是蔓延的中庸主义。直到20世纪70年代发生剧变，团队思想才成为了时代思潮。

研究表明，集体的决策比从集体中的个体独立做选择更具有风险倾向。如果将这种决策模式应用于软件编程，我们可能会看到这样的结果：团队可能使用更奇特的数据结构、更古怪的算法或者更晦涩的语言来编程，这样做必然会给这个软件带来风险。然而，团体动力学的研究还表明了另外一种倾向：在做决策和解决问题时，团队有一种均衡的效果，这会将个人的贡献和能力降到最低。从上面两种研究可以得出结论，似乎单独做出决策更具有效力。其实这两种倾向都是可以尽量避免的。

上述两种倾向在团队决策中存在的可能性在很大程度上都依赖于团队的组织和领导方式。以前，我曾在国外一家新公司中与顾问和管理者一同工作，在那里中庸思想占据主导地位。对于许多在旧体制下训练出来的管理人员来说，团队合作意味着大家均处于一个无能的工作水平上。在这种管理体制下，团队是一种逃避责任的方法，有时他们积极地合谋来限制成绩。在这样一个团队中，挺身而出或者提出一个新颖的观点或者有争议的想法，或者任何出头的行为，不仅仅要冒招致同事怨恨的风险，还可能被人牢记在心，并期望你今后都能达到如此的成绩。在典型的“大锅饭”体制下，如果考虑“饭碗”的稳定性以及“多劳不多得”的分配制度，谁愿意给自己惹麻烦呢？

一个团队所处的社会和组织的大气候是真正发挥团队潜力的决定性因素。为了达到最好的效果，社团文化和团队领导应该积极鼓励和支持创新与协作。从某种意义上说，上述团队做得很好，达到了老板和企业政策制定者“真正”期望，即掩盖事情黑暗面而不是获得好的结果。该团队的管理者告诉我，他们都学会了“绝不要成为链条上的最后一环”。

轻度领导

在“一致意见”方式的设计和决策制定时，团队领导所扮演的角色是至关重要的，不仅要从宏观上建立起一种协作的气氛，而且还要在微观上起到领导的作用。要想使“一致意见”方式的设计和决策制定达到最佳效果，必须让最终的解决办法体现所有成员的智慧，包括经验、创造性以及各种思想，它应该不仅仅是个人贡献的一个均衡产品，而是一个真正综合了各成员最优贡献的产品。不管团队的领导者多么具有能力，当他开始压制成员自身的行为时，团队的工作质量就下降了。

领导团队需要方法，有些方法看上去很狡猾，甚至可以说是“阴险的”。作为一个团队领导，在不恰当的时间表达自己的意见会使整个团队成员对问题形成偏见，最终导致不良的结果。研究表明，只要领导在所有的成员或者绝大多数成员发表完意见后，最后表达自己的看法，就会对最终的解决方案起到积极的促进作用。同时，研究还表明，一个领导说话速度过快，就会降低团队工作的质量。对于那些自信的领导，如果他们总是认为自己是正确的或者知道的是最多、最好的，也会使解决问题变得更加困难。

在软件开发企业中，多数项目领导和中级管理者都是一些“真正以技术为荣”的人员，差不多每个人都是从程序员、系统分析员、软件工程师一步一步走过来的。他们认为自己熟知软件开发技术。对他们中的大多数人来说，从键盘前走开，让其他人来做工作并做出技术决策，是一件很困难的事情。

现在，我们知道如果使用“一致意见”方法来做决策，而且想要获得第一流的问题解决方案，最重要的因素之一就是采用中立领导。讨论会的主持人尤为重要，无论哪个领导来主持讨论会，他都必须时刻努力保持中立，这样才能从所有的意见中得出最好的结论。

这样的领导是每个人的朋友，但又不是任何一个人的私人支持者；这样的领导能够从每个人的建议中提取出最好的结论，而不是偏爱某个人的结论；这样的领导不会偏向于某些意见，也不会在团队中推行自己的看法，他可以帮助团队建立团队自身的“一致意见”式的处理方法。

具有讽刺意义的是，与上述观点相反，项目经理和官方的团队领导在主持会议以便解决某个技术问题或者做出决策时，所采用的是最坏的方式。他们说得太多了，从某种意义上说，也许他们知道得太多了。作为一个领导，他的领导方式越强硬，对自由讨论的压制也就越大，这样就不可能从众多的选择中或是从“一致意见”方式中获取最好的结果。

有一些管理者采取了一种完全撒手不管的方法，他们试图不参与技术问题有关的协同解决过程。然而，这种做法对他的团队来说并不是一个福音，他们失去了管理者具有的经验和专家意见；对于管理者，他失去了参与解决问题的乐趣。好的管理者是将讨论和会议变成一个意见中和器，自己努力保持站在与其他人员同等的位置上，学习如何才能不武断地贡献自己的知识。有些管理者可能永远也学不会怎么做到这一点，但是我所合作过的大多数管理者都学会了这种方法，作为团队一份子平等地参与技术讨论。

这就是晋升为管理者以后的生活。

摘自《计算机语言》杂志，第9卷，#3，1992年3月 KZBcwq8T9PIYTY35nuUo5orIdKYIxx/xA7r9v6I9NdYFfRArmRNuw5R5RgClOC9z