事情背景

运维人员将产品部署更新了一下，交给了产品经理，然后就开会去了。产品经理需要检查一下昨天交付过来的功能是否满足需求。

事情经过

收到运维部署成功的消息后，产品经理过了一段时间打开产品，发现账户的充值按钮点不开，没法继续进行下去了，就去问前端工程师有没有更新。

前端工程师检查了一下，回复产品经理说：更新过了。 但充值的按钮还是无法打开，产品经理没有办法继续测试，转而做其他事情了。

在早会的时候，我听运维说会部署一个更新给产品经理，按道理来讲，运维没有理由不去部署。 于是我就问了一下产品经理

问： “ 运维今天早上答应给你部署一下最新版的，对么？”

产品经理： “是的”

问： “那运维更新给你了吗？”

产品经理： “他说更新好了”

这个时候，前端插入进来说：“前端更新了，后端还没有更新”

产品经理：“还有后端？”

于是我问了一下后端工程师： “ 测试环境的后端，你可以更新吗？“

后端工程师： ”可以“

1分钟之后，后端回复产品经理：“更新好了”

至此，问题解决。

复盘

这事情很小，不至于引发员工的情绪。 于是我找来了运维来复盘了这件事情。

首先我要做的事情，就是尽可能的将事实以中立的态度描述出来。 我始终记在心里的的是

我要做的是启发员工，让他自己得出结论，而不是我直接告诉他结论。

我描述了一下事情的经过，并且跟他梳理了一下： 这件事情，经过了产品经理，前端工程师，后端工程师，项目经理， 已经快要覆盖了公司的全部人员（我们公司比较小），为什么呢？

运维回答我说： “因为前端更新了，后端没更新导致的。”

是的，这是一个表面原因，并不深入，于是我继续引导提问：“为什么后端没更新呢？”

运维：” 因为我也不知道要更新后端，如果我更新前端的时候，前端工程师能告诉我需要更新后端的话，我一定会去更新后端的“

问：” OK， 那么是什么原因前端没告诉你呢？”

运维： “ 可能前端也忘记了吧？“

问： “那你想一想，有什么方法规避这个问题呢？”

运维：“ 如果前端和后端都在群里说一下，那就好了。”

问：” 嗯。这个方法不错，所以，你需要前端和后端更新好代码后，在群里通知你一下”

运维： ”对的“

到此为止，取得了不错的进展，运维意识到自己的错误来源于自己的信息接收不全，他需要得到前端和后端的帮助。 而谈话在之前，他自己是完全没有意识到的。

然后我又继续提问：”你注意到没有，从你跟产品经理说部署好了，到产品经理反应遇到问题，期间过了40分钟？“

运维思考了一下： “是的。”

问： “为什么呢？”

运维：“ 我不知道哎。“

问： ”OK，那我换种说法。 如果产品经理，或者其他人知道后端没有部署，你觉得产品经理遇到问题时，会怎么办？”

运维：“他会立即来问我。“

问：” 对，那么这个假设和现状，差异在哪里？“

运维：” 因为产品经理不知道。”

问：“ 对， 你再想一想， 项目经理知道吗？前端知道吗？ 后端知道吗？”

运维：“他们也都不知道，我只跟产品经理一个人说了。”

问：“ 嗯。那么有什么优化方法吗？”

运维：“有啊，我把部署的信息发到公司大群里。 前端或者后端会知道后端没有部署。“

运维顿了一顿：“其实，我早上在群里写了，然后觉得这样的小事，都往群里发，可能打扰到其他同事。”

我说：“所以，你的第一个问题的答案是，需要前端和后端在群里通知你。 这个问题的答案是，你需要在群里通知其他人。 现在能够理解群里通知消息的作用了吧“

Bingo， 最后的答案出来了。 因为运维心理觉得部署一个版本这点小事，不值得在群里说， 于是选择了不说。 最后的心结在这里。

我的收获

提问法与说教法

在提问之前，我有一个假设：这位运维小伙伴没有意识将这些信息传递给其他同事。我需要告诉他，你每次部署的时候，需要将信息告知在群里。

事实却出乎我的意料，我的假设并不正确，他并不是因为不知道而没做，而是觉得做了可能对其他同事造成打扰，于是没做。

如果我没有采用提问的方法，而是一上来就采用了说教模式，我会说：”今天发生了这件事情，是因为你没有将部署信息发送到群里，请你下一次将部署信息发送到群里，这样能够保证信息的流通。 “ 我就无法获知到这个最根本的原因，而对方也无法真正理解为什么一定要这么做。

思维模式升级

思维模式从说教模式转换到引导提问模式之后，相当于做了一次思维模式的维度升级。在新维度上我做的一般，甚至略显笨拙，但依然能够收获到比之前的模式更好的效果。