最近再次遇到大项目和系统变更，讨论变得尤其频繁，但是很多时候的讨论在我看来很低效，讨论往往会变成对各自观点的一个辩护。这还不是最严重的问题，尤其困扰我的是，达成一致变得尤其困难，并由此导致需要再次约会讨论，浪费时间，且影响项目进度。 基于此，我思考了几个方面：
- 我们讨论的目的是什么？
- 我期望的有效的讨论是什么样子的？
- 如何解决参会方各自辩护而脱离讨论初衷的问题？
讨论我认为应该分为三大类，不同类型的讨论，对应的目的也会有所区别，而一个讨论可以被称之为高效，首先应该是达到了讨论目的的。
类型一：知识分享型
由某个知识传播者准备分享内容，参与讨论的各方就具体的知识加深理解，扩展思维。
这种类型应该是比较常见的，且因为往往会由一个相对资深的人来做分享，无形形成了一个意见领袖的角色。
对于这种类型的讨论，如果在这次讨论的过程中，填补了我的一个知识空白，或者对自己已有的知识体系做了完善补充，甚至纠偏，我会认为这次讨论时间非常有价值。
类型二：头脑风暴型
就某个问题，展开讨论，分析各种可能性，不管是问题原因也好，还是问题解决方案也好，总之是围绕一个问题，做各种发散性思维。
所以，这里的重点在发散，但是也有个前提是，围绕一个问题。但是其实在实施过程中，对问题的把握和发散的角度的控制，其实是比较难拿捏好的。
如果在这个过程中，收获到了更多更新的思路，并且这些思路对于解决问题提供了有效的帮助，那么这次讨论的目的就达到了。
类型三：协调行动型
这种也是在工作中经常见到的，随便一点的，两个人就代码怎么写争论不休，或者正式一点的，项目实施方案，参与的各方就实现细节各自表达各自的观点，难以统一一个最终的方案。
可以看到这种时候，讨论的目的就是各方就某个方案达成一致后，协调行动，制定下一步的工作内容和计划。既然是基于某个方案，就需要组织会议的一方在会议开始前准备好评审方案，针对这个方案，在会议中，各方讨论可行性后，制定可行性方案。
所以这种讨论的目的其实有两个：一个是充分暴露潜在的风险点，另一个就是达成理解和行动的一致，最终使得方案落地实施。
那么现在困扰我的其实就是最后一种，比如：
- 方案设计评审，参会方在理解上存在大量理解不一致的地方，各方就各方的理解各抒己见，导致很难在理解上达成共识。
- 方案设计各方理解一致，但在具体设计实施上，各方坚持各方观点，并为各自的观点辩护，继而导致会议偏题；更有甚者，会有人直接抛弃现有讨论方案，抛出自己的另一套方案。
理解上的不一致，需要由一个人出面，对大家的理解做一个统一的阐述，并基于此阐述，大家建立新的共同的理解。
对第二种，很多时候，两方为各自的观点争论不休的时候，经常陷入一个类似吵架的你来我往的气氛中。特别是当一个团队中，大家的工作背景和技术积累相差比较大，这种情况会尤其普遍。我也经常会在这种你来我往的讨论中，为如何快速达成一致结论而苦恼不已。
一个很消极但也很有效的解决方案是主动妥协，是的，很多时候，说服一个人太难，只要不是根本性问题，妥协下也无妨。但是我想，对于一个团队来说，当某些人渐渐采用妥协的方案去达成一致的时候，这个团队应该不能说算健康的团队，它会导致部分坚持争辩的人获胜，而忽略了讨论的初衷：达成一个更好的结果
那么如何解决这个讨论过程中各执己见的问题呢？
首先是明确讨论的目的，首先是暴露风险，那么当前的讨论是在围绕风险点在讨论吗？如果不是的话，那么双方讨论围绕的差异点在哪里？
既然两个人能就两个方案展开几个回合的讨论，那么这两个方案应该是没有太大的缺陷的。争论不休的原因，我想无非是两个人在权衡方案的时候，考虑的侧重点不一致。A说a方案这里好，那里好；B也会坚持自己的一个原则认为必须满足这么一个原则。没办法，系统方案设计没有十全十美的，就如同分布式系统的CAP三个指标，永远无法同时满足三个，所以设计方案讲的就是一个权衡。那么如果大家在考虑各个方案之前，事先对各个权衡要素能做到优先级对齐的话，我想会大大提高沟通效率，避免过多无用的争执。