关于沟通的十条建议

前言

最近工作越来越体会到沟通的重要性,作为程序员,我表示自己的沟通技巧还需学习。这段时间,由于没有做好有效的沟通,感觉工作有点不开心…

今天上课,老师给我们强调了沟通的重要性,这篇博文的第一个目的是做个课堂笔记,另一个目的是分享最近我对如何有效沟通的一些思考,会包含一些具体的建议。那我们就愉快地开始吧,gogogo。

白板晨会

我们每天都要开白板晨会,大家站在白板周围,讲讲自己昨天做了什么、今天要做什么已经可能的风险,白板上写了每个人的工作情况。这个晨会除了向项目经理汇报进度外,还有个目的:向老板展示团队的工作。所以,白板要放在老板能看得到的地方。

得到老板的关注,对团队的激励时无穷的,我们在白板上,承诺了要完成的工作,工作进度也能体现,这很能提高工作效率。

注意语言表达

我们知道,问一个问题的表达不同,可能会得到不同的答案。看下面两个问题:

  1. 如何投放更多的广告,吸引用户玩我们的游戏?
  2. 游戏如果赚到更多的钱?

这两个问题得到的答案肯定是不同的,问题2更具开放性,回答者会从多方面考虑。

在定位bug时,要注意措辞,比如,不能简单的说,这不是我的问题,某某组件有bug。而要说,这个问题我需要再检查一下,某某同学能否跟我一起看一下这个问题。

先整理好问题列表再发问,避免打扰他人。

有个同事最近有很多问题找我确认,这些问题很简单,我只需要回答是或否。每次我回答后,他隔了不久,又给我抛出另一个问题。

这让我很没有预期,我不知道对方有多少问题,拜托,能不能一次把你的问题整理完,我一下子告诉你?高频率的向对方发消息,会打扰到别人的。

还有一点,提问之前要看下有没有对应的《帮助文档》,如果总是询问文档上已包含的内容,对别人也是一种打扰。

学会对方的“语言”

世界上,有很多语言,不同语言之间沟通时又障碍的。IT行业也是这样,客服、运营、产品、美术、技术都操着不同的“语言”,如果能够学会对方“语言”,当然沟通会更快捷。

我在跟产品解释一个问题时,常常就默认他跟我一样时技术背景的,结果说了半天,对方也没能完全明白。

不要轻易提紧急需求

对于紧急需求,至少有两层含义:

  • 需求提出方很迫切地用到该功能。
  • 开发可能需要加班加点完成。

作为一个程序员,如果任务多时间紧,你为了完成需求,你要怎么做?要么压缩编码的时间,要么压缩测试时间,这肯定是对质量有影响的!

作为需求提出方,你要想清楚,我的需求很紧急么?我们项目组就遇到过,一些产品催得很紧急,然后我们交付后,他们居然不用。这让项目经理会怎么想?你以后提紧急需求,PM还会优先满足你么?

产品有bug,先想想是不是自己的问题?

一个产品,经常会整合很多个小组的代码,定位bug时,会定位出是哪个组件的问题,然后推动该组件的开发去改。

我被坑过,当然也坑过别人。我曾经下过结论,我的代码没问题,结果其他组件的兄弟周末加班定位出时我的问题,把他坑惨了,现在想想真对不起他。

在下结论之前,要考虑一下,是不是自己的问题?你想想,你一封邮件抄送给这么多leader,然后说别人的组件有问题,后来被证明是自己的原因,这是多么难堪事情啊!

尊重别人的汗水

当别人为你完成一个需求时,表示一下感谢吧,这是对别人汗水的尊重。

如果他做得不满足你的需求时,不要埋怨,多些鼓励。

请给对方时间和耐心,学会换位思考。

我很理解那种渴望做好产品的心情,因为我也很渴望写出漂亮而且无bug的代码。

