项目中的一点沟通心得

标签: 工作感想 | 发表时间:2011-08-03 19:52 | 作者:legene ZX
出处:http://blog.sina.com.cn/legene

我们每天都在通过各种方式与人沟通,但是这些沟通是真正有效的吗?我们是否总是在不知不觉中,被沟通障碍牵绊住了前进的脚步,沉浸在消极的工作情绪之中却还不自知呢?

 

以下是我在工作中总结的一些沟通心得,在此与大家分享。


项目中常见的沟通方式:


通过文档沟通:

  • 优点:不受文字数量的限制,内容具体;便于查阅存档及日后的统一管理;适合描述功能多、业务复杂的         项目;适合跨部门协作的项目;
  • 缺点:不容易建立统一标准;面向不同角色,阅读时不容易找到重点;费时;理解成本高,沟通效率低

通过邮件沟通: 

  • 优点:打破时间和空间的限制;便于查阅记录;方便为多人发送附件;比较正式,适合报告工作进度或通         报项目状况等
  • 缺点:正文不适宜太长;传递信息不即时(有时容易被忽略或丢失);不清楚语言环境有时容易误读;不         利于处理争议或敏感问题

通过IM沟通:

  • 优点:沟通方便;容易消除紧张情绪;截图、发送文件方便;可多人对话;适合相熟的同事之间沟通,畅         所欲言;适合解决争议不大的问题,
  • 缺点:容易被忽略;一些复杂的问题很难描述清楚;容易误解;查询记录时不是很方便(里面可能夹杂了         不少无关内容);不利于解决争议;过于随意,不适合说重要且紧急的问题

通过电话沟通:

  • 优点:即时、有效,沟通效率较高;适合解决紧急但不太重要的问题
  • 缺点:不利于传达微妙的情感;特别复杂的问题仍不容易说清楚,有可能引起误会;不方便查看图片等          (可配合IM使用);不便查找记录

面对面沟通:

  • 优点:真实、拉近距离(很多误会可由此解开);便于说明复杂问题;沟通效率高
  • 缺点:无记录;沟通成本略高;多人沟通时效率可能较低;一旦陷入僵局回旋余地较小(面对面沟通时心         态一定要平和,以解决问题为目的)

会议沟通:

  • 优点:集思广益、开拓思路,更多角度了解他人的观点;适用于跨部门、协同解决问题、头脑风暴等
  • 缺点:若方法不得当会导致效率极低(如果需要在会上做出决定,最好先提前一对一沟通,有备而来)


特点比较(世事无绝对,仅供参考)



适用环境(世事无绝对,仅供参考)


了解时间管理的人都知道,要首先关注重要但不紧急的事情;其次还要尽量处理好既重要又紧急的事情。因此在沟通中,要充分的重视文档、多人会议、面对面沟通、邮件等沟通方式。对于一个基层员工,要特别注意掌握面对面沟通和邮件沟通的方法。


总结:每种沟通方式都有各自的特点,很难彻底舍弃其中的任何一种,在工作中应该根据情况选择适合的沟通方式。


比如说:在项目开始之前,可以通过多人会议进行头脑风暴征求大家的意见;策划中撰写需求文档;文档写完后先面对面给其他项目人员讲述一遍思路,之后再配合IM、电话等方式即时解决后续问题;制作原型的过程中可以随时请大家在IM上提意见;通过邮件定期监控项目进度和问题;发现项目成员有负面情绪了,赶紧面对面沟通一下,……

项目中常见的沟通问题:


中国人的性格比较含蓄,又怕伤和气。既不善于主动提问,也不善于表达内心想法。于是项目中常遇到这样的情况:


1. 用文档代替正常沟通。

很少有PM发完文档,会快速跑过来给你讲一遍他的思路。这也是人之常情,人家都没问,干嘛自己要跑过去说呢。不过有文档的好处就是,别人看到不懂的地方会去问。


2. 用正常沟通代替文档

对于大型或复杂的项目,需要文档来解释说明,这是其他任何一种沟通方式也无法取代的。文档的缺失,不利于大家正确理解项目,也不利于发现问题。这样出来的结果很难令人满意。


3. 视觉或前端没看懂交互稿要表达的意思,或者是感到存在问题,却没有提出来。

