人类厌恶“不确定性”就像大自然厌恶真空一样。很多人一直在追求“确定性”这种命根子似的东西，一旦有了确定性的东西就会死死抓住，心里也踏实了！
为了防止老无所依这种不确定性，我们就在年轻的时候拼命挣钱；听各种鸡汤非鸡汤的讲座文章等，减少自己对当前或者未来没有确定性的焦虑感；拼命进国企央企考公务员，降低随时会失业的风险。买保险、多生孩子、看风水占卜、大家都希望能够互相坦诚等等，都是为了降低我们对于当前或者将来出现不确定性的焦虑感。事情只有“确定下来了”才踏实。
技术支持这个岗位，作为产品研发和用户之间的重要桥梁，应该想尽办法去把很多不确定性变成确定的事情。努力输出确定性信息，减少不论用户还是研发的焦虑感，让各方心里更加踏实。
以最常见的线上问题的处置为例。当出现线上问题，一般情况下，刚开始都是一通慌乱。研发和用户之间的天然交流障碍在这个时候暴露无遗。
研发定位解决需要用户提供相关信息来去排查问题，研发的需求往往是
“ID多少？”、
“报错是什么？”、
“操作系统/浏览器/app版本号多少？”
用户的回答一般是“用不了了”、“看不见了”、“不知道/我哪知道”等等。双方根本不在同一个频道上，鸡同鸭讲对牛弹琴。这种信息交流方式，让问题排查过程更加漫长。研发不知道用户那里发生了什么，用户不知道怎么办。
这个时候就需要一个角色去把这个拧巴的沟通捋顺了。技术支持这个时候一般会想把发把研发需要的信息翻译一下。譬如“用户ID多少”翻译成“用户注册手机号多少”；“报错是什么？”“操作系统/浏览器/app版本多少？”翻译成“能录一小段视频吗？”。
在给研发想办法提供有用（确定性）的信息的同时，也会向用户传达一些内部信息，如“这个问题我们研发已经捕获到了，正在紧急定位问题中，目前我们先建议您重启设备/清空app缓存/退出重进/重启路由器/XXXX方式进行重试，问题一旦解决我们会马上通知到您”。这个时候大多数用户知道了自己的问题已经被重视，并且正在解决中，不是没人管没人问的状态，用户就“心里有了底”，情绪会平静很多。
在整个处理过程中，技术支持需要紧跟问题解决的进展。一方面适时向研发要修复进度或更加靠谱的临时解决方案，另一方面要及时观察用户侧的反馈情况，是否有新的问题并做及时快速靠谱的反馈，直到问题解决。另外还要排除一些杂音，譬如不相关的问题等等。这个时候技术支持就在不断地给产研和用户直接传达相对“确定性”信息，让双方更加安心。
其实在这个过程当中，为了让信息传递更加有效，固定固定的群刷进展信息，通知不同的团队接口人，我们其实也做了一些工具化的东西来让信息尽可能地传递给相关人。我们自己做了一个信息推送系统，在各个业务系统上进行弹窗提示，把当前进展和话术发送到相关团队。在这个信息推送系统上，我们还做了最终用户侧的触达信息功能。一旦出现紧急情况，我们会根据影响范围直接给受到影响的用户进行app或短信推送。就是用这种方式把“确定性”发送到用户心里，给用户吃个定心丸，耐心等待问题解决。
不光是出现线上问题的时候，确定性信息可以帮助产研和业务人员减少焦虑感，一个新业务刚刚开始运行的时候其实也需要“确定性”这种东西。因为人跟人直接默认是不信任的，一个新业务刚刚开始的时候团队之间不信任是正常的。业务方很可能对产研的能力产生怀疑，如果业务方和产研不在同一个物理地点，那这种怀疑情绪可能会更加浓厚，如果某个问题一直搞不定的时候，业务和产研双方的焦虑感会更强，这种焦虑感就来自于“不确定”对方能不能搞得定我的问题。技术支持这个时候可以做的事情就是，让双方都能“了解我的心情”，让双方都透明。
去年的时候，我司要上一个新的项目。项目开始不久就遇到了卡顿的问题，这个问题迟迟得不到解决。业务反馈自己和用户看直播卡顿严重，研发这边并没有发现很明显的问题。这个时候就有有意思了，业务那边觉得产研处理问题速度太慢，公司不够重视，就向上面施加压力。研发这边因为查不到“卡顿”的原因焦头烂额还要接受上面的压力，也很郁闷。因为业务方在D市，产研在北京，双方的交流大部分是在线交流，问题一直没有定位到。解决这个问题的关键是让双方互信，然后才能兄弟同心其利断金！
在这种局面僵持的时候，我冒着疫情的风险，亲自去了一趟D市职场。到了D市后，我先让接口人把所有这个项目的业务人员召集了到一个会议室。会议开始后，我首先对所有业务明确了公司和产研对这个项目的重视程度。我说：“这个项目请大家放心，目前是公司优先级最高的项目。产研这边专门从各个团队抽调了最骨干的人员组成一个专门的团队做这个事情，我介绍了一些产研人员的北京和从业经历，同时我也坦诚地表示新产品出现一些问题是绝对不可避免的，请大家跟产研一起努力帮助我们提升产品质量，共渡难关。并在现场保证，当前的这个状态没有进展，我就不回北京。最近大家业务时间，我会跟大家一起在会议室解决问题……”。这个话我说了两遍。业务就说“您这么说，我们就心里有底了。我们一直觉得公司并不重视这个项目，我们反馈的问题一直得不到明显进展”。我说，请大家放心，别的话不多说了，看行动吧。
在D市这几天，我每天跟业务在一起，观察他们反馈的问题，同时向研发反馈这些“去掉噪声”的问题。为了减少领导的焦虑感，每天不论工作到几点，都会整理一个邮件反馈给产研和业务的老板们，让老板们了解进展的同时也让他们看到事情是一直在往前进展的状态。为了让业务们更加信任产研的决心，除了把产研的值班表发给业务看，我还让北京的同事录了一段视频，这段视频内容是一群高P研发就在距离直播间几米的会议室里做保障，这段视频业务们看了以后，情绪就好了很多。有几个业务反复说“我们心里有底了”。在以后与产研交流的过程中互相信任了很多，很多问题得到了澄清和解决。在跟用户交流沟通过程中也不再焦虑烦闷了，有问题就大大方方承认这个问题我们已经在解决了并告知临时解决方案，如果有确定的解决时间，也会告知用户。几天下来，投诉明显下降。不论是用户、业务还是产研都松了一口气，我也顺利返京。这就是传播了“确定性”信息的效果。
除了在用户和产研之间传递确定性外，技术支持岗位也要在产研内部传递确定性信息。这个确定性信息就是当前线上问题整体是个什么状态。以督促相关团队对问题能够进行客观评估，合理安排项目排期，提升产品质量。
我司在早期奔跑阶段，产品需求比较多，产品质量和易用性相对粗糙一些，线上问题也是频繁出现。一旦出现用户反馈，技术支持岗位是最能够很快感知的，一旦弄清楚以后每天都会回复类似的答复，工作非常枯燥，并对研发会有怨言。为了解决这个问题，我们在数据——能够传递“确定性”的东西上面做了两件事情，
一， 所有线上问题统统记录下来，并且还自己开发了一个小工具开放给业务方，让他们也记录下来所有疑似线上问题。技术支持对这些问题粗筛一遍，然后找研发再对一遍，最后整理一个线上问题列表展示给研发的VP。在得到我的老板和对应研发VP的支持后，形成例会机制，相关团队的负责人到场解释问题并给出修复的方案。经过将近一年的努力，线上故障时长降低了70%，倒逼问题解决的同时，加速了老的系统架构下架的进程，提前了4个月。我们就是通过给出具体的数据这种确定性信息，让研发对线上问题的现状有了清晰的认识，加速了线上问题解决的速度，提升了系统稳定性。
二， 把接到的各个渠道的用户侧的问题反馈统统记录下来，进行分类整理并存入自建的数据库中。把不同问题分门别类，按照周的时间维度进行记录统计，把这些数据每周发送到产研老板和各个团队，让产研对当前产品质量有了全方位的认识，在开发新功能的同时合理安排优化已有的产品，通过对这些数据一年运营，共计上线修复或优化项目200+。提升了用户体验。
在传递信息确定性方面本人有一些体会
1， 没有确定性信息的时候如何发布确定性信息。当出现问题的时候，用户侧都特别希望能够得到一个确定性的信息，譬如能不能修复，什么时间能够修复，甚至问题原因是什么。技术支持这个时候应该尽量把确定性的信息传递给用户侧。譬如修复时间，问题原因等等。但是实际业务场景中，可能我们很难马上给出这么确定新给的信息。往往研发还没有定位问题，用户的这些问题已经到了。
这个时候我们虽然不能直接给出类似“还需要X分钟or天能够恢复”这种确定性的信息。但是技术支持要有这种能力：在不确定性的环境中找出确定性的信息的能力！线上问题在定位中或者产品优化中，具体什么时候上线我们还不能确定，但我们可以向外界传达类似这种信息“这个问题我们技术团队非常重视，目前已经在集中力量定位问题了，请稍等，有进展我们会马上同步给大家”，或者“这个功能优化的建议已经提交给产品部门，他们近期会尽快评估改进方案，争取早日上线优化”等等。这种信息发给用户的时候，实际上是传达了一种信息，问题已经有人在跟进处理中了，并不是没人管没人问的状态。大部分用户得到这种相对确定性的信息后情绪会好很多。千万不要固执地认为只有问题彻底修复了才是确定性的信息，才彻底修复了可以告知用户。很多情况下，问题处理不是几分钟内就能够完成定位并修复的。如果一直什么都不说，等了很长时间才告诉用户“已经修复了”，估计这个等待过程用户都要爆炸了。技术支持在这个等待的过程中要积极主动跟进问题进展，要从研发那里了解实时进展。如，当前是否有人在跟进了，是否有临时解决方案，是否定位了问题，是否修复等等。因为如果技术支持不主动问题，研发可能要等到彻底修复了才会在群里说一声“已经修复”。这个时间天知道要多长！
2,上面我说了确定性信息能给用户带来安全感，但也要客观表达，否则可能会带来更大的麻烦。我们可以在语言组织上做一些处理，但是我们不能把歪曲事实，因为一旦我们原来的信息被用户证明是错误的信息，用户的情绪会更加激烈。
3, 传递确定性信息一定要高效。首先要建立一个高效的信息传播机制，保障渠道畅通。对接不同的业务部门，尽量保持接口人相对固定，一旦出现问题能够有效地通知到各个团队。其次要建机制和工具，减少对人的依赖，通过机制和工具减少人为因素的干扰。再者，多演练，一切机制工具人员等等都是文字，需要不断演练和磨合才能让这些活跃起来，并能够及时发现问题。我的团队在这件事情上是花了不少时间的，线上问题特别频繁的那段时间我们团队内部并邀请相关团队双周做演练，效果特别好，通过演练让每个参与人在出现问题的时候不再懵逼，按照章法操作，降低了50%以上的反应时间。
4, 尽最大可能给出预期减少焦虑感。一个被蒙着眼睛的悬空的人，如果不告诉蒙眼睛的人离地面有多高，即使脚尖离地面只有两公分这个人也不敢往下跳，如果告诉这个人脚尖离地面两米他也敢往下跳。告诉用户问题能够解决的预期时间和方式，就相当于告诉了用户脚底下还有多高就可以触及地面。让用户心里踏实，减少焦虑。
如果您觉得上面的内容能够对您有一点点帮助，也请在下方进行讨论沟通，当然更希望您能转发，去帮助更多的小伙伴，多谢！