本文作者:sodme
本文出处:http://blog.csdn.net/sodme
声明: 本文可以不经作者同意, 任意复制, 转载, 但任何对本文的引用都请保留文章开始前三行的作者, 出处以及声明信息. 谢谢.
前记:
“有效沟通”,这里的“有效”,指的是有效率。
这是一篇有关“如何进行有效沟通”的作团队感悟,其核心思想是:
在实际的开发实践中,我们需要不断优化各种各样的工作流程,而流程优化一个非常重要的方式,就是“有效沟通”,所谓的“有效”,是说对于表达者,要明确表达自己的意思,对于接受者,要准确理解对方意图。我们经常说,“执行比理念更重要”,而有效沟通,就是“有效执行”的大前提,所以,要努力培养团队成员养成有助于有效沟通的一些好习惯,比如:要多读书,多思考。从另一方面来说,学会对问题的基本分析与判断方法,是一个职业人应该具备的基本素质之一。
引入正文----
在团队开发中,我们总免不了与上上下下,左左右右的人协作,交流与沟通,上到一个需求的含义,下到一个函数的接口。如何作到“快速开发”?有效的沟通,成为第一个我们需要面对和解决的问题。
所谓沟通者,参与的人,无外乎两个方面:听者与说者。
所以,有效沟通,具体的应该是指:
1.对于说者而言,要想办法组织好自己的条理和语言,把复杂的问题简单化,力求“一针见血,言简意赅”的表达自己的想法,对于说者,你的任务,不仅仅是“说”,而且,是要“说清楚”,要想办法让听者更易理解。
2.对于听者而言,要认真收集说者语言中传达的各种信息,理出有效信息,记下,并在随后的交流中进行复述和确认,对于听者,你的任务,不仅仅是“听”,而且,是要“听明白”,你的理解要跟说者达成一致。
我们总是痛苦于这样一种情况:辛辛苦苦说了半天,结果,我们的“听众”听到最后,还仍然是不明白。我们埋怨对方的理解力太弱,埋怨对方不认真听,进而失去耐心,认为这样的沟通是在浪费时间,于是,便不再进行沟通,而不沟通导致的结果就是对方作出来的东西不是你想要的东西,于是,出现了不断的返工,浪费了更多的时间。
每当这个时候,其实,最应该反思的,是你自己,你应该仔细反思以下内容:
1.你所说的话,有没有条理性,有没有一是一,二是二的理清关系?
2.你是不是把简单的问题复杂化了?能不能作到复杂问题简单化,你的想法能不能只用一两句话就能明确表达?
在涉及到多人协作的团队开发中,我把第二点看得更加重要,一件事,如果不能用一两句话说清楚,那在他传我,我传你,你又传另外人的几个步骤后,很有可能就会造成理解扭曲,第二点能力,可以简单地说,就是“
抽象的能力”和“
形象的能力”。
“
形象的能力”,是指借用打比方,类比之类的方式,来把一个陌生的观点和想法通过听者已经熟知的内容传达给听者,把想法尽可能具体化。
如何培养“抽象的能力”?阅读+思考。
我记得很久之前,读初中时,我们每学一篇议论文,学习之前,语文老师都会让我们记一下这篇文章的“中心思想”,也就是这篇文章的核心观点,然后带着我们围绕着这个“中心思想”去分析作者如何从各个方面为自己寻找论据的。
所以,针对这个“中心思想”,从听者和说者的两个角度,应该努力作到:
1.说者要尽可能“明确表达”这个“中心思想”;
2.听者要尽可能的从各种信息中“判断”出这个“中心思想”;
3.听者“心里”明白了,还不行,必须要跟说者来确认这个“中心思想”,确认双方对它的理解是一致的,而确认的方法之一,就是由听者对“中心思想”进行提炼,概括,复述。
以我们自己项目的开发方式而言,说一说我们的方式。
通常情况下,我在布置开发任务时,会按以下方式来作:
1.在布置具体任务之前,我会先交待一些开发原则,比如:要有防御性编程思维,服务器编程是基于“不可信任式”编程,安全是第一位的等等;
2.明确表述需要制作的内容,按什么步骤来作,列出可以参考的类似实现;
3.向接受方明确告知,什么是第一位的,什么是第二位的,当第二位的与第一位的产生冲突时,要舍弃第二位的。
其实,在我们的开发实践中,我们发现,大家普遍容易疏忽和出现问题的地方,主要是跟实际运营相关的,就是说编码不能仅仅是考虑编程语言如何组织,数据结构如何优化,不能仅仅在技术的框架内考虑实现方案,慢慢地,要学会在产品运营的框架下去考虑问题。而这种观点,就构成了我们团队沟通的基础,必须要不断强化运营的观点,让大家慢慢接受这种观点,这样,在以后的协作中,就会出现更多合作中的默契,而不用你一而再,再而三的去作唐僧式的宣讲了。