作为交互设计师,我会尽量把交互稿做的精致些,配上详细的说明,但最后的结果总是不如预期理想。


4. 还有很多大家当初没发现的问题,制作完却成了大问题……


……


面对这些问题,我也在不断的思考解决方法,目前想到的如下:


1. 作为PM,还是要尽量写需求文档。首先,需求文档对理清PM的思路非常有帮助,可以通过它发现自己还有哪些地方没考虑周全;另一方面,它是设计的重要参考依据,靠简单的沟通不可能遍历到所有的用例和需求点;第三,文档可以帮助其他项目成员有针对性的提出问题,而不是感到困惑和无所适从。

也许有人会问,如果交互设计师从一开始就参与到项目中,甚至是参与需求的确定,还要写需求文档吗?答案是肯定的。需求文档可以规范的把需求要点有序的整理起来,对后续提高项目效率非常有帮助。


2. PM不写需求文档怎么办?

将心比心,没有人不热爱自己负责的产品。PM不写需求文档,一定有自己的立场和原因。作为项目组成员,可以总结自己在项目中需要知道和了解的问题,列出一份清单,请PM回答。相信每个PM都不会拒绝为大家回答问题吧。如果觉得对方回答的不清楚,可以继续细化问题,直至回答清楚为止。


3. 需求文档到底要写什么内容,是一个难题。到底什么样的需求文档能合理的概括重点内容,让后续工作顺利进行呢?我觉得这是一个长期的摸索过程,需要PM和交互、开发等角色一起讨论,通过长期的项目实践逐渐得到最适合当前团队、项目状况的文档格式。

前提是:PM及每一个项目成员要认识到大家是一个共同协作、平等互助的团队,而不是领导和被领导的关系。


4. PM不仅提供需求文档,还应向团队主要成员整体讲述一遍思路。前期沟通主要传递想法;中期沟通解决不断发现的问题,迭代需求;后期沟通确认问题是否得到解决。


5. 其他角色以此类推。


类似的项目如果做的多了,在这个过程中,就会逐渐形成规范机制,使得后面的工作越来越轻松。


通过沟通把握微妙的情感:


沟通过程不总是理性的,也有很多感性成分。


大家在一起工作,但又属于不同的部门或小组,时间长了,难免会产生各种小摩擦。正确的沟通,可以尽量避免这些不快,帮助我们更好的工作,或者说更快乐的工作。要想达到好的沟通效果,需要注意以下几点:


1. 放平心态。

不太计较得失,客观的看待问题,保持心情愉快……这些看起来谁都懂,做起来却困难的很,需要不停的在工作中磨练自己的心性。


2. 换位思考

你有没有对某人很不爽的时候?巧合的是,这个人十有八九对你也抱有同样的想法。对待同一个事情,每个人的立场不同,太过坚持自己的想法,就容易造成误解和矛盾。很难说谁对谁错,重要的是客观认识不同的立场,最后寻求一个好的解决方法。意气用事不会带来任何益处。

当你埋怨PM做的不好,沟通不到位的时候,有没有想想自己是不是也在犯同样的错误?自己有没有认真的把设计意图传达给视觉?每个人都有自己的难处,宽容、谅解,做好自己的事,也帮助别人做好他的事情,才能促使更好的结果。


3. 积极主动

多思考、多提问、多表达自己的意见。遇到不快的事情不要急着下结论,或是越想越歪,而是探清事情因果。其实,事情永远不像我们想的那么乐观,也不像我们想的那么悲观。


4. 真正认识沟通的意义

沟通是平等的,而不是一方强势的压过另一方。这是一个协作的时代,不是个人英雄主义的时代。


结语:沟通不是说学就能学的技能,而是通过后天不断的去领悟,去应用。我对沟通的认识还很粗浅,需要继续体会沟通之道。祝愿大家都能更有效的沟通,快乐的工作。

相关 [项目 沟通] 推荐:

项目中的一点沟通心得

- ZX - legene的交互设计博客
我们每天都在通过各种方式与人沟通,但是这些沟通是真正有效的吗. 我们是否总是在不知不觉中,被沟通障碍牵绊住了前进的脚步,沉浸在消极的工作情绪之中却还不自知呢. 以下是我在工作中总结的一些沟通心得,在此与大家分享. 优点:不受文字数量的限制,内容具体;便于查阅存档及日后的统一管理;适合描述功能多、业务复杂的         项目;适合跨部门协作的项目;.

