魔鬼告诉你：你在这个设计上投入了很多精力，为它付出了很多的心血。你坚信它比任何人得设计都棒。别听他们的，他们只会把问题变得更糟糕。

你很可能见过，对方案设计的讨论变成了情绪化的指责——做决定是基于谁提出了这个观点，而不是权衡观点本身的利弊。我们曾经参与过那样的会议，最后闹得大家都很不愉快。

但是，这也很正常。当Lee先生在做一个新方案介绍的时候，下面有人会说：“那样很蠢！”（这也就暗示着Lee先生一样很蠢。）如果把这句话推敲一下，也许会好一点：“那样很蠢，你忘记考虑它要线程安全。”事实上最适合并且最有效的表达方式应该是：“谢谢，Lee先生。但是我想知道，如果两个用户同时登录会发生什么情况？”

看出其中的不同了吧！下面我们来看看对一个明显的错误有哪些常见的反应。

    否定个人能力。
    指出明显的缺点，并否定其观点。
    询问你的队友，并提出你的顾虑。

第一种方法是不可能成功的。即使Lee是一个十足的笨蛋，很小的问题也搞不定。但你那样指出问题根本不会对他的水平有任何提高，反而会导致他以后再也不会提出自己的任何想法了。第二种方法至少观点明确，但也不能给Lee太多的帮助，甚至可能会让你自己惹火上身。也许Lee能巧妙的回复你对非线程安全的指责：“哦，不过它不需要多线程。因为它只在Frozbot模块的环境中使用，它已经运行在自己的线程中了。”哎呦！忘记了Frozbot这一茬儿了。现在该是你觉得自己蠢了，Lee也会因为你骂他笨蛋而生气。

现在看看第三种方法。没有谴责，没有评判，只是简单地表达自己的观点。让Lee自己意识到这个问题，而不是扫他的面子。由此可以开始一次交谈，而不是争辩。

                               要专业而不是自我
多年以前，在我担任系统管理员的第一天，一位资深管理员和我一起安装了一些软件，我突然按错了一个按钮，把服务器给关掉了。没过几分钟，几位不爽的客户就在敲门了。
这时，我的导师赢得了我的信任和尊重，他并没有指责我，而是对他们说：“对不起，我们正在查找是什么地方出错了。系统会在几分钟内启动起来。”这让我学到了难忘的一课。

在一个需要紧密合作的开发团队中，如果能稍加注意礼貌对待他人，将会有益于整个团队关注真正有价值的问题，而不是勾心斗角，误入歧途。我们每个人都能有一些极好的创新想法，同样也会萌生一些很愚蠢的想法。

如果你准备提出一个想法，却担心有可能被嘲笑，或者你要提出一个建议，却担心自己丢面子，那么你就不会主动提出自己的建议了。然而，好的软件开发作品和好的软件设计。都需要大量的创造力和洞察力。分享并融合各种不同的想法和观点，远远胜于单个想法为项目带来的价值。

负面的评论和态度扼杀了创新。现在，我们并不提倡在设计方案的会议上手拉手长《学习雷锋好榜样》，这样也会降低会议的效率。但是，你必须把重点放在解决问题上，而不是去极力证明谁的主意更好。在团队中，一个人的智商高是没有用的，如果他还很顽固并拒绝合作，那就更糟糕。在这样的团队中，生产率和创新都会濒临灭亡的边缘。

我们每个人都会有好的想法，也会有不对的想法，团队中的每个人都需要自由的表达观点。即使你的建议不被全盘接受，也能对最终解决问题有所帮助。不要害怕受到批评。记住任何一个专家都是从这里开始的。用Les Brown的一句话说就是：“你不需要很出色才能起步，但是你必须起步才能变得很出色。”

                                        团体决策的骆驼
集体决策确实非常有效，但是有一些最好的创新源于很有见地的个人的独立思考。如果你是一个有远见的人，就一定要特别尊重别人的意见。你是一个掌舵者，一定要把握方向，深思熟虑，吸取各方的意见。
令一个极端是缺乏生气的委员会，每个设计方案都需要全票通过。这样的委员会总是小题大做，如果让他们造一匹木马，很可能最后做出的是骆驼。
我们并不是建议你限制会议决策，只是你不应该成为一意孤行的首席架构师的的傀儡。这里建议你牢记亚里士多德的一句格言：“能容纳自己并不接受的想法。表明你的头脑足够有学识。”

下面是一些有效的特殊技术。

设定最终期限。如果你正在参加设计方案讨论会。或者是寻找解决方案时遇到的问题。请设定一个明确的最终期限，例如午饭时间或者一天的结束。这样的时间限制可以防止人们陷入无休止的理论争辩之中，保证团队工作的顺利进行。同时应该现实一些：没有最好的答案，只有更合适的方案。设定期限能够帮助你在为难的适合果断做出决策，让工作顺利进行。

逆向思维。团队中每个成员都应该意识到权衡的必要性。一种客观对待问题的办法是：先是积极的看到它的正面，然后再努力的从反面去认识它。目的是要找出优点最多缺点最少的那个方案，而这个好办法可以尽可能地发现其优缺点。这也有助于少带个人感情。

设立仲裁人。在会议的开始，选择一个仲裁人作为本次会议的决策者。每个人都要有机会真的问题畅所欲言。仲裁人的责任就是确保每个人都有发言的机会，并维持会议的正常进行。仲裁人可以防止明星员工操纵会议，并及时打断假大空式发言。
如果你没有积极参与这次讨论活动，那么你最好退一步做会议的监督者。仲裁人应专注于调停，而不是发表自己的观点（理想情况下不应在整个项目中有既得利益）。当然，这项任务不需要严格的技术技能，需要的是和他人打交道的能力。

支持已经做出的决定。一旦方案被确定（不管是什么样的方案），每个团队成员都必须通力合作，努力实现这个方案。每个人都要时刻记住，我们的目标是让项目成功的满足客户需求。客户并不关心这是谁的注意——他们关心的是，这个软件是否可以工作，并且符合他们的期望。结果最重要。

设计充满了妥协（生活本身也是如此），成功属于意识到着一点的团队。工作中不感情用事是需要克制力的，而你若能展现出成熟和大度来，大家一定不会视而不见。着需要有人带头。身体力行，去感染另一部分人。

对事不对人。让我们骄傲的应该是解决了问题，而不是比较谁出的注意更好。

平衡的艺术
    尽力贡献自己的好想法，如果你的想法没有被采纳也无需生气。不要因为只是想体现自己的想法而对拟定好的思路画蛇添足。
    脱离实际的反方观点会使争论变味。若对一个想法有成见，你很容易提出一堆不大可能发生或者不切实际的情形去批驳它。这时请先扪心自问：类似的问题以前发生过吗？是否经常发生？
    也就是说，像这样说是不够的：我们不能采取这个方案，因为数据库厂商可能会倒闭。或者：用户绝对不会接受那个方案。你必须要评判那些场景发生的可能性有多大。想要支持或者反驳一个观点，有时候先做一个原型或者调查出它有多少同意者或者反对者。
    在开始寻找最好的解决方案之前，大家对“最好”的含义要先达成共识。在开发者眼中的最好，不一定就是开发者眼中最好的，反之亦然。
    只有更好，没有最好。尽管“最佳实践”这个术语到处在用，但实际上不存在“最佳”，只有在某个特定条件下的更好的实践。
    不带个人情绪并不是要盲目的接受所有的观点。用合适的词和理由去解释为什么你不赞同这个观点或方案，并提出明确的问题。