分享个观察：牛人是怎么力挽狂澜的？怎么救起一个连续失败了多年、其他人都不能挽救成功的业务？

这是一位朋友的亲身经历。
她在几年前，被派到了一个连续失败了10年的业务。在10年中，这个业务换了很多任负责人，但是都没做起来。
最终，这些负责人基本都活不到2年。
但是，她一来，花了大半年的时间，业务就有了显著的起色。

她是这么做的——
1、
第一步，还是得先看到业务问题。
知道前人为啥失败。
真正可能带来转机的动作会是什么。
但是，这一步，其实一点也不难。

为啥呢？
因为这个转机本身，并不难看到。
至少，
公司还在持续换负责人，就说明公司是觉得业务有希望的，此前的负责人们在上任前，肯定也和公司讨论过自己咋做、咋改变局面。
这些讨论，也是得到了公司认可的。

她回头看，那些负责人的方案，其实都挺靠谱的。
任何一个方案，只要能落下去，业务结果都会很好。
但是，
可惜，所有这些方案，都没有得到被认真落地的机会。
这才是最难解决的问题。

2、
为啥好方案不能得到落地呢？
因为，
过去这么些年，公司一觉得业务没有起色，就马上换掉业务负责人。
公司做得也没毛病，毕竟判断是业务做的。
研发是无辜的嘛！
而且，如果连研发也换掉了，没人熟悉业务和代码，更难做。

于是，
10年过去，整个团队，就变成了铁打的研发、流水的业务。
但是，这些研发，是一帮连续跟着业务失败了10年的研发。

他们每个人，都是一堆失败经验的集合。
新的业务负责人，拿任何方案出来，在研发那儿常常得到的回应都是——
“你说的这个，我们在XX年做过了，没效果。”
结果就是，每一任业务负责人，想推的动作都落不下来。
你要强推。
研发们也会做，但是是明显不相信的做。
他们做的初衷，就是证明你会失败，自然动作就不会成功。
强推是没用的。

此前几任负责人，基本都是一心做事儿，结果挂在了这第一关。

3、
这位新任的业务负责人，在试着推了一下方案，被研发怼了两次后，就意识到了：
真正的问题，不在于业务上的方案和问题。
在于老团队——特别是老研发们的信心。

看清楚了局面，她就确定了解决方案。
肯定需要一场胜利。
只有由她这个业务负责人，能带来一场胜利，她才能够一点点建立起来研发团队对自己的信心，才有推动整体方案的机会，业务结果才会改善。

于是，她做了三个动作：
第一，
现在，研发们的信心、对自己这个新人的信任，都在谷底。
所以，其实自己只有一条命。
如果争取到了研发的配合，一旦失败了一次，自己这唯一一条命就挂了。

所以，哪怕她对自己的整体方案再有信心，也不应该先推整体方案。
要以最短的时间，先让研发们体验一个小胜利。
有了这个小胜利，建立了信任，才能推更大的事儿。
那就要推一件最容易的、能快速取得成功的事儿。

第二，
找到了事儿，怎么推下来呢？
一拿方案给研发看，
研发还是会说“做过，没效果”，咋办呢？

找到过去的文档，或者找到当时参与方案的研发。
问清楚上次具体是咋做的。
把上次具体的方案和这次的方案比较一下，很容易发现某些假设上有不一样。

就要找准这个点。
告诉研发到底哪里不一样，为什么前一次没效果、我们却相信这次会有效果。
只要耐心，总能说通。

第三，
最关键的是，做业务嘛，总有不确定性。
万一自己有没考虑到的部分，最终方案效果不理想，最后一条命还是会挂。
怎么办呢？
她额外花了时间，提前想清楚了什么是最大的风险——
当时，
她设计的动作，是个产品功能上的改进。
产品改进，最怕的就是一部分用户喜欢、一部分用户不喜欢。
结果，不喜欢的用户产生的负面影响大于正面影响。
效果不好。

既然知道最大的风险是啥，就好说了。
那就索性在方案测试时，把用户分组做到特别细。
能多细就多细。
只要够细，哪怕整体效果不理想，也总会有几组用户效果好。

最后，还真是命中了她的猜测。
项目整体效果不理想，但是在部分用户身上效果显著。
那就直接做了个策略，只对这部分用户生效。

她一步步建立了团队对自己的信任，才有了落地整体方案的机会。

4、
我也见过不少被派到连续挫败的团队里、渴望力挽狂澜的人。

她与其他人的差别，
其实就是会看清楚局面——不仅仅看事儿，也看人、看团队的状态。
基于对局面的整体了解，再看到底怎么做，才是真正的最优策略。

对比之下，很多人只看事儿。
上来就想做个大的，一次性解决问题，或者对风险估计不足，结果失去了宝贵的信任。
也就不会再有改变局面的机会。

其实，常常“人”和“状态”，才是改变局面时最关键的重点。