开会那点事儿(三)项目中的沟通之道

- Will Yang - 所有文章 - UCD大社区
《开会那点事儿》 系列第三趴——项目中的沟通之道(点此回顾:第一趴 第二趴). 刚刚上线了项目,期间体认最多的是当面对多种需求方时,如何通过沟通各个“击破”又让他们各个心满意足. 有篇不错文章,讲得是产品经理需求分析要高于需求方,大致意思是:. 首先,人都是站在自己的角度看问题,但是产品往往要整合不同业务需求,一大堆需求不做分析、排序整合在一起,用户用起来必然会很恶心.

文章: 与项目干系人沟通业务价值

- - InfoQ cn
我先告诉你一个秘密:我根本不关注你在“DD”前放哪个字母,我也不太关心代码是怎么写的、软件开发时的输入输出是什么. 倒不是因为我不知道它有多重要——而是因为,我更关注的是它的交付价值. 你做的东西,怎么节省我的时间、钱和/或避免项目失败. 我明白,团队里如果没有你这个天才成员——我的生活将会变得一团糟,工作将不再正常运转.

跨部门项目沟通的6个关键因素

- - 人人都是产品经理
编辑导语:在工作中,完成一个项目的时候,常常需要进行跨部门合作,如果不能掌握好跨部门的沟通能力,有可能会导致项目延期或者项目失败. 本文作者根据自身在部门里的工作经验,总结了跨部门沟通的几个关键因素,一起来看看吧. 很多在大厂工作的伙伴应该都有遇到过这样的困扰,完成一个项目大多数时候都必须要跨部门合作.

如何与PM沟通

- - 曉生
1.要学会听取别人意见,也许PM提出的问题你并没有考虑到,集思广益,可以得出有更好的方案. 值得肯定的是,你设计时已经能学会从产品角度考虑,引导用户操作,而不是单纯的好看. 只要不是单纯审美上的PK,都可以讨论,不是吗. 2.让产品阐述自己的需求点,明确重点. PM们七嘴八舌肯定不对的,要引导他们梳理出统一的意见.

团队沟通杂感

- - 人月神话的BLOG
随时随地的短时间的,快速迭代的培训和教练作用远远大于正规的系统培训. 系统性培训一个是针对性往往弱,另外一个就是对团队成员有较高的要求,即自我强烈的系统性学习欲望. 走动时管理目的是及时的发现各种问题和团队技能之欠缺点,有针对性的进行沟通和经验传递,这需要团队管理者有敏锐的洞察力,不能脱离到团队工作事务之外.

谈产品人的沟通

- - 互联网的一些事-关注互联网产品管理,交流产品设计、用户体验心得
  经常听产品经理说自己是打杂的,虽然这种说法有自我调侃的意味,但用这词来形容产品经理的工作也颇为贴切. 产品经理在一个公司中扮演的角色决定了他要做的事情多而杂,在一个产品诞生的过程中,从idea的诞生,产品的规划,UI设计,前端制作,程序开发,然后测试上线,上线后产品的优化等,产品人员一方面要全身参与,另一方面也要一直跟进.

reCAPTCHA项目

- - 四火的唠叨
文章系本人原创,转载请保持完整性并注明出自 《四火的唠叨》. 要说reCAPTCHA,就要先说一说CAPTCHA,全称是Completely Automated Public Turing test to tell Computers and Humans Apart,即全自动区分计算机和人类的图灵测试,也就是通常说的“验证码”,目的就是要把计算机和人区分开来.

我们需要怎样的沟通工具(一)情境沟通

- danaodai - 爱范儿 · Beats of Bits
自从进入了2011年,Kik、WhatsApp、Beluga、GroupMe、TalkBox等等几乎每周就有一个新的聊天工具冒出来,又看到 WhatsApp 获得八百万美金的 A 轮融资,我相信无论开发者们还是VC都相信的一个市场机会是,在移动互联网时代,一款完全基于移动设备的,并充分利用其能力而设计的沟通工具是一个很大的市场机会.