有些问题,我需要时间去定位,请不要每次一有报错就直接给我打电话要求我立马解决,我不能一秒变超人,我也需要时间,现在我可能还有其他事情要跟进。

再说一下企业里面的电话沟通。电话是很直接的沟通方式,如果遇到紧急的问题,建议直接电话沟通,但是不要每次都电话。如果对方需要时间跟进的,建议发电邮或者消息,这样不至于给对方太大的压力。

说到换位思考,我检讨一下自己。有一次,一个同事让我看一个报错,我看了半天,给他的结论是:这不是我的问题。结果那同事很着急,他说,我又不懂技术,你虽然定位出不是你的问题,但是你可不可以告诉我,可能是哪些地方出错了,我好去找相关的人。

是的,我应该换位思考,抱着解决问题的心态,而不是证明我没错后,就不管不顾了。

不要威胁同事

你不给我解决,我就捅到你的领导,再不行,就告诉领导的领导!
你要是不行,我就让PM换个人来跟!

对方只考虑到了他自己的需求是否得到实现,但没有考虑到我的实际情况。听到这样的威胁,我感觉很可笑,这样我想起童年时的那句,我要告诉老师。

退一步说,大家都是打工吊,何必苦苦相逼。

战争是解决矛盾的一种方式。

有些矛盾如果无法解决,那就爆发“战争”吧。

大家通过争吵、矛盾激化,然后惊动到领导,接着就坐下来谈一谈。战争之后,就要“签订条约”,对应到工作中,就是约定一些流程,去解决问题。记住,解决问题才是关键,“战争”过后,也需要和平共处。

结束语

终于写完了,没想到写了这么多,在IT公司混,沟通也很重要的呢。第一次用markdown写博客,为自己赞一个!

时间: 2024-10-27 04:45:57

关于沟通的十条建议的相关文章

JavaScript高性能开发的十条建议

JavaScript高性能开发的十条建议 文/开发部 Dimmacro 编者按:javascript开发大部分程序员都做过,写出来的代码质量也千差万别,现在浏览器内嵌的解释器虽然效率已经很高了,但在客户完美体验的趋势下还是捉襟见肘,编写高性能javascript代码,无疑能带来更好的客户体验.本文的这些建议能给开发者带来一定的方向指导,值得一读. 1.使用延迟脚本,动态加载脚本,XHR脚本注入等方式加载js脚本,避免多脚本加载出现的页面长时间等待. 编辑解读:每读取一个页面,页面内容从上到下顺序

如何书写高效的工作邮件:给你十条建议

by DaXi · 2016年6月10日 在工作中电子邮件是必不可少的通讯工具,尽管即时通讯软件目前在工作中也起到了非常重要的作用,但是电子邮件仍然具有不可替代的优势,我从业以来每 天都面临着处理各种电子邮件,但是我也发现很多朋友和同事,对如何书写一封高效的工作电子邮件不是十分明确,今天写的这篇文章就把我的工作电子邮件书写建 议分享给经常使用电子邮件的同事,或者是刚刚迈入工作单位的朋友.大家共勉之. 1.重点突出的邮件标题 邮件标题是邮件的重要部分,你需要用一句话概括邮件的内容和意图.如果是一封

[转载]AxureRP使用参考建议

这些参照建议是马克总结出来的,我只是借用过来给大家参考,在此先感谢一下马克.对于很多学习或者刚使用AxureRP的产品经理们或者朋友们,总会有一些对于AxureRP该怎么使用的更合适想法,也有对AxureRP做原型到什么程度的争论,比如是低保真.高保真等保真度的掌握:对于这些,大家可以参考这二十条建议. AxureRP使用建议第一条:原型设计的最终目的是为了准确.方便.快捷的表达产品设计人员的产品设计意图: AxureRP使用建议第二条:原型的观看者往往不是同一类对象,因此原型的设计不可避免的会

做软件测试月薪过万的10条建议!

