除非所有的参与成员都认可通过讨论所得出的结论，否则所达成的就不能称为“一致意见”。这意味着，如果软件开发团队试图达成一致意见，他们必须首先确定一些标准，用于评论最终达成的结论，诸如：什么是重要的？什么是比较麻烦的？在一个特定的项目中“好”和“不好”的界定标准是什么？

很多时候，当一个软件开发团队尝试就软件分析、设计问题达成一致意见时，往往会陷入困境。他们会说：“我们不能决定该按照哪种方式进行下去了。”这时，我就问他们：“你们如何知道哪种方式更有效呢？”从某种意义上说，工程学的目的就是进行综合，在某一方面放弃一点，然后从另一方面获得更多。在一个特定的项目中，想要达到这种综合效果，软件开发团队必须知道在综合过程中所放弃的东西和所得到的东西的价值，以便从中获得最大的利益。

几乎在所有的工程学中，一个项目所要达到的各种指标之间都存在竞争关系。如果期望在各个方面、各个细节上都完全平等地满足指标，那是根本不可能的。大部分项目所追求的目标都是经济和技术的混合体。软件开发团队希望最终的软件产品能够及时交付、高效运行、方便使用、系统扩展性好、易于维护、极具市场前景、可以满足各种不同层次的用户。但是，如何综合这些指标呢？

设置优先级

设置优先级有助于解决上面的问题，质量专家很可能会建议你采用量化的方式，为每个指标设置不同的加权指数，并将最后要得到的结论简化成一个数学公式。但是，采用这种方法，既没必要，效果也不明显。其实，只需对各种指标进行简单归类，设置相应的优先级就足够了。在进行软件分析和设计时，当需要对各种指标进行综合汇总时，我们很难获得足够的数据来进行精确量化处理。如果把一大堆臆想出来的“估计值”放到一个伪造出来的公式中，那得到的只能是一个极具欺骗性的“伪客观”结论。这种做法甚至会成为开发团队逃避责任的一种借口，“你看，我们可是按照公式得出的结论进行的，如果屏幕更新需要17秒的话，那一定是哪个地方出问题了，但不可能是我们的错。”

在开发团队中，如果大家采用一同制订指标优先级的方法，会有助于提高开发人员的责任心。团队可以先找出最基本的指标，然后按照这种思路，为每种指标设置相应的优先级，在软件开发中按照优先级的高低来满足不同的需求。结论一旦达成，就没有必要重复讨论各种指标的优先级了，开发人员应该把更多的时间用于开发，而不是技术讨论。当然，没有必要为了解决一个小问题，也采用将其分割成七八个指标的做法，那样反而会降低开发效率。只有当需要做出决策时，才按照所制订的指标列表进行讨论。另外，也有必要隔一段时间把所制订的指标列表拿出来修改一下。

争论与对话

缺乏明确的标准并不是达成技术性一致意见的唯一障碍。在软件开发团队内部，只有通过自由的讨论才能达成一致意见，而且这种讨论本身也是一件很有意义的事情。但是，过分强烈的讨论，很有可能会演变成争论，甚至是恶意的争论。但是，不管是法庭式的辩论模式还是政客式的辩论模式，对于那些希望达成一致意见的软件开发团队来说，都是不值得效仿的。那些从事设计和开发的团队，在达成一致意见的过程中，无论大家所提出观点和方案是否对立，需要注意的就是，不要把团队变成一个充满争论的社团。

有一个学习面向对象技术的培训班，培训班分成了多个小组进行学习，其中一组的成员曾经向我抱怨说他们的工作无法进行下去了，原因很简单，他们陷入了无休止的争论，他们所取得的进步比同一培训中的其他任何一个小组都要少。

我自己观察了这个小组的工作——如果那种行为可以认为是工作——并很快发现他们之间进行的讨论完全被一个人控制，这个家伙拥有极佳的辩论素质，是一个非常棒的辩论高手，只可惜他的意见并不像他的辩论技巧那样高超。当组内其他成员指出他的意见中的缺陷时，争论就发生了。最后就变成“我不这样认为”或是“我认为这样做，感觉起来不太好”。

实际上，这个家伙的动机还是好的，他只是希望让工作进行的更好一些。因此，我让他来做小组讨论的主持人，他专门负责两个任务：确保整个讨论不要被一个人或者一种意见所支配；帮助那些不敢发言的人和表达不清晰的人，将他们真实的想法和意见以更有逻辑性的方法清楚地表达出来。

