一个软件开发公司如果想要在项目中获得最大限度的成功，取决于软件开发公司中的成员能否形成技术性一致意见。但为什么这点如此重要呢？是不是软件开发公司只要在诸如目录表格的布局上达成一致，或者建立一个很好的错误汇报机制就行了呢？技术性一致意见指的并不是与同事打成一片就可以了（当然，这也不是说在同事之间建立良好的关系有什么错误）。技术性一致意见是指充分吸取软件开发公司中每个成员的技巧和经验，其目的是为了开发出更好的软件。

软件开发人员也许能够迅速理解一款好的软件，至少当他们看见一个好的软件时会宣称自己能够理解它，但是，在软件开发者中，很少有人能理解技术性一致意见。可能许多软件开发者会说，我们以前使用过一致意见的方法来解决问题，但是效果非常差，他们还会举出许多例子，比如，一些很棒的构想就是在不断的讨论中葬送了，最后为了所谓的整体性只得做出妥协；本来 6 个月可以完成的项目最后拖了 1 年：软件开发公司的能力也没有完全发挥出来。但如果仔细地听听他们的意见，你就会意识到他们所说的解决问题的方式根本就不是技术性一致意见，而是折衷。那么，二者之间有什么差异呢？

折衷意味着所做出的选择是一种似是而非的东西。既不是甲，也不是乙，而是一个介于二者之间的东西。我们可以通过一个典型的例子来说明。如你的软件开发公司正在开发一个图形用户界面的项目，一部分人强烈建议直接将控制按钮放在屏幕底部，而另一部分人建议在屏幕的左侧放置一个控制窗体。在这两种意见中，一种是水平放置，一种是垂直放置，形成了两个极端。那么，一个最具有代表性的折衷方案就是，将控制按钮沿着对角线放置在屏幕的中央。

就像上面的例子所描述的，由折衷所产生的解决方案常常要比任何一个原有的方案都要差劲。但是技术性一致意见就恰恰相反，它所产生的解决方案要比任何一个原有的方案都要好。如果不使用技术性一致意见，往往会由于顾忌到每种备选方案的优点，而采用优点均衡的方式，但实际上每种备选方案的优点也就丧失了。真正的一致意见不是基于那种让每个个体都做出让步的折衷，而是基于综合的，新的综合体要比原有的任何一个个体都要好。最后的结局就是，开发出了更好的软件。

一个综合体是一种具有新颖性的新个体，是集成了原有的每个建议和方案的本质特征的个体。在上面所说的界面设计例子中，可以明显地看出，一个具有创造性的综合方案是给控制按钮窗体加上选项，由用户来决定是采用水平放置还是采用垂直放置。一致意见的方法不仅仅是将各种选择方案的优点集中起来，而且综合方案还体现了新的特性和功能。通过集成水平放置和垂直放置这两种方案，我们可以实现终端用户定制。这样，最后的软件产品就集成了各种方案的好的方面，而不是坏的方面。

形成真正的一致意见并不是一件容易的事情，那些政客和工人谈判代表们对此深有感触。达成一个技术性的一致意见与达成一个政策性的一致意见是有所不同的，但是有些本质特征是基本相似的：二者都需要制定一些约束条件以达成共识，参与者在讨论过程中都需要保持一种信念。

软件开发公司必须坚信，从每个人的意见中提取出最好的方面并将其综合起来，就此形成一个技术性的综合体是完全可能的。只有坚信这点，成员们才有可能坚定不移地寻找最好的解决方案，而不是轻易地折衷或者固执己见。每个成员发表自己对问题的看法，讲述方案的优缺点，通过坚持不懈地努力，成员们可以提高形成具有创造性方案的可能性，而这种创造性的方案会比原有的任何方案都更好。

当每个成员都相信开发一个好的软件要比在软件中使用自己所喜爱的方案更重要时，一致意见式的设计会发挥更大的作用。如果我们注重最终软件产品的质量，在软件开发公司讨论过程中会更容易发现每种意见的优点。

如果软件开发公司中的成员不是独自炫耀个人能力，而是认同联合协作的工作方式，那么对于软件开发会更有帮助。有些公司愿意奖励杰出的个人，而不是奖励软件开发公司；或者晋升那些惯于单打独斗，特别是那些不会也不可能与他人共事，常常一个人解决问题的程序员，而不是表彰整个软件开发公司。这样的公司会做出如下论断：最好的软件是他们的天才程序员开发出来的。这些公司意识不到，除了这种方法以外，其实还有其他的方法可以达到更好的效果。

在建立技术性一致意见时，一个必须遵循的原则就是：绝不能以货易货!对于政客们来说，采用以货易货的贸易方式是一种获得成功的经典策略，但对于技术性一致意见而言，这是有害无益的。举例来说，在上面的界面设计例子中我们可以采用以货易货的方式，如果让我同意你的愚蠢方案，将控制按钮窗体放在屏幕底部，那么你就要同意我聪明的设计思想，加上没有标签的图标。最终的结果就是，界面不是最好，而只是一个具有两个普通特性的界面。这种以货易货的策略其实是另一种形式的折衷，而折衷之所以糟糕