高效程序员的10个习惯之一 对事不对人

 

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

 

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

 

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

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

 否定个人能力。


指出明显的缺点，并否定其观点。

 询问你的队友，并提出你的顾虑。

 

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

 

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

 Venkat
如是说……

要专业而不是自我

多年以前，在我担任系统管理员的第一天，一位资深的管理员和我一起安装一些软件，我突然按错了一个按钮，
把服务器给关掉了。没过几分钟，几位不爽的用户就在敲门了。

这时，我的导师赢得了我的信任和尊重，他并没有指责我，而是对他们说：
“对不起，我们正在查找是什么地方出错了。系统会在几分钟之内启动起来。”这让我学到了难忘的重要一课。

 

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

 

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

 

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

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

 

团体决策的骆驼

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

 

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

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

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

 

设立仲裁人
。
在会议的开始，选择一个仲裁人作为本次会议的决策者。每个人都要有机会针对问题畅所欲言。仲裁人的责任就是确保每个人都有发言的机会，并维持会议的正常进
行。仲裁人可以防止明星员工操纵会议，并及时打断假大空式发言。

如果你自己没有积极参与这次讨论活动，那么你最好退一步做会议的
监督者。仲裁人应该专注于调停，而不是发表自己的观点（理想情况下不应在整个项目中有既得利益）。当然，这项任务不需要严格的技术技能，需要的是和他人打
交道的能力。 

 

支持已经做出的决定。
一旦方案被确定了（不管是什么样的方案），每个团队成员都必须通
力合作，努力实现这个方案。每个人都要时刻记住，我们的目标是让项目成功满足用户需求。客户并不关心这是谁的主意——他们关心的是，这个软件是否可以工
作，并且是否符合他们的期望。结果最重要。
设计充满了妥协（生活本身也是如此），成功属于意识到这一点的团队。工作中不感情用事是需要克制力的，而你若能展现出成熟大度来，大家一定不会视而不见。
这需要有人带头，身体力行，去感染另一部分人。

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

 

切
身感受 

一个团队能够很公正地讨论一些方案的优点和缺点，你不会因为拒绝了有太多缺陷的方案而伤害别人，也不会因为采纳了
某个不甚完美（但是更好的）解决方案而被人忌恨。 

平衡的艺术 


尽力贡献自己的好想法，如果你的想法没有被采纳也无需生气。不要因为只是想体现自己的想法而对拟定的好思路画蛇添足。


脱离实际的反方观点会使争论变味。若对一个想法有成见，你很容易提出一堆不太可能发生或不太实际的情形去批驳它。这时，请先扪心自问：类似问题以前发生过
吗？是否经常发生？


也就是说，像这样说是不够的：我们不能采用这个方案，因为数据库厂商可能会倒闭。或者：用户绝对不会接受那个方案。你必须要评判那些场景发生的可能性有多
大。想要支持或者反驳一个观点，有时候你必须先做一个原型或者调

 

查出它有多少的同意者或者反对者。


在开始寻找最好的解决方案之前，大家对“最好”的含义要先达成共识。在开发者眼中的最好，不一定就是用户认为最好的，反之亦然。


只有更好，没有最好。尽管“最佳实践”这个术语到处在用，但实际上不存在“最佳”，只有在某个特定条件下更好的实践。


不带个人情绪并不是要盲目地接受所有的观点。用合适的词和理由去解释为什么你不赞同这个观点或方案，并提出明确的问题。