作团队感悟(8)----有效沟通

本文作者:sodme

本文出处:http://blog.csdn.net/sodme

声明: 本文可以不经作者同意, 任意复制, 转载, 但任何对本文的引用都请保留文章开始前三行的作者, 出处以及声明信息. 谢谢.

前记：

“有效沟通”，这里的“有效”，指的是有效率。

这是一篇有关“如何进行有效沟通”的作团队感悟，其核心思想是： 在 实际的开发实践中，我们需要不断优化各种各样的工作流程，而流程优化一个非常重要的方式，就是“有效沟通”，所谓的“有效”，是说对于表达者，要明确表达 自己的意思，对于接受者，要准确理解对方意图。我们经常说，“执行比理念更重要”，而有效沟通，就是“有效执行”的大前提，所以，要努力培养团队成员养成 有助于有效沟通的一些好习惯，比如：要多读书，多思考。从另一方面来说，学会对问题的基本分析与判断方法，是一个职业人应该具备的基本素质之一。

引入正文----

在团队开发中，我们总免不了与上上下下，左左右右的人协作，交流与沟通，上到一个需求的含义，下到一个函数的接口。如何作到“快速开发”？有效的沟通，成为第一个我们需要面对和解决的问题。

所谓沟通者，参与的人，无外乎两个方面：听者与说者。

所以，有效沟通，具体的应该是指：

1.对于说者而言，要想办法组织好自己的条理和语言，把复杂的问题简单化，力求“一针见血，言简意赅”的表达自己的想法，对于说者，你的任务，不仅仅是“说”，而且，是要“说清楚”，要想办法让听者更易理解。

2.对于听者而言，要认真收集说者语言中传达的各种信息，理出有效信息，记下，并在随后的交流中进行复述和确认，对于听者，你的任务，不仅仅是“听”，而且，是要“听明白”，你的理解要跟说者达成一致。

我 们总是痛苦于这样一种情况：辛辛苦苦说了半天，结果，我们的“听众”听到最后，还仍然是不明白。我们埋怨对方的理解力太弱，埋怨对方不认真听，进而失去耐 心，认为这样的沟通是在浪费时间，于是，便不再进行沟通，而不沟通导致的结果就是对方作出来的东西不是你想要的东西，于是，出现了不断的返工，浪费了更多 的时间。

每当这个时候，其实，最应该反思的，是你自己，你应该仔细反思以下内容：

1.你所说的话，有没有条理性，有没有一是一，二是二的理清关系？

2.你是不是把简单的问题复杂化了？能不能作到复杂问题简单化，你的想法能不能只用一两句话就能明确表达？

在涉及到多人协作的团队开发中，我把第二点看得更加重要，一件事，如果不能用一两句话说清楚，那在他传我，我传你，你又传另外人的几个步骤后，很有可能就会造成理解扭曲，第二点能力，可以简单地说，就是“ 抽象的能力”和“ 形象的能力”。

“ 形象的能力”，是指借用打比方，类比之类的方式，来把一个陌生的观点和想法通过听者已经熟知的内容传达给听者，把想法尽可能具体化。

如何培养“抽象的能力”？阅读+思考。

我记得很久之前，读初中时，我们每学一篇议论文，学习之前，语文老师都会让我们记一下这篇文章的“中心思想”，也就是这篇文章的核心观点，然后带着我们围绕着这个“中心思想”去分析作者如何从各个方面为自己寻找论据的。

所以，针对这个“中心思想”，从听者和说者的两个角度，应该努力作到：

1.说者要尽可能“明确表达”这个“中心思想”；

2.听者要尽可能的从各种信息中“判断”出这个“中心思想”；

3.听者“心里”明白了，还不行，必须要跟说者来确认这个“中心思想”，确认双方对它的理解是一致的，而确认的方法之一，就是由听者对“中心思想”进行提炼，概括，复述。

以我们自己项目的开发方式而言，说一说我们的方式。

通常情况下，我在布置开发任务时，会按以下方式来作：

1.在布置具体任务之前，我会先交待一些开发原则，比如：要有防御性编程思维，服务器编程是基于“不可信任式”编程，安全是第一位的等等；

2.明确表述需要制作的内容，按什么步骤来作，列出可以参考的类似实现；

3.向接受方明确告知，什么是第一位的，什么是第二位的，当第二位的与第一位的产生冲突时，要舍弃第二位的。

其 实，在我们的开发实践中，我们发现，大家普遍容易疏忽和出现问题的地方，主要是跟实际运营相关的，就是说编码不能仅仅是考虑编程语言如何组织，数据结构如 何优化，不能仅仅在技术的框架内考虑实现方案，慢慢地，要学会在产品运营的框架下去考虑问题。而这种观点，就构成了我们团队沟通的基础，必须要不断强化运 营的观点，让大家慢慢接受这种观点，这样，在以后的协作中，就会出现更多合作中的默契，而不用你一而再，再而三的去作唐僧式的宣讲了。