即便预设了会议时长，但似乎极少有人觉得全程保持对时间的关注很重要。

讨论问题遭到反对意见时，（尤其是领导）感觉自己的权威或者自尊收到侵犯。

大多数人在会议中的角色是听少数人说，因此时不时跑神很常见。

会议中总会出现两个人同时说话的时候，产生的争执在会议结束时也没有解决似乎也很常见。

对人的评估通常由领导完成，即便是360度环评，也往往只出现在要评估晋升和定奖金等时候。

因为自从加入公司的那一刻起，这些行为和其伴随的想法就已经是这样了。所以，大多数人不会太去思考一直以来的这些习惯是怎么来的，是不是可以改变。

但S3认为，贯穿组织生活的各种细节都是可以被更加有意识地改善的。

这是系列稿的下篇，正文如下。

Photo by rawpixel.com from Pexels

7. 是否对“反对”和“同意”的本质有意识

大多数时候，当一个人提出的想法被另一个人反对时，两个人很快就陷入争论。反对的理由也许各种各样，小到对未知风险的担忧、大到和公司价值观不符、以及一些不能直接说出的办公室政治理由。

而另一方面，当一个团队“同意”某件事情的时候，大多也不会是全员都非常认可一个方案。有些时候出于种种原因，可能不会直接说出反对意见，还有些时候由于自己其实不够了解解决方案的来龙去脉，也说不出什么反对意见。所以，在不敢反对、不想反对或者不知如何反对的假象里，团队经常”同意“做某件事情。

但是真当做这件事的时候，又会不断出现分歧和争执。

从S3的视角出发，为了更高效地协作，就需要团队能够更高效地“反对”和“同意”，为此，我们首先要能够对这两个概念做出准确的定义。

反对意见可以是：给出一个理由，指出为什么某件事情会阻碍对某一特定驱动因素做出（更加）有效的响应。反对意见可以提出一种改进途径，或者解释一种对驱动因素可能的损害。

如此提出反对意见要求每一个人都时刻保持我们对于共同的why的认识，而且这个反对意见一定是要合理地阐明为什么对目前的解决方案有害。这能防止争论点不知觉地跑偏。

当然，如果只是有担忧，但又说不上来具体的反对原因，S3认为这也是要说的。因为你的担忧也许可以帮助其他人想出有效反对的点。

但是，表达担忧不会阻碍方案推进。S3认为达成同意，并不是非要所有人都消除顾虑，不然几乎总无达成一致的可能。

导师提出了“同意”的原则是，“眼下看足够好，尝试一下也足够安全/good enough for now, safe enough to try"。

所以，当团队对当下的结果没有反对、只有担忧时，就算满足了“同意”的原则。（当然这背后是一种实验主义的精神，边摸索边发展，显然和花几个月把方案想好了再行动的风格不同，这又回到了第一篇中对问题种类的认识）

那当出现反对意见时，我们怎么处理呢？（流程如下图）

首先，按照我们上述的原则表达反对意见，然后全组共同确认是否理解该反对的意思，并且验证这这个反对是否合理，即其能说明潜在损害或是有立竿见影的改善方法。

然后问反对者或者其他同意这个反对意见的人，是否有办法对当下的方案做出修改。

接下来，看组内是否对该修改方案有反对意见：

如果有反对意见，那么新的反对人就要再重新走一遍这个上述流程。

如果没有反对意见，那么再次聚焦整个提案，看对已经修改过的版本是否还有反对意见：

如果再有反对意见，那么依然重复上述流程。

如果没有，则庆祝我们全体“同意”了该行动方案。

例如，当时我们的模拟小组就出现了一个争论。提案中的一条行动方案是：选择5家企业进行调研，以理解他们“组织创新的痛点”。一位组员提出的反对意见是，我们需要先确定选择调研企业的标准，确定什么类型的公司是值得访谈的，比避免浪费时间在不符合标准的对象上。

另一位组员对这个反对意见表示反对，因为他觉得在开始调研前就确定调研的标准，有可能会直接错过一些有价值的对象。