事件概述
事情发生在大概一个半月之前的一次showcase会议中，整场showcase会议可以称得上是车祸现场，某位关键stakeholder对于团队开发出来的插件功能并不买账，对团队接下来计划开发的查询功能也不认可，并给出了“No value”的评价，而团队则为自己所做的产品特性据理力争，试图证明这些特性的重要性，最终的结果是showcase会议在非常尴尬的互相道别中草草收场。
事件复盘
当尝试回过头去复盘整个事件的时候，我们才发现其实整件事情已经发酵了很久了，现在尝试按照时间顺序复现整个事件：
2018年12月，与stakeholder面对面的沟通项目愿景和任务优先级；
2019年1-2月，与stakeholder每两周一次线上沟通接下来两周的工作内容和优先级，期间stakeholder提到希望团队能提供一个开发者界面帮助最终用户能更方便的使用系统；
2019年3月-5月，关键stakeholder休假，定期沟通中断，团队根据自己对项目愿景的理解，排定了交付计划和任务优先级；
2019年5月10日，关键stakeholder休假归来，假期之后第一次参与项目showcase会议（车祸现场）；
2019年5月10日 -- 2019年6月18日，项目团队暂停了showcase会议，由PO出面与关键stakeholder进行一对一的沟通；
2019年6月19日 -- 2019年7月，项目团队与stakeholder进行了5轮feature list和优先级的讨论，初步制定了项目接下来的优先级和开发计划。
事件分析
通过对整个事件的时间线的梳理，我们可以得出一个结论，所有的问题就发生在3月到5月的两个月时间里。团队与关键stakeholder的沟通处于彻底断开的状态。此时的stakeholder对于团队目前的开发进度和状态一无所知，因此无法准确的定位出项目团队当时所处的阶段。因此也就无法对于优先级作出一个准确的判断。而团队这边因为是面对众多stakeholder的showcase，因此也无法打断showcase的节奏去分享更多的业务上下文和作出当时优先级判断的依据。
披露信息
参照披露信息的过程中我们常犯的几个错误：
团队在整个披露信息的过程中一共犯了如下的几个错误：
1. stakeholder休假回来之后，没有在showcase之前及时分享团队当前的状态和阶段，在showcase之前没有充分的分享业务上下文，一上来就直接谈团队的决策；
2. 团队对于showcase会议的沟通目标没有一个清晰的定位。showcase会议并不是一个单向信息传递的过程，同时也是收集stakeholder的反馈，修正团队前进方向的过程；
3. 会议之前没有跟stakeholder拉通上下文，对于stakeholder可能提出的问题和可能出现的反应缺乏充分的准备；
4. 团队对stakeholder的真实诉求没有清晰的认识。stakeholder参加showcase会议主要是为了关注团队的发展方向，评判一个或几个产品特性的重要性并不是关键，stakeholder希望看到的是自己提出的需求得到重视和考虑；
5. stakeholder对于搜索功能的评价是“No value”，这显然是一个观点，而非事实；
6. stakeholder对于团队工作成果的一系列主观评价，已经开始进入指责团队的范畴；
7. 团队在被stakeholder指责的情况下，情绪化的为自己的决定辩护，进入被动放手模式，实际上是自降一等；
8. 团队在无法当场弥合分歧的情况下，不是讲分歧的焦点进一步弄清楚或分享更多上下文，而是为自己的决定辩护，实际上是否定了stakeholder的判断，当场作出了否定的决定；
9. 团队在长达两个多月的时间里，与stakeholder断开联系，没有保持持续的沟通，后面直接进入showcase的环节，双方的关系其实没有得到很好的铺垫。
由此可见，此次沟通的双方，讲披露信息过程中可能会犯的几个常见问题都犯了一遍，堪称高效沟通的教科书一般的反面典型。
阐述意见
与此同时，根据阐述意见时的乔哈里视窗模型：
阐述问题的过程中应该尽可能的缩小盲目区，保证一定程度的隐秘区，尽量扩大沟通主题部分的开放区。可是反观上面的那起沟通“事故”，我们可以明显的感觉到，沟通的大部分内容其实是处在隐秘区的，也就是项目团队对过去2个月发生的事情是清楚的，但是这一块对于stakeholder来说是完全未知的一块区域，由此便注定了那次沟通不会特别的成功。
高效倾听
在我们谈到高效倾听的时候，我们说要适应讲话者的风格，要用耳朵和眼睛一起听，要有同理心，要控制好自己的情绪，不可以打断别人。但是在那次showcase会议中，双方都没有尝试着去理解对方，不停的打断对方的表达，到最后双方甚至都开始带着情绪在沟通了，所谓的同理心更是无从说起。
处理异议
在说到处理异议的时候，我们需要管控好自己的情绪，梳理对方的情绪，要有同理心，要把自己摆在一个中立的位置。要学会使用认可-询问-调整的衔接技术来处理异议。
可是在那一次的showcase会议中，双方都没能很好的管控自己的情绪，stakeholder率先进入指责模式，团队则奋起反抗，据理力争。在自身情绪失控的情况下也不断的刺激对方的情绪升级。整个过程中双方都已经给自己预设了对立的立场，没有尝试从对方的角度去思考这个问题，毫无同理心。认可-询问-调整的衔接技术难觅踪迹。
非语言沟通
整个沟通过程中，团队成员一个个眉头紧锁，争论到激烈时甚至面红耳赤，而stakeholder的一方，双手环抱在胸前，止不住的摇头，表情落寞而无助。双方通过自己的语气语调和身体语言不断的将负面的信息传递给对方，不断的推动这矛盾向更进一步升级。
说服技巧
可以看到在整个沟通过程中，什么聚焦，什么钟摆逻辑，利益逻辑全都看不到。两方面都是非常简单粗暴的通过列举对方的漏洞来证明自己的正确性，场面一度非常的尴尬。
危机处理
这次沟通对于团队来说确实算是一个不小的危机，从上面的事件复盘中可以看到，showcase之后团队采取了一些列的措施来处理此次危机：
1. 取消了后面stakeholder会与团队产生大面积接触的会议，改由项目的PO与stakeholder进行一对一的沟通，介绍了过去两个月团队的工作内容以及决策的相关上下文，一定程度上缓和了一度紧张的关系。
2. 与stakeholder一起开始重新梳理产品的特性列表，按照统一的标准给定所有产品特性的优先级。
3. 此后在每一个大的epic story开始之前，会与stakeholder一起kickoff这些epic story。
对应危机处理的几个要点我们可以看到：
1. 第一时间：在发现分歧无法调和的情况下，及时的中止争论，中断了整件事情向更坏的方向发展的趋势。
2. 打消担心：在安抚好团队内部情绪的同时，与stakeholder建立了一对一的沟通，也打消了stakeholder对于团队合作度上的担心。
3. 给点甜头：邀请stakeholder一起重新制定项目的特性列表。
4. 集思广益：团队成员与stakeholder一起制定项目的产品特性列表，充分的解释每一条特性的业务价值。
5. 牵线搭桥：引入与stakeholder关系密切充分信任的第三方stakeholder参与产品特性列表的重新制定。
6.寻求共鸣：基于产品特性清单，重新制定产品的愿景，并与整个TechOps的愿景保持一致。
7. 建立信任： 通过重新制定产品特性清单的过程，让stakeholder看到团队寻求合作的开放程度和意愿，开始逐步的建立互信。
8. 寻求共赢： 在重新制定产品特性清单的过程中，充分考虑来自stakeholder和团队的诉求，并按照统一的标准给定优先级排序，使得双方的诉求都得到了考虑和反映。
结论
现在回过头去思考整个事件的酝酿-爆发-处理的过程，我们可以看到高效的沟通是多么的重要。沟通过程如果处理得好，将会是一个融合多方利益，增进互信，加强理解，互利共赢的过程，最终的结果就会是win-win。如果不能很好的掌握和运用高效沟通的技巧，不仅无法使得多方利益得到良好的融合，而且会伤害双方的互信和理解，最终面临的一定是lose-lose的结局。
在我们努力将项目做到最好的同时，也需要通过高超的沟通技巧使得stakeholder能够与我们达成利益的一致，从而将stakeholder变成我们项目的助力而不是阻力，带领团队从一个胜利走向另一个胜利✌️。