各位朋友大家好呀，我是身处北京还没有阳的天机术士~
今天写这篇文章的起因是一件小事情。我在现在的公司已经快三年了，最近来了一位刚毕业的实习生，老大交给我来带，顿时受宠若惊。（北京都这样了，佩服这位实习生小哥）
经历了初期的入职阵痛，小哥逐步开始接触到我们日常的开发中去了。我交给他了一个小需求的迭代，很简单的增删改查（入门嘛，先学走再学跑嘛）。从代码上看，小哥其实完成的还不错，编码习惯不错尤其是喜欢写注释（比我强，作为老家伙懒的一比），模块划分的也还算清晰，在新人里就算是不错的了。但是作为旁观者跟他开了几次会，发现小哥的一个问题：沟通能力不大行。主要表现在，陈述事情的时候，逻辑不清晰、因果不明确、表达不完整，就觉得好像说明白了但是听的人好像又不知道他在说什么。
为啥会这样呢？我想原因有很多，比如：在学校里缺乏锻炼、对需求了解程度不够、临场发挥紧张.....这篇文章，不给大家说那些干巴巴的原理，咱直接按照在你发言中的角色和发言的受众总结一批发言公式给大家套，走起！
作为沟通中的甲方
说道这儿估计就有人纳闷了，咋出来甲方了呢？我最恨的就是甲方......
非也非也，此甲方非彼甲方。在发言中，甲方可以理解为发言的主动发起方，是需要你输出自己的知识、见解、结论的，是需要你给对方提供信息的。既然是提供信息，那么你就一定要注意发言要全面、要准确、要尽可能说清楚前因后果。
对方是程序员
公式：业务背景+业务问题+解决方式（方式1、方式2.....重点）+技术特点+分析优劣+我的选择+需要大家做什么（如果有）
对方如果是程序员，他一定更关心你的技术特点和实现方式。这种就要求你 1、说清楚背景，让对方对做的事情有个概念便于评价你的实现方式。2、重点介绍你的解决方式和技术方案，尤其是优劣分析
例子：我们支付系统对接XXX上游的工作已经完成了，目前我们返回支付结果的方式是同步的方式，即对方调用我们的接口，我们进行支付，在接口返回中返回支付状态（业务背景）。但是，在实际支付中经常会遇到支付时间长导致上游调用接口超时的情况，引起上游支付失败。而上游后续重试支付的时候，又会发现上面已经成功了，进而导致重复支付的问题（业务问题）。为了解决这个问题，我们需要改造这个接口，采用异步支付的形式，支付接口返回中间态“支付中”，后续支付完成后再通知上游系统最终结果（解决方式）。实现这个功能的方式有三种：1、接口新增上游回调地址，我们通过回调地址发送最终结果；2、发送kafka消息，由上游监听topic；3、上游主动查询。他们的实现方式是：......（实现的N个方案和技术特点）他们的优劣是1、实现比较复杂，需要记录地址，而且需要有重试......2、不够保险，不知道下游收没收到......3、上游主动调用，可能给系统机器造成压力......（优劣分析）我的选择是：方案1和方案3结合，理由是：......（我的选择）请大家看一下，我这个方案有没有什么问题？（需要大家做什么）
对方是产品或业务
公式：业务背景+业务问题+问题根源+解决方式+为什么能够解决+会不会有后续问题+如何运维
如果对方是业务或产品，那么他们对技术细节就并不是那么关心了。他们关心的是，现在的问题的系统根源是什么，你的方式能否给我解决问题，是临时解决还是长期解决，后续如果有问题的话运维需要怎么进行（发生了什么事的时候，我应该找谁，或应该使用什么功能）。
例子：我们支付系统对接XXX上游的工作已经完成了，目前我们返回支付结果的方式是同步的方式，即对方调用我们的接口，我们进行支付，在接口返回中返回支付状态（业务背景）。但是，在实际支付中经常会遇到支付时间长导致上游调用接口超时的情况，引起上游支付失败。而上游后续重试支付的时候，又会发现上面已经成功了，进而导致重复支付的问题（业务问题）。这个支付时间长短的问题，是由银行决定的，我们难以把控（问题根源）。因此我们将整个过程分为了两个步骤，也就是异步化。我们收到请求支付，除了必要的校验，立即返回一个“支付中”的中间态；而后我们在后台等待银行支付，有结果后再主动通知上游系统最终结果。这样上游请求的第一步很快就能完成，就不会有超时问题了。（为什么能够解决）后续可能在通知结果的时候会失败，那么我们开发主动查询结果的功能，允许上游一段时间后查询支付结果。（会不会有后续问题）如果还有问题可能就需要具体问题具体分析了，这个方案一般不会出现别的问题（如何运维）
对方是老大或老板
公式：业务背景+业务问题+解决方式+为业务创造了什么价值（重点的重点）
如果对方是你的上级或者老板，那么他们并不关心你用了多牛B的技术，或者多花哨的写法，他关注的是，你给业务创造了什么价值。这种最好有数据支撑：我们创造了多少收入，降低了多少成本，给业务提升了多少效率，减少了多少工时等等等等。
例子：我们的公司是集团公司，因此子公司有非常多的账户，这些账户每个账户都有少量的流动资金便于子公司进行使用。而这些资金汇聚起来是一笔不小的资金，我们可以利用这笔资金进行理财或投资实现公司资金利用的最大化。（业务背景+业务问题）为了实现这个目标，我们建立了总账户体系，每月定时由下级账户向上级账户把所有余额收集上来，而需要支付的时候，有上级账户实时向下级账户打钱，这样就能解决这个问题（解决方式）。建立完这个父子账户体系后，我们集中管理了XXX个账户，给公司创收XXX万/年的收入......（为业务创造了什么价值）
作为沟通中的乙方
如果我们在沟通中是处于乙方，也就是信息的接收方，一般来说并不需要我们主动开启发言，而是需要我们倾听甲方的发言，解答甲方的提问或响应对方的诉求。一般来说，需要倾听对方提供的背景、做的事情、目标以及需要我们提供的信息
公式：提问（不清楚的地方彻底搞懂）+复述甲方意图（拉齐两方认知）+能够提供的信息
例子：刚才你提到的XXX我不是很懂能重复一下嘛？还有就是XXX为什么这么做？XXX用YYY这种方式做不行吗？（提问）。哦哦，我明白了，那我理解你们实际上是要做XXX这回事儿对吧，因为XXX所以你们要XXXX这么做，因此你们需要我们提供XXX信息（或XXX帮助）。（复述甲方意图）那么针对于这件事，我们可以提供的帮助是：XXX，需要XXX方的开发或沟通，你们应该注意XXX。（能够提供的信息）
写在最后
其实沟通时程序员最重要的几个技能之一。我一直认为，技术能力决定了一个程序员的下线，保证程序员不至于没有饭吃。而沟通、汇报、总结、反思等等的软实力决定了一个程序员的上线，能够让程序员走得更高更远。仅仅是沟通一项就有很多方式，一句意思相同的话能够有一百种表达方式。如何能够让对方听着舒服，进而接受你的思路是一种能力。我们还是应该在日常生活中，观察你的leader或老板是怎么表达的，能走到他们的那个位置，大概率这些能力都是非常强大的。
最后，谢谢你“点赞”、“评论”我的文章，我是天机术士，下次见~
