前(xia)言(che)
上一篇写了如何开会，讲的是通过形式化的一些方法来有效的组织会议的高效进行，避免出现一会开一天的状况。写完了如何开会，现在写如何沟通。因为会议的本质是沟通，如果沟通不好，会导致工作中的出现巨大的失误。失之毫厘，谬之千里。
沟通有好多种类：
- 维持沟通氛围
- 表达自己的想法
- 否定别人表达的内容。理论上否定，事实否定(打脸)
- 逐项讨论
- 总结、交接任务
维持沟通氛围
最常见的维持沟通氛围的，是会议主持。比如春晚等晚会，或者政府工作报告等正式会议，都是需要一个主持人，有开场词，转场词，结尾词等。
可能很多搞技术的人认为这是不必要的，但是我认为其实这是非常有必要的，而且极度重要。
虽然说的话都是套话，既没有表达什么实际的意义，也没有解决什么问题，但是这是流程控制。
编程过程中，不是每一步都要进行运算的，这里的沟通氛围相当于指针或者是函数调用了(当然函数调用的本质也是指针)。
这方面的沟通我没什么文学上的造诣，但是有一点想说的是这个部分一定要有。会议的讨论过程中，大家经常聊着聊着就发散到不知道哪里去了。这个的本质还是千米说的流程控制，有了流程控制，会议的效率会提升一大截。
尤其在会议刚开始，确认今天会议都有哪几项，逐条列出来一一进行，或者最后进行总结等，让每一位参会的人能感知到我们整个沟通走到了过程中的哪一步。
表达自己的想法
表达自己的想法是一门很大的学问。市面上有各种个样的书籍在讨论，然而我不是一个学习派，我是实践派，我喷过很多人，也吃过很多亏，慢慢学会了如何表达自己的想法。
一个人在讲话的时候，所选择的词汇和语法可能并不完全符合他所想要表达的内容，经常有一些口误导致的误会，这就是最典型的案例。另外，哪怕是他内心想要表达的内容，可能并不是他内心最迫切的需要，这方面在很多内向的女生身上表现得比较明显，还有一个词语“口是心非”，大概也是说的这样。
一个人在听别人讲话的时候，并不一定是完完全全集中注意力的，哪怕是一个热衷于拍马屁的下属在听领导讲话。上学的时候，我们都有走神的时候，其实那时候不知道脑子里在想什么，也可能什么都没想，等回过神来，发现已经跳过去一大段了。
即便是我们认真听了，我们对很多语句的理解也是不同的。以我们团队为例“组件”这个词，由于每个人对这个词语的定义不一样，最终理解不一样，有人认为是硬件，也有人认为是一个应用就可以认为是一个组件，在这个事情上我们吃过很多亏，后来终于学会了，遇到一个有可能误会的词汇的时候，我们先拿出来聊一下大家对这个词是怎么理解的。(诺，这就是流程控制，跳转到了getWordDef函数，哈哈)
即便是我们对词语有相同的认知，也一直在认真听内容，我们由于不了解讲话者所处的环境，或者我们内心对讲话的内容并不认同，我们可能对内容的接受度也是不一样的，那个喊狼来了的小孩子，大家都知道他在说什么，可是大家都没有接受。
在表达自己的想法的时候，一定要注意这部分内容。
这里就写这么多吧，我估计多了我也说不清楚了。
否定别人表达的内容
要是肯定别人表达的内容，那就比较简单，点点头，或者把对方的话用自己的理解重复一遍，对方就会知道你理解并且肯定了对方的表达。
否定别人就有点意思了，这里分为理论上的否定和事实上的否定。
理论上的否定，那挺简单，把对方的理论举出反例即可，或者以理辩理，说出对方的逻辑错误来。当然，在表达的时候一定要注意照顾对方的感受，尤其是对方是你老板的时候(微笑)。
事实上的否定，在当下有一个火热的词，叫做“打脸”。确实是非常生动形象的一个词，但是其实在打脸的时候，也是要考虑对方的感受的，人不能争一时之勇。
逐项讨论
逐项讨论是一个比较耗时但是非常高效的沟通方法。使用这样的方法的时候一般都是对一个事情有共同目标的时候，双方带着各自的观点或者利益方来进行商讨。
最常见的，比如某个销售有一天突发奇想，想要做一个山寨的淘宝，那么他就会拉着程序员开始逐项讨论。
销售会首先问做这个需要多长时间，其实本质上关注的是用多少成本。
然后程序员就会说：“这要看你要什么功能了”，其实这是因为需求才是决定成本的唯一因素。
销售会继续说，”能展示产品，还能够进行费用结算“。这当然是表面上能够看到的需求。
那么程序员继续说，”既然能展示产品、费用结算，那么要不要一个用户中心，毕竟每个用户都有自己的费用和购物信息。另外，要能展示产品是不是要显示库存，因为用户买一次库存就会减少一件“，这里程序员就把隐性的需求给列了出来，说明这是一个稍微有一点经验的程序员，因为没有经验的程序员可能不会去想那些隐藏的需求，然而特别有经验的程序员会建议他直接去淘宝就可以了，没必要造轮子。
上面这一段是一个逐项讨论的过程，双方会不停的推进和撤退，列出的每一项都会有一个小的结论，最终达成一个共识。
总结、交接任务
这才是本文的重点，因为不管是维持氛围也好，表达或者否定也好，或者逐项讨论也好，最终都是要形成一个结论的。如果一次沟通最终没有达成一个结论，那么这是一次非常失败的沟通，双方都浪费了时间和精力在这上面。当然有时候有些沟通的结果是发现大家最终谈不来，那就一排两散，这也算是一项结论。
总结就是把前面逐项讨论的节点最终一一确认下来，不要讨论完了最后结果给忘了都讨论了哪些事情。因为人的讨论是一个运算过程，而记录是一个存储过程。
对于交接任务，则是决策者在沟通总结之后，把任务进行交接给执行的人。这里最常见的是上级把工作交接给下级，甲方把工作交给乙方，或者乙方接口人把任务交接给执行部门的人。
任务的交接主要包含两个方面：
- 任务的发送
- 任务的接收
任务的发送
任务发送的关系人越多越好，因为大家了解的越多，后续工作的开展越是方便。因为大家都处在同一个环境中，在同一个Flow里面去思考问题，解决问题。沟通的成本就会极度降低。
当然如果有需要保密的事情，那当然不能告知太多人。
- 任务的发送方，首先要想的是，自己接下来要发的这个任务，是要什么，能给什么。或者说，为什么在这里做这个事情。在发送任务之前，就先要确认好，事情的利害关系，以及所有的相关人，包括邮件任务中出现的上级，这时候也要计算进去。
- 把任务一条一条列出来，写清楚，这里可以参照SMART原则来写事情。每件事要有一个结束项，有一个评审的标准。也尽量有放弃的成本。必须要对任务有一个非常清楚的描述，甚至包含一个背景的描述，因为团队中有的人并不在同一个Flow中。
- 要对接收方告知，这其中的每一条分别是什么含义，一定要解释清楚，尤其要留意的是其中的一些词汇双方可能有不同的理解。
- 如果方便的话，尽量让任务接收方重复解释一遍任务，这样的反馈机制能够保障下达的任务是OK的，没有问题的。这里比较方便的方法是结束的时候把草纸留给对方，或者双方拍照分享会议讨论的内容。
- 在交流结束后，要再发一封邮件来核实内容。一方面，能够让相关人员方便确认；另一方面，同时也是告知利益关系人，本次都有哪些事情需要处理。个人实践证明，这样的事情真的太有必要了。
- 最后一条，不要在有情绪的时候做决定（不要再生气的时候说分手）。这个应该算是一个禁忌，希望大家不要碰。
任务的接收
任务的接收方，一般来说是“拿人钱财替人办事”，既然这样，那就一定要把任务接收清楚。
像我这样脑子不好用的，可能别人吩咐一句我转身就给忘记了，那怎么办呢？
记下来啊！
如果是工作安排，一定要每一条都记录清楚。不管对方是否后续会不会发邮件。可能很多人觉得没必要记录，其实内心里可能是觉得，记录一条需要对方等那么半分钟几十秒，会陷入一个短暂的尴尬。
我觉得几十秒的尴尬其实是一个很OK的场景，这短暂的沉默会让双方都有一个心理上的安全感增加。记录的过程一方面是态度认真，另一方面是精确准确的记录任务和需求。
为了避免尴尬，别人下达任务的时候没有记录，那么工作的时候极有可能方向会有偏差，后面检查的时候发现不正确，那岂不是更加尴尬。再进行返工就会更加耽误进度。切不可因小失大。
记录完成后，要逐条与任务发送方进行确认。主要是看有没有遗漏的条目，然后每一个条目是否都准确的记录了任务的需求。
有了这样一个记录，就有了一个CheckList，在执行的时候就可以完全参照这样的一个记录表来进行实现。最终成果只要符合这样的记录表，就完成了最低要求。
因为除了任务完成，还要更多的领会发布任务的人的需求，做更多的事情，让对方更加满意，这就是另一部分内容了，在这里不做讨论了。