如果我们的初衷是从讨论中获得最好的结论，那么我们肯定不希望把那些善于辩论的人的意见当做最终的结论，如果把那些嗓门大的人的意见当成最终结论，事情就会变得更滑稽。为了避免这种现象的发生，争论的受益者应该是整个团队，而不是某个人或者某个小团体。讨论的目的是为了平衡各方的意见，并从各种意见和分析中挑取优点，并对其进行综合，而不是为了让那些具备高超辩论技巧或是嗓门大的人赢得一次讨论。

在讨论中，如果各方意见不能达成一致，可以试试下面的方法，效果会非常理想。让讨论双方互换角色，为对方的观点进行辩论；让辩论能力强的人去讨论技术性更强的问题，而不是概念性的问题。“嘿，Mavis，你很擅长这个啊，那你试试能不能说服我们，让我们都同意Greg的意见。”或者可以说：“让我们把这个理由用于解释那个意见，看看会怎样。”

技术性一致意见是对话和谈判的结果，而不是争论和辩论的结果。在其他的领域中，有很多谈判的技巧和方法，它们会对软件开发有所帮助。我向大家推荐两本非常好的书，它们介绍了“哈佛谈判项目”（Harvard Negotiation Project）中的成功经验，一本是《Getting to Yes》（如何让对手说“是”，Fisher and Ury，1981），另一本是《Getting Together》（团结起来，Fisher and Brown，1988）。

如果使用谈判方式来达成一致意见，那必须注意下面的问题。在谈判中，谈判双方在谈判之前实际上已经对自己的位置和形势做出了判断，需要更多关注和讨论的问题实际上早已确定下来。双方并不是开诚布公的，而是各怀心思的，实际上双方都很清楚要谈哪些问题。因此，通过谈判更容易达成的是折衷，而不是一致意见。这样，在谈判中，很容易出现双方针锋相对的情形。

有时，最简单的方法往往能解决最复杂的问题。“哈佛谈判项目”就指出，让谈判双方并排坐在一起面对“他们共同的问题”，比让双方隔着桌子面对坐着谈判会更好地促进谈判进程。我发现，在软件开发团队中开展讨论时，让对立的双方坐在一起，面对一块白板，或是面对一个投影仪，会加快讨论的进程，并对问题的解决起到促进作用。

整合建议

有时候，为了顺利开展下一步工作，需要进行一些前期准备工作或是利用一些原有的工作成果，这种现象是不可避免的。举例来说，在同一个公司内部，两个不同的小组分别开展前期准备工作，两者都想充分利用前期工作的成果，而且都不想放弃自己工作的成果。在某些公司中，为了开发某个自行研制的产品，甚至在公司内部展开设计竞争。通常情况下，当需要进行系统整合时，竞争者都会倾向于自己的方案，他们会努力向大家介绍和描述自己的方案。如果采用以下方法，会有助于达成一致意见。可以安排一个专门的人员，他保持中立的立场，在各竞争者介绍自己的方案之前，负责向大家介绍各种方案。另外，一种平和的讨论气氛也有助于达成一致意见。应该鼓励参与者去发现对手方案的优点和长处，而不是专门揭短。整合工作应该从实际出发，“对我们来说，既然尽量发现系统中的漏洞要比假设系统是完美的更重要，那么大家能不能都谈一谈自己方案的缺陷呢？”

如果不同的小组最后都要按照讨论出的最终方案展开后续工作，那么当首次讨论完成后，每个小组都应该尽量地吸取对方方案中的优点，改进自身的方案，这样在以后的讨论中，大家就会发现，相互之间有很多意见都变得一致了。

通常来说，技术性一致意见综合了各种备选方案的优点，甚至超出了任何一种方案的优点。要达到这种效果，可以从讨论问题出发，这要比从讨论某个立场或讨论某个特定的技术建议出发更有效。团队的首要任务就是探讨并解决各种基本的技术问题，这些问题代表了各种可能性、潜在原因以及技术可行性，而讨论这些问题可以反映出每个人所处的立场和所建议的解决方案。

为了达成一致意见，在第一次会议之前有很多工作要做。举例来说，如果让团队的成员考虑一个文件结构的问题，那么他们的思路应该被限制在设计一个有效的文件结构的范围内；他们应该列出各种标准，并为这些标准设置相应的优先级；甚至应鼓励他们采用不同的设计思想和方案。如果在团队中大多数的人都是那种桀骜不驯的性格，那首先要做的是尽量地控制他们不要过多的争论。

摘自《计算机语言》杂志，第9卷，#5，1992年5月 jxZrH0lU7DBzpIo447MaJeK7rjci1ZyivJoiL0BW6x971akgODlYBLmRqtPEFiNi