读大道至简之我见2——关于团队沟通

近日花了一些时间在读周爱民老师的<大道至简>，全书整体来说是本好书，不过有些部分却不是很认可，在这里来谈一下，对于整本书观点，我的一些看法。

1. UML之我见

从书中的文字中，我隐约感觉到爱民老师对UML是比较反感的，以至于出现了这样的文字：

程序员不能要求客户会C，难道需求分析师们就一定要求客户会UML么？

项目文档真的可以用甲骨文来写。

我不了解爱民老师为何会对UML有如此看法，其实在我看来，的确，项目文档可以用甲骨文来写，如果项目组都认识甲骨文的话。

UML的核心在于Unified上，也就是统一。就像我们说为什么制作一个网页需要用HTML语言呢？我们不用<br/>而改用<rb/>不也一样么？W3C最大的贡献不是为我们发明了一个语言，而是为我们发布了一套规范，让我们每个程序员都可以通过HTML来沟通。

正如设计模式一样，其一，他为我们提供了某类问题的解决办法，而另外的贡献还在于它为我们程序员提供了这样一个通用的语言。当遇到某某问题时，如果没有设计模式，我们可能要画图，写方法，然后讲好久才能跟另外一个人说明自己的意图，但是有了设计模式，我可能只需要一句话：这个要用工厂模式来解决，大家都明白了我的意思。

就像我们可以自己做一个编译器，发明一种新的语言，然后使用这个语言，没什么不可。但是前提条件一定是，团队成员熟悉你发明的语言，新加入团队的人也要懂你的语言。

那么也就是说，用 UML 写文档最大的好处时，团队成员，还是新加入的成员，都可以读懂你的UML图，减小了适应和沟通成本，这就是UML的最大价值之所在，这也是标准的力量。

2. 团队中的讨论

每个做技术的人都懂，与人讨论，说出自己的想法，倾听别人的想法，是对自己最大的提高。这是对于技术问题。

有句话是“三个臭皮匠，凑成一个诸葛亮”。这也说明了在一个项目中，或者一个团队中，讨论的重要性，只有一群人交流，才可能会迸出奇迹的火花。

而具有最终决策权的管理者，究竟应该如何看待这样的讨论。

爱民老师的话很有道理：不要把沟通目标设定为“让对方认同”。

在我们没有办法把事情讨论清楚的时候，旁观者最清。因此这个时候，作为管理者，作为决策者，你应该跳出这场讨论，作为旁观者去观察，去思考，只有作为这个角色，你才是最清醒的。

作为管理者，你可以适时地停止这场讨论，但是并不意味着这次讨论就划上了句号。而是讨论暂时不清楚就先让他不清楚，让需要讨论的人（而不是整个团队）继续去讨论。

你不要给这次讨论试图做什么总结，这次讨论，管理者需要做的是，为他们营造环境，让讨论的几个人，在其他的时间把这次讨论继续下去，而你，要做的一直是个旁观者，倾听者，思考者。