很多软件测试人员薪资就卡在了6k-9k之间,就是过不了万.第一个应给是前期走过不少弯路的,第二个就是长期限于这个瓶颈期上升不去. 那么如何解决这两个问题呢?希望我整理的自己多年的经验能够给你们一些启发. 这篇文章主要还是解决软件测试从业者思维思想的一些问题,说白了,技术上的问题好解决,认知和思维上的问题不好解决.老规矩,本文的思维导图我依然放在文末! 文章主题<年轻测试人员薪资过万的十条建议>,共计3500字左右,预计阅读时间4分钟 个人工作经验总结,绝对原创! 一.不断究根问底 1.出现问题

精简代码,为网站减负的十大建议

网站快速加载,是提供良好用户体验的前提.然而,网站功能的不断增多,程序包的不断臃肿,导致网站访问时较大的下载量,最终影响了响应速度.没有一个用户喜欢等待,如何减少代码量,为网站减去过多负担,Craig Buckler在sitepoint网站发表了一篇文章<10 Quick and Easy Fixes to Reduce Page Weight>,分享为网站减负的十个建议.下面为该文的编译内容. 2013年,网站页面的重量增加了32%,竟然达到了1.7MB,包含96个独立HTTP请求.这只是一

如何提高Axure设计的效率 提高Axure设计效率的10条建议

如何更有效率的使用axure,这是新手需要掌握的技能.本文作者从实际经验中归纳出来的十条建议十分值得学习,转载分享给大家: Axure 是创建软件原型的快速有力的工具.上手很容易,但是,其中存在一个危险.这款软件是如此的直观以至于很多用户可以在没有接受过任何正式培训的情况下进行使用.他们可能不知道的是他们可能没有以恰当的方式来使用 Axure. 作为一位有经验的用户体验设计师,我很少在画一页的时候第一次就能把它设计正确.大部分时候,我要经历5到10次的反复迭代(iterations).当你的用户

为页面减负的十大建议

过于笨重的网站将严重影响网站的最终体验,主要表现在以下四个方面: 更大的下载量,导致更慢的用户体验.并不是每个人都拥有20M的网络连接,尤其是对于那些不发达地区.不管你的网站多么优秀,用户永远不希望等待. 移动Web访问正迅速发展,移动网民几乎占到所有网民的1/4.在典型的3G网络连接下,一个1.7Mb的网站加载需要近一分钟.如果你的网站无法高效工作于这些移动设备,那采用响应式Web设计技术又有什么用呢? 网站加载速度已被谷歌加入排名算法中.加载缓慢会降低网站排名,同时也会影响搜索引擎优化. 网

源码管理的新15条建议

作者:张克强    作者微博:张克强-敏捷307 建议之1:使用好的配置管理工具,也称为版本号控制工具(Version Control), 比方Git,SVN. 请彻底抛弃 VSS.假设是新採用配置管理工具,CVS已经不再是选项. 配置管理工具与版本号控制工具能够理解为指的是同样工具. 建议之2:抛弃古老的配置管理三库做法,常说的三库是指开发库(动态库).受控库和产品库(静态库).做法是开发库->受控库->产品库. 在当年没有强大版本号控制工具的"古代",三库做法是不得不的

如何与开发沟通功能实现

测试工程师日常工作中,经常会与其他团队角色进行沟通,这其中难免会出现一些沟通的问题,这些问题需要更多地沟通技巧来解决.本次小编想跟大家分享一下:如何与开发沟通功能实现. 某测试同学为了测试一个功能,需要了解功能的实现逻辑,所以她满脸笑容地找到开发同学后说道:”你给讲讲Cookie同步是怎么实现的吧!” 开发同学不耐烦道:“说了你也不懂.” 以上情景相信不少同学遇到过吧,小编分享下自己在与开发沟通功能实现方面的技巧: 一.沟通的时机很重要. 小编以前做开发的时候,最大的感受就是来自于实现功能的压力