如何进行有效的沟通----日常沟通及会议

日常开发和工作中会经常遇到沟通不畅的问题，"communication" 不论是在学术还是实践中都是一个很重要的议题。因为低效的沟通造成的开发事故有时候是灾难性的。

沟通的问题为认为本质上就是信息不对称。下面以日常沟通及会议沟通做一些浅显的讨论，并警戒自己在以后工作生活中做到有效的沟通。

一、 日常沟通

1. 明确问题

两个人讨论问题，如果A开口就是：

"昨天那个程序又挂了，你那有备份么？"

那么B的内心一定是：

"What a fucking question it is！"

先说A，A的沟通是低效的，甚至可以说是一句废话，因为这句话中最关键的信息被遗失了。

A内心的想法可能是，"昨天不是跟你说过这个程序的事吗，所以我跟你讨论这个挂掉的程序你应该是知道我在说什么啊"。

但是B不一定知道，他从昨天到今天处理了这么多事，即使昨天跟你一起处理过这个程序他也无法一下子反应过来你说的是什么。

实际上这里的不对称就是A在表达时默认一些信息是公共的，是你我都知道的，然而大部分时候，这些被默认的信息都是重要的，且"不公共的"。

如果A的表达换成"昨天那个unix时间戳转换程序我改了一下出了bug，你那还有之前的备份么"，可能B一下子就能get到你的点了。

这里要说一下，跟别人说明问题的时候一定要言简意赅。尽量用最少的语言去表达最重要的信息：

1. What is the problem？

2. How serious the problem is ？

3. What is the effect of this problem？

大家工作每天都很忙，要在有效的时间里传递最有效的信息。

在说明问题商讨方案的时候要把问题是什么说清楚，问题的严重性说清楚，问题的影响说清楚。

尽量不要把你发现问题的过程啰里啰嗦地讲给别人，"我是因为发现了***问题，然后发现***，最后我发现这个问题是****，所以我猜测这个问题是***"。 最开始沟通的时候这些描述是多余的。

先把目前遇到的问题明确。接下来再去详细说明问题的来源和过程，说明问题不是空穴来风。

2. Feedback

沟通中的反馈是非常重要的，根据谈话者的反馈来确定沟通的内容，能帮助我们提高效率。

如果A是任务的发布者，要主动确认任务接收者的理解是否与自己的意图相同，保证信息的对称性。任何默认彼此都知道的公共信息都是危险的。尽可能的把重要的信息传递出去，不管对方知不知道。

如果A是任务的接受者，要主动反馈自己对任务的理解确保与任务的发布者对任务有相同的认识。避免造成理解偏差，做南辕北辙的事。要重视开发中的需求再确认。

Double check could be applied everywhere.  不论是在需求，开发还是测试中，反向确认都是重要的。只有弥合了信息的不对称才能确保后面的路一马平川。

二、会议沟通

国内很多公司都开始向敏捷开发的路狂奔。但是我在工作的时候发现大家只是东施效颦，没有真正的去思考敏捷开发到底敏捷在哪里，更不要说正确应用了。

我这里以每天的例会为例说一下我对例会中沟通的敏捷的理解。也就是Scrum中的Scrum Daily Meeting。

Scrum Daily Meetings are strictly time-boxed to 15 minutes. There are three questions that each team members need to answer:

1. What did you do yesterday?

2. What will you do today?

3. What is blocking progress?

关于daily meeting，所有的教课书都强调两点，15分钟时限的严格控制，三个问题的回答。

敏捷开发是一种源于经验的科学理论，对日常会议作出时限的要求也是大量实践的结果（当然也是结合团队规模的结果）。如果一个团队7个人的话，则平均每人个人说话两分钟。加上团队成员间的交流互动，促成这15分钟。但是现实中的日常会议经常演变成以下两种：

1. 流水账

有的同学喜欢把这一天细枝末节的事情都罗列的说一遍，诸如审核了谁谁的代码，开发了啥啥功能，补充了什么什么文档。这些内容冗长而乏味，既不能体现出项目的进度，也不能使其他队员参与到讨论当中，更别说回答三个问题了。这样的报告基本上就是在浪费时间，更别说敏捷了。

2. 技术及方案的讨论

经常在日常会议的时候有的同学喜欢把今天写了一个什么算法，用了什么技术拿出来讨论一下，几番讨论就变成了争论不休，而且这样的讨论，在这种会议中即无法给出合理的方案（会议时间短，讨论者之间对问题和进度的理解不同，无法达成一致），也说不清楚目前问题的所以然，如果别得同事与这个问题无关，就变成了团队中某几个人的秀场，其他人无聊且不耐烦的等待了。

私以为，daily meeting 是以贯彻项目进度为导向的，团队成员聚在一起讨论是明确项目的进展如何，有哪些不可抗力的阻挠（eg：时间规划，硬件设备，资金，人手等等），需要团队提供帮助的，以及一些分工合作上的交流。

实际上，敏捷团队中有一个重要的角色是Scrum Master，这个角色有一个重要的职责就是控制会议时间，使会议变的高效。

在团队成员的日常总结空泛时，应该主动询问，今天重要的进展是什么，困难是什么，其他人如何配合你完成工作，接下来的计划和方案是什么。

如果团队中个别成员陷入了与会议主题无关的讨论时，应及时终止争论，切回项目进展的正题，对于具体的方案，诸如算法，开发细节的讨论应该会后安排时间讨论。

敏捷开发中的日常会议可以提供给团队更加清晰的项目进展，帮助团队合理的分配和优化资源（时间，人手，硬件设备等等），以此来提高团队的效率。

其实，在工作中我发现，Daily Meeting 中团队成员间的讨论和互动也可以很好的培养团队凝聚力的，以及成员之间的工作默契等等。

我在这里反思一下：

我最近工作中处理一些数据，但是机器不够用，开会的时候缺没有把自己的困难说出来，以至于一直进度缓慢，问题和困难也没有得到及时解决。没有机器怎么办？借呀！