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

标签: 开会 项目 沟通 | 发表时间:2011-04-27 11:57 | 作者:张雅秋 Will Yang
出处:http://ucdchina.com/rss/all

《开会那点事儿》 系列第三趴——项目中的沟通之道(点此回顾:第一趴 第二趴

刚刚上线了项目,期间体认最多的是当面对多种需求方时,如何通过沟通各个“击破”又让他们各个心满意足。

有篇不错文章,讲得是产品经理需求分析要高于需求方,大致意思是:

首先,人都是站在自己的角度看问题,但是产品往往要整合不同业务需求,一大堆需求不做分析、排序整合在一起,用户用起来必然会很恶心。

第二,需求方的某些需求可能比较狭隘,他通常只会告诉你:我需要一匹很快的马(而不是一个新产品叫汽车)——亨利福特,这就需要你创新地再加工。

如果你相信事在人为,沟通亦有技巧,在会议中针对不同的需求方,如果恰当的使用沟通方式,或许会达到共赢的效果。

(一)避免专业上的“针尖对麦芒”

开会时拖延最长往往不是因为内容过多,而是一个点上争论不休…

你和我讲用户体验,我就和你谈数据分析,你和我谈数据分析,我就和谈运营计划….总之,在我的专业上,没人比我权威,这是我的专业,你丫还敢来挑战我,我专业还是你专业。最后谁也不能挑战谁的专业,讨论也无解…

有同事还为此配图说明:

分析:

心理上,谁都讨厌别人在自己擅长的领域指手画脚,如果大家都在自己的专业上对一个问题,不同方向东拉西扯,各自专业神圣不可侵犯,那沟通多数久久纠结,最后无果。

良好的沟通是建立在双方对专业知识覆盖的基础之上的。沟通不在专对专,而是广对广。作为项目团队的虚拟核心,产品经理一是要在专业上尽量广泛涉猎,二是专业上信任队友,积极了解学习,最终整体权衡。

(二)把无所谓的胜利让给对方

很多人都曾遇到这样的问题:会议上总有一类辩才一流的人,偏偏与你在某一个细节上意见不同。

“为什么这里填表不直接采用输入框?”

“我在设计中觉得下拉是最常见样式,用户比较熟悉”

“但是,你不觉得下拉一个个排查很麻烦么?”

“….是的,不过我认为直接输入会造成很多校验问题,比如:全角\半角”

“我认为前端有方法可以解决,可以全角转成半角。还有,blablabla…..”

“………”

开始时候觉得在这个无关紧要的东西上争论不休很浪费时间,但是如果你回嘴又是新的一波探讨,难道还为了这个在本来就紧张的项目中做用户测试、数据分析?有这个必要么?

问问自己,如果按他们的方法对产品有致命伤害么,用户会不理解或是愤怒、挫败么?如果没有,把这种无所谓的胜利让给对方又如何?谈判中也让对方“占了便宜”,没准上道后对方在关键点上也会有所让步。

(三)关注沟通中的沉默寡言者

会议中总有些沉默寡言者,看似比喋喋不休的指挥者招人喜欢,但这些人往往是项目延期的“致命地雷”。

  • 怎么都行的需求方

这个视频你一定看过:女生多数嘴上表达无所谓,心理一堆标准。

面对这样的女友、这样的需求方如何应对?开始好说话,“随便,怎么都行?”上线牢骚一堆…..

  • 话说一半的需求方

常用语是“总之,你懂的…”这类人特征是话不讲明,总有所保留。要么他压根没想到你不了解某些信息,要么忙碌忽略。这时候,项目中大量细节仍需要确认…怎么办?

拓展中的“接桥游戏”是说明这类沟通问题最佳案例:

每组建造整座桥的一半,要求不但符合任务书上的要求,同时在桥的造型、高度、宽度、装饰等各方面都要完全一致,最后拼成一个完整的桥。整个造桥过程,两组队员只有三次沟通机会。

听起来很简单,有木有!但是,每个人都认为各自项目书上的内容是“你懂,我懂,大家都懂的…”沟通中的疑惑也没及时刨根问底,最后发现各自认知完全不同,桥无法对接成功,就为了这个看似简单的原因产品宣告失败…

这说明,沟通之道很简单:要积极,要争取,要会聆听对方描述,并及时询问不同理解,达成共同认知。

最后,说点项目外的管理体认。

  • 小心!拖沓和老好人

项目中,估时和提醒是管理的“硬指标”。如果有人平日正常,最近似乎心不在焉、工作拖沓。即使你和他没有级别关联也要主动关心,了解是不是有些状况,做好风险预测和备案措施。这些看似不可控,但可预期的因素经常造成项目延期。

另一种看似无害的“老好人”也很危险。他们往往碍于人情,接下不合理的要求,或是受制于“人情”而不是规范,不怒不言不通报。一方面,他们即使有不同意见和建议也不表达;同样,他们因为沉默而产生团队距离感,信息也经常出现不对称。第三,往往他们是高压人群,对团队、自己有负面想法。这对形成统一、透明的团队氛围很不利,他们往往需要引导,私下多沟通。

源地址:http://www.zhangyq.com/meeting-that-something-c-communication-with-the-demand-side-of-the-road/

相关 [开会 项目 沟通] 推荐:

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

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

项目中的一点沟通心得

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

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

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

如何与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都相信的一个市场机会是,在移动互联网时代,一款完全基于移动设备的,并充分利用其能力而设计的沟通工具是一个很大的市场机会.

团队如何有效沟通

- Ivan - 博客园-首页原创精华区
         一个团队,特别是项目团队,往往涉及的人员多,而且跨专业线、跨部门甚至跨区域,如果让团队中所有的人员进行有效的沟通就非常重要,一个有序且高效沟通的团队必然是一个高效率、高凝聚的团队,相反一个项目组成员整天都在无序地、低效率地沟通,那应是一个低效、无凝聚力的团队,我们很多人往往都关注做事情、解决问题去了,并不是很重点关注此问题,常常忽略掉沟通的问题.