今天再看了樊登讲书的视频：《非暴力沟通》（Nonviolent Communication: A Language of Life），查阅相关资料时注意到这个英文名，直译过来就是《非暴力沟通：一种生活的语言》，作为一个从事编程开发工作的人来说，对“语言”是有一种特殊的情节的，既然是一种生活的语言，为什么不认真学习和了解一下呢？

书中主要讲述了以下几点内容：

在我们的沟通过程中，尽量：

  • 陈述事实及观察，而不是评论。
  • 体会并表达感受，而不是指责别人。用准确的词语描述真实的感受。
  • 明确自己的需求，而不令对方迷惑。
  • 准确提出具体的请求，而不是命令。
  • 学会倾听，理性表达愤怒，找到生活的热情。

克里希那穆：不带评论的观察是人类智慧的最高形式。

联想到日常公司的管理，做以下触类旁通的尝试：

事实观察 vs 评论：

只陈述事实和观察，是非常困难的一件事，我们从小到大形成的习惯，日常放松时的聊天，都已经非常自然地添加自己的评论和观点，这是每个人都具有的表达欲望所驱使的。

工作中可能我们要时常在心里提醒自己，多观察真实的情况，只陈述看到的或了解清楚的事实，而尽量不掺杂自己的评论和观点。我们当然也有责任和义务对一些工作事宜发表观点和评论，那怎么办呢？是不是改为建议会好些？或者改为陈述另外一些相关的观察是不是会好些？比如：“关于下阶段的目标，据我的了解，在类似的公司面临这样的情况时，是这样做的……，也许我们可以借鉴一下其中的这几点……，大家有什么好的建议吗？”。

另外很多时候事实和观点之间的区别很微妙，可能不刻意练习区分，时常是会混淆的，比如视频中的例子：“你最近经常迟到”，这就是一个掺杂了观点的陈述，而换做：”通过查看考勤记录，我发现你上周迟到了三次。“，就是一个事实的陈述了。

我们习惯表达中常用的一些词，一定要刻意避免：“经常”、“总是”、“一直”……

体会并表达感受 vs 指责别人

公司内部，同事之间，指责别人也是非常常见的现象，通常发生在追责文化比较盛行的公司里，比较好的时候可能是只说自己没责任，稍微情绪激动的时候，就会指出其他人的问题了。

这些也都是长期个人的习惯使然，我们日常生活中的对话，所接触的大量的影视剧中都充斥着类似的对白，我们会为精彩的怼人和反怼拍手称快、拍案叫绝。而我们接触真正非暴力而高效沟通表达的机会则太少太少，以致于多数人都是凭本能在进行着大量重要的沟通活动，结果当然可想而知，这世界充满着各种各样的矛盾、误会和悲剧。

我们国人受传统文化的影响以及父辈时代的教育影响，似乎特别疏于表达感受，一些欣赏、感激的情感可能被淡而化之，让对方感觉迷惑或被忽视等，而一些痛苦、愤怒的情感则被习惯性地压抑在心底，然后通过抱怨、牢骚等不太好的方式宣泄出来，造成不好的结果。

因此在公司的沟通交流中，我们一定要避免指责别人，即使是感觉有些事情结果不理想有所顾虑，也要克制自己的负面情绪，改为陈述事实和准确表达自己的感受。比如：“我看到你使用了……的技术方案，关于这种技术方案，我的了解是它具有……的优势，同时我也观察到在运用这种技术方案时，团队会需要做……的工作和保障，我有些担心后期的维护工作量会很大，从而影响我们的交付进度和质量。”。

明确自己的需求 vs 争论和妥协

自己要仔细思考并明确自己的需求，很多时候，我们习惯于宣泄自己的情绪而忘记了我们真正的需求，视频中有句话大意是说：每个愤怒的背后都隐含着某些需求。

公司日常沟通中，也经常会出现类似的情况，很多人忘记了根本的需求，而去与他人争论具体的实现方案，或者是用妥协的方式采取折中的方案，结果得到的可能都不是理想的方案，要么一方不满意，要么双方、甚至多方都觉得不理想，最终影响到具体执行的方案和结果。

那么一个要往左，一个要往右怎么办呢？

通常遇到这样的情况我们都应该冷静下来，先把双方争论背后的需求讨论清楚，你要往左走或往右走的原因是什么？目的是什么？是为了解决什么问题？等等……。也许有时候会发现大家的目的是一致的，方向是差不多的，只是一个倾向于先解决短期问题，另一个倾向于考虑长远问题等等……或者如果目标不一致，那么讨论目标就相对更有意义了。一旦讨论到总体目标或终极目标，通常大家都是有一致共识的。那么回到大家共识的边缘处，再仔细分析产生分歧的思考差异，就比较容易互相理解对方的出发点了。然后再结合头脑风暴等工具，也许能就找出理想的《第3选择》了，这也是一本非常值得学习体会的书。

