阿里云开发者社区,千万开发者的选择
阿里云开发者社区,百万精品技术内容、千节免费系统课程、丰富的体验场景、活跃的社群活动、行业专家分享交流,欢迎点击【阅读原文】加入我们。
阿里妹导读
前言
1、专业有gap,缺少共同语言;
2、目标达不成一致(部门墙);
3、进度不透明;
怎么减少类似的问题出现呢?以作者的经验来看,需要有这3个点:有意识、有方法、有习惯。
沟通意识是最重要的前提条件,只要知道了文中提到的这些坑,就能带着避坑的意识去结合方法论来应对了。
通过多次有意识的建立反射,慢慢会形成出了自己的套路打法后,相信沟通协作的效率、质量一定会有的提升。
不过要完全避免协作中的损耗是不现实的,还是不要想了,哈哈!
有时我们可能会说,一个人干活多爽啊?协调个啥啊?确实,对于牛X的个体,少协调确实是最高效的!但超出个人能力范畴,协作就无法避免。小到自己家庭,大到全地球,没得办法......
沟通损耗也是大组织管理上的挑战点之一,尤其是大项目干系人一大堆时,协作困难可以预料,带着一颗平常心就好。
作者想到这句话时委屈会好受一点,毕竟:一个人走得很快,一群人走得才远~
那么回到正题,我们先来看看影响沟通协作的因素有哪些。
1、影响沟通的主要因素有:
2、影响协作的主要因素有:
行为(可行性):结果影响:分配与沟通方式 =>能被协作
一、概念统一的意识
第一个要重视的意识是统一理解的意识,人与人之间的沟通不像是计算机中有固定的标准协议或编解码逻辑。通常会受双方的角色、地域、文化等因素影响而不同,建议大家在沟通中有意识的在容易误解的地方交互描述来确认对齐。
比如我们跟大陆同学说“土豆”这个词,大概率是会被认为跟“马铃薯”是同一个东西,而台湾同学可能以为是指的“花生”。
据说曾经有个大陆朋友去台湾地区玩,进餐馆要一盘“炒土豆丝”,厨师却生气的出来把他拉进了后厨,指着一粒粒的花生吼道:
“你来给我切成丝看看?!”
“......”
当我们在某个环境习惯后,对周围人的理解一致性感知会弱化,而刚到新环境、经常做跨角色沟通的同学体感就比较明显。比如下列这些熟悉的常用词,作者之前随机问过一些实习同学、外包同学、原厂同学,他们的回答和预期还是有很大偏差的。
产品:产品是指被人们使用和消费并能满足人们某种需求的任何东西,包括有形的物品、无形的服务。
服务:不以实物形式而以提供劳动的形式来满足需求方,服务也是产品分类的一种。
项目:有临时性、独特性、阶段性的特征,一般需要明确走立项流程,用标准化的项目管理手段来管理的工作项。
问题:由于某些原因导致不能达到目的,现状不理想的部分,没有被解决,或者事态出现了意外。
事件:内部主要指业务中遇到了比较严重的异常,比常规问题影响程度更大,但还不至于定为故障。
故障:故障是导致整个系统功能恶化的事件,在技术团队中往往有明确的条件定义和故障级别,如P4S1。
风险:生产目的与劳动成果之间的不确定性,强调影响预期结果收益、成本、代价的不确定性。
运维:通过网络监控、事件预警、业务调度、排障升级等手段,使服务处于长期稳定可用状态。
运营:运营管理指对生产和提供公司主要的产品和服务进行设计、运行、评价和改进的管理工作。
经营:含有筹划、谋划、计划、规划、组织、治理、管理等含义。经营和管理相比,经营侧重指动态性谋划发展的内涵,而管理侧重指使其正常合理地运营。
当然,还有不少内部术语,常常以为对方懂,对方以为我方懂。像阿里内部的术语、平台名、项目名也是非常非常的多。
像弹内、弹外、站内、站外的概念,整个集团技术同学和非技术同学的理解想要完全一致是很难的。
所以常用语也要慎用,看对象,使用时尤其注意对方的理解。
二、协作定位的意识
沟通前给对方的定位是什么?可以参考使用“RASCI矩阵”分析
RASCI
R-责任(Responsible)
负单责的人,负责项目中某块工作的拆解、解决、执行,可以有多人。
项目组内的骨干,单类工作中可有一人或多人,酒店中可能是厨师长、大堂经理,也可能是厨师、服务员、收银员。
A-批准(Approve/Accountable)
能决策的人,一般是做统筹的、有决策权、解释权的一号位,虽然不做具体执行,但出事儿他要去向上头解释、负最大责任。
某方面工作只能指定一人、仅能指定一人,如公司老板、总经理、法定代表人、总工程师、项目经理。
S-支持(Support)
给支持的人,3不原则:不主动、不拒绝、不负责,只做明确需要支持配合的部分工作。
一般是项目外的干系人,但也非常关键,比如在开饭店时,有食材供应商,还有消防、城管、工商、税务等部门。
C-咨询(Consult)
可咨询的人,拥有完成项目所需信息的人员、专家,可以给出线索、方案、建议、评审意见。
一般是项目外的干系人,有必要信息、管理经验、技术经验、商务经验、财务经验、法务经验的人员。
I-通知(Inform)
工作中要通知的人,有必要告知的、有诉求要知晓进度结果的人员,例如相关领导、未能参与项目的新同学。
通过RASCI的责任矩阵的思路可以非常好的帮我们把各部门各个人的工作责任、范围、分工划分清楚,避免协作中的误解。
当然,除了非常正式的项目开展,否则不用每次都做个表搞得太细节,但日常沟通有这个意识很重要,心里带着定位再去聊,效果会更好。
三、适当的沟通方式
阿里内部的沟通工具非常多,以作者的个人经验来讲:
1分钟打字搞不清楚的语音聊
钉钉先看签名状态,然后简单表明要聊啥、约个时间,如果没收到回复再打电话
紧急还未联系上的去找备份的同学,不行再找他的主管协调安排,脸要大别腼腆
1个人说不清楚的拉群聊
5分钟群里打字还说不清楚的,约上相关同学开短会来聊
1天搞不定的任务,记代办
发Aone任务、Teambition任务、钉钉任务等,记给对方和自己,方便有自动提醒
1周搞不定的事情,记Aone
关联上其他相关的需求、问题、文档,中午吃饭前看下回复,晚上下班前再瞅一眼。
四、正面表达的态度
有本非常知名的书叫《非暴力沟通》,内容不多,推荐看看。书中作者总结下来最核心的表达公式是:
表达() = 客观事实 + 主观感受 + 我的诉求
接收() = 感知情绪 + 理解内容
表达举例:
负面:(评价)你的PPT写得屎一样,(判断)你个笨蛋 + (诉求)回去重写 + (情绪)愤怒高喊
正面:(事实)看到你PPT没加图都是小字,(感受)我难理解你表达的重点,(诉求)希望你加上图精简一版
减少干扰:
负面情绪是沟通内容的最大干扰,99%的人是优先接收情绪。
如果对方感受到的情绪占比越高,理解到的内容占比越少,所以是成反比关系。
五、逻辑表达的框架
参考著名的《金字塔原理》来组织语言或材料,S/C/Q/A的顺序可根据场景目的的不同来调整。
S场景
指某个场景下的客观事实,不包含主观判断的原始信息。
举个例子:张三蹲坑没带纸,厕所没纸也没其他人
C困难
张三有洁癖,接受不了没纸就起来
蹲太久了腿麻了,站不起来
Q问题
定义并抛出核心问题有什么?心脏、腿、还是没纸的问题?
A方案
直接提裤子出来
电话摇人来送纸
120叫救护车
平复心情再等等
六、逻辑表达的顺序
1. 找准关注点
分顺序的原则是判断沟通对象是什么角色,关注点是什么?
易出现的几种错误:
5.篇幅长没中断,没给接收者反馈的时间和机会
2. 按耗时顺序
先讲诉求、目的(n秒钟) => 确认是找他?
再讲价值、挑战(n分钟) => 为什么找他?要聊多久?
后讲细节、方案(n小时) => 为什么是他?下次啥时候聊?
甚至对方不是负责解决的、或无能力解决的人,白讲了一堆细节和方案
3. 按因果顺序
结果:影响范围、影响程度、影响损失、有无投诉
4. 按时段顺序
计划:Q1/Q2/Q3/Q4
七、挖掘事实的方法
七问原则
纬度:5W2H的全面问,逐项问
深度:1个原因挖深7层的问,而不是停留在表面
结合:用STAR原则结合场景,判断信息的前后一致性、合理性、真实性
STAR原则
常用在面试过程中,也可以用在描述进展上使用
八、目标制定的方法
我们知道常用的拆解工具主要有OKR和KPI这2种,一般组织内部也会有对应的绩效系统,有更详细的说明。
通常从个人的理解上来看:
OKR拆解
OKR(Objective & Key Results),中文名称是“目标与关键结果”,是一个目标管理工具。
O 是目标,回答的是“我和我的团队想要完成什么”
KR是一系列可衡量的关键结果,回答的是“我如何知道自己是否达成了目标”
KPI拆解
KPI 是 Key Performance Indicator 的缩写,中文是“关键绩效指标”,常见的KPI指标如:
医疗保健行业:患者等待时间、平均治疗费用
零售行业:坪效、每名员工销售额
人力资源部门:离职率、平均招聘时间
制定原则
常见错误是制订时写得太空或太细、不全或重叠,要注意的协作对齐的目标以及拆解项中,是否符合SMART原则和MECE结构。
结尾
由于时间关系,这里只是框架性的讲了讲,并没有结合太多工作中的具体案例来讲解,先在这里抛砖引玉了,欢迎留言探讨。
阿里云开发者社区,千万开发者的选择
阿里云开发者社区,百万精品技术内容、千节免费系统课程、丰富的体验场景、活跃的社群活动、行业专家分享交流,欢迎点击【阅读原文】加入我们。
文章引用微信公众号"阿里开发者",如有侵权,请联系管理员删除!