河北视频网站建设,上海近期新闻,查询注册过哪些网站,小程序开发成本日常开发和工作中会经常遇到沟通不畅的问题#xff0c;communication 不论是在学术还是实践中都是一个很重要的议题。因为低效的沟通造成的开发事故有时候是灾难性的。 沟通的问题为认为本质上就是信息不对称。下面以日常沟通及会议沟通做一些浅显的讨论#xff…日常开发和工作中会经常遇到沟通不畅的问题communication 不论是在学术还是实践中都是一个很重要的议题。因为低效的沟通造成的开发事故有时候是灾难性的。 沟通的问题为认为本质上就是信息不对称。下面以日常沟通及会议沟通做一些浅显的讨论并警戒自己在以后工作生活中做到有效的沟通。 一、 日常沟通 1. 明确问题 两个人讨论问题如果A开口就是 昨天那个程序又挂了你那有备份么 那么B的内心一定是 What a fucking question it is 先说AA的沟通是低效的甚至可以说是一句废话因为这句话中最关键的信息被遗失了。 A内心的想法可能是昨天不是跟你说过这个程序的事吗所以我跟你讨论这个挂掉的程序你应该是知道我在说什么啊。 但是B不一定知道他从昨天到今天处理了这么多事即使昨天跟你一起处理过这个程序他也无法一下子反应过来你说的是什么。 实际上这里的不对称就是A在表达时默认一些信息是公共的是你我都知道的然而大部分时候这些被默认的信息都是重要的且不公共的。 如果A的表达换成昨天那个unix时间戳转换程序我改了一下出了bug你那还有之前的备份么可能B一下子就能get到你的点了。 这里要说一下跟别人说明问题的时候一定要言简意赅。尽量用最少的语言去表达最重要的信息 1. What is the problem 2. How serious the problem is 3. What is the effect of this problem 大家工作每天都很忙要在有效的时间里传递最有效的信息。 在说明问题商讨方案的时候要把问题是什么说清楚问题的严重性说清楚问题的影响说清楚。 尽量不要把你发现问题的过程啰里啰嗦地讲给别人我是因为发现了***问题然后发现***最后我发现这个问题是****所以我猜测这个问题是***。 最开始沟通的时候这些描述是多余的。 先把目前遇到的问题明确。接下来再去详细说明问题的来源和过程说明问题不是空穴来风。 2. Feedback 沟通中的反馈是非常重要的根据谈话者的反馈来确定沟通的内容能帮助我们提高效率。 如果A是任务的发布者要主动确认任务接收者的理解是否与自己的意图相同保证信息的对称性。任何默认彼此都知道的公共信息都是危险的。尽可能的把重要的信息传递出去不管对方知不知道。 如果A是任务的接受者要主动反馈自己对任务的理解确保与任务的发布者对任务有相同的认识。避免造成理解偏差做南辕北辙的事。要重视开发中的需求再确认。 Double check could be applied everywhere. 不论是在需求开发还是测试中反向确认都是重要的。只有弥合了信息的不对称才能确保后面的路一马平川。 二、会议沟通 国内很多公司都开始向敏捷开发的路狂奔。但是我在工作的时候发现大家只是东施效颦没有真正的去思考敏捷开发到底敏捷在哪里更不要说正确应用了。 我这里以每天的例会为例说一下我对例会中沟通的敏捷的理解。也就是Scrum中的Scrum Daily Meeting。 Scrum Daily Meetings are strictly time-boxed to 15 minutes. There are three questions that each team members need to answer: 1. What did you do yesterday? 2. What will you do today? 3. What is blocking progress? 关于daily meeting所有的教课书都强调两点15分钟时限的严格控制三个问题的回答。 敏捷开发是一种源于经验的科学理论对日常会议作出时限的要求也是大量实践的结果当然也是结合团队规模的结果。如果一个团队7个人的话则平均每人个人说话两分钟。加上团队成员间的交流互动促成这15分钟。但是现实中的日常会议经常演变成以下两种 1. 流水账 有的同学喜欢把这一天细枝末节的事情都罗列的说一遍诸如审核了谁谁的代码开发了啥啥功能补充了什么什么文档。这些内容冗长而乏味既不能体现出项目的进度也不能使其他队员参与到讨论当中更别说回答三个问题了。这样的报告基本上就是在浪费时间更别说敏捷了。 2. 技术及方案的讨论 经常在日常会议的时候有的同学喜欢把今天写了一个什么算法用了什么技术拿出来讨论一下几番讨论就变成了争论不休而且这样的讨论在这种会议中即无法给出合理的方案会议时间短讨论者之间对问题和进度的理解不同无法达成一致也说不清楚目前问题的所以然如果别得同事与这个问题无关就变成了团队中某几个人的秀场其他人无聊且不耐烦的等待了。 私以为daily meeting 是以贯彻项目进度为导向的团队成员聚在一起讨论是明确项目的进展如何有哪些不可抗力的阻挠eg时间规划硬件设备资金人手等等需要团队提供帮助的以及一些分工合作上的交流。 实际上敏捷团队中有一个重要的角色是Scrum Master这个角色有一个重要的职责就是控制会议时间使会议变的高效。 在团队成员的日常总结空泛时应该主动询问今天重要的进展是什么困难是什么其他人如何配合你完成工作接下来的计划和方案是什么。 如果团队中个别成员陷入了与会议主题无关的讨论时应及时终止争论切回项目进展的正题对于具体的方案诸如算法开发细节的讨论应该会后安排时间讨论。 敏捷开发中的日常会议可以提供给团队更加清晰的项目进展帮助团队合理的分配和优化资源时间人手硬件设备等等以此来提高团队的效率。 其实在工作中我发现Daily Meeting 中团队成员间的讨论和互动也可以很好的培养团队凝聚力的以及成员之间的工作默契等等。 我在这里反思一下 我最近工作中处理一些数据但是机器不够用开会的时候缺没有把自己的困难说出来以至于一直进度缓慢问题和困难也没有得到及时解决。没有机器怎么办借呀 转载于:https://www.cnblogs.com/philipce/p/6979344.html