另外一方面，明确自己的需求，在公司的管理中还体现在如何把需求清晰呈现的事宜上，这里可以特别提一下文字表达与口头表达的差异上，比如产品经理在梳理需求时就需要把需求明确表达在需求文档上，很多时候我们会发现口头表达快捷高效，但却容易出现理解的偏差、疏漏和歧义，当你尝试把自己脑海中的零乱思绪通过文字进行表达时，可能才能慢慢理清很多笼统的概念、错杂的关系等，很多新的需求或者细节的需求才会慢慢浮出水面，很多原以为的需求可能不攻自破，很多不切实际的需求可能也就被逻辑推理推翻放弃。因此我们应该鼓励把需求整理成有条理的文字，反复推敲其中的关系和逻辑，达到可以清晰指导具体的开发工作后再付诸实现。

准确提出请求 vs 命令或意会

国人的沟通习惯里还有一个喜欢意会的倾向，特别是领导者对于下属的行动要求方面，经常会缺乏耐心而懒得讲清楚。 这方面我们可以学习和借鉴一下日本管理中安排事情要反复五遍的精神和方法：

  • 第一遍陈述所要安排的事情；
  • 第二遍请听者复述一下所安排的事情；
  • 第三遍询问听者：公司对于此事真正的诉求和目的；
  • 第四遍询问听者：会遇到什么意外、问题或困难？哪些可以自己做决定，哪些需要及时汇报？
  • 第五遍询问听者：如果此事由他来决策，会有什么样更好的想法或建议？

具体详情参见此文。想到公司里产品经理提需求，领导启动项目，安排一件具体的任务，似乎都可以借鉴，不怕麻烦，耐心执行这个方法，一定是可以收到很好的效果的。比如公司梳理研发需求这件事：

  • 首先要用文档的形式记录下来，文档中要按用例故事的格式来描述具体的需求；
  • 其次，要开计划会议与开发团队进行一次深入的需求探讨和分析；
  • 然后，要对于这个需求所要达成的目标、背景、原因和真正诉求达成共识；
  • 在计划会议讨论期间，要分析可能遇到的意外、问题或困难等，以及各种情况发生时的相应预案；
  • 同时，在讨论期间，可以征询开发团队对于此需求的更好的建议和想法等，必要的时候可以及时改进和修订。

具体案例分析

例如有时候我们在会议上，听某同事讲了很长的时间，自己脑海里可能因此也激发起很多想说的内容了，甚至想反驳他的一些观点了，这时很可能就打断对方插话进去，并且直接抛出我们的观点和评论，这样自己自然痛快了，但会议可能就进入到一种相互争论而低效无果的状态了。

正确的做法是什么呢？

首先要学会倾听，认真地倾听，快速将对方所表达的重点和自己想表达的要点记录在本子上，多理解对方想表达的真实诉求，在对方停止的间歇，可以概要陈述一下自己对他表达内容的理解，陈述大家所公认的事实，以及自己对某些重点的观察。

之后开始陈述自己对这件事的一些感受，注意不是观点和评论，只是感受，比如：开心、愤怒、欣慰、感谢、赞赏、担忧、焦虑、迷惑等。

接下来理清从公司角度来分析，所真正需要的需求，通常真正的需求是非常容易达成共识的，如果有些需求没有达成共识，就可以针对具体的需求讨论，通过问五个为什么的工具，通常很快就能讨论出具体而清晰的需求了。

同时我们还要努力去识别伪需求和想象中的需求等，有很多需求、特别是客户的需求，很可能是我们想象出来的，有时候需要一些事实和数据的支持才能被认定为真正的需求，有时候一些需求可能是伪需求，当我们找到真正的底层问题并解决后，这个需求也许就不存在了，所以这类需求仍然可以通过追问五个为什么来逐渐变得清晰并被识别。

之后我们还要把需求进行优先级的排序，非常久远以后的需求可能就比较模糊，不够具体，也不容易落地实际操作，而我们将重点关注那些优先级较高的需求上，这样一个主题非常宽泛的会议就能够逐渐聚焦，会议也就更能高效，同时也就能真正得到具体可行的讨论成果了。

结语

当然以上这些方面，自己也是远远没有达到的，很多的错误沟通方式回想起来自己也是屡犯不止，现在将感想和理解记录在这里，和大家共勉吧……