问题解决不了？重新定义问题，突破思维格局
很多朋友反馈说，除了多读书之外，不清楚还有哪些方式提升认知水平。
今天给大家介绍一个突破思维格局的方法，提升我们解决问题的水平，核心总结在最后部分。
先来看个段子
美国的洋葱新闻（就是用于娱乐和讽刺的新闻）播报了一条消息：因为百分之八十七的美国人都超重，产生的各种社会问题很多，所以美国政府使用一种方法瞬间大幅减少了胖子的数量。
这个方法就是重新定义胖子的标准，即将标准从体脂率55%提升到90%，大量“胖子”变为“身材苗条”的强壮一族。哈哈。
重新定义胖子的标准
虽然这是一个段子，但是里面蕴含了一种全新的解决问题的方法：重新定义问题。
在现实生活中，“重新定义问题”能够有效突破问题本身的困境和局限性，实现思维格局和认知水平的提升。
再来看个真实案例
2010年左右，我们产品收到俄罗斯一个客户的反馈，说我们的产品文档内容太少了，不符合他们的要求。
这是我在华为工作中遇到的极其少见的反馈，因为绝大多数客户都会说产品文档太厚、内容太多，这次居然有人说内容太少，这是什么情况？
我们让当地的维护工程师与客户沟通，了解情况，收集回来的信息还是“文档内容太少，尤其是《日志参考》这个文档”。
于是我们重点优化了《日志参考》，将每一个日志的每一个字段都做了详细的解释，这本手册从50多页一下子膨胀到190多页。
将《日志参考》发给客户后，客户反馈的结果居然是：“内容还是太少，不好用。”
我们所有人都陷入了沉思，团队进行了几次头脑风暴，都没有找到对策。这个时候一个同事突然提出来：“我们为什么老是盯着《日志参考》，客户的问题是内容太少，我们重新定义他的问题。既然《日志参考》的内容已经到了最详细的程度了，他依然觉得内容太少，那么他的问题就不应该是《日志参考》的问题，而是其他问题，例如维护问题，会不会是他遇到了问题在《日志参考》中没有找到解决方法，所以觉得内容太少。”
大家一下子被打开了思路，觉得很可能是这个问题。于是联系当地的维护工程师去和客户交流，了解他最近的困难和问题。
当地的维护工程师交流后反馈说：“客户在导入数据时总是有一些数据导不进去，他通过业务日志定位问题，一直没有找到方法，所以认为《日志参考》内容不全。”
根据这个反馈，我们重新优化了《维护指南》这本手册，对里面数据导入、切换等操作的过程进行了详细描述，并增加了一些异常问题的处理方法和案例。
很快，在《维护指南》和当地维护工程师的帮助下，这个客户的问题得到了解决。
后来，根据俄罗斯客户的这个问题，我们又收集了更多类似的案例，进一步丰富了《维护指南》，提供给公司的服务热线。因为客户有问题都是最先求助服务热线，如果服务热线解决不了才会转到研发内部。
服务热线对我们的这本《维护指南》非常满意，因为这本手册有效提升了他们的客户满意度，最终实现了三赢：客户满意，服务热线人员的绩效提升，研发部门节约了时间。
在这个真实案例中，客户反馈过来的“日志不全”这个问题其实是一个“伪问题”，不是他真正遇到的困境所在（即“数据导入失败”），这个时候如果只是一厢情愿地提升《日志参考》的详细程度，很大程度上解决不了他的问题。
只有跳出客户的问题描述范围，重新定义客户的问题，才能发现他的真实困境，从而有针对性地解决问题。
问题本身错了，方向就错了
我们应该怎么做
我们从小到大一直学到的思路和习惯都是“针对问题，找到解决方法，做个高绩效的人才”。
所以我们非常善于针对某个问题进行分解重组，抽丝剥茧地找到解决方法。
这个思路的前提就是“这些问题都是对的问题，不是伪问题”。一旦遇到那些伪问题，无论我们再怎么努力，都是南辕北辙，付出越多，效果越差。
现实中，如果一旦问题受阻，总是无法解决掉，那么很可能是“问题本身就有问题”，这个时候需要重新定义问题，跳出原来的思考圈子，这个时候我们最重要的思考步骤就是反思：“为什么会出现这个问题？”
这是一个飞跃式的思维突破，代表着我们向前深入了一步，并且一旦开始了这个过程就无法停下来，直到发现了真实的问题所在。
深入一步，发现问题背后的真相
很多人都说：“这不就是5W2H方法吗，多问几个为什么呗。”
是的，关键问题是，我们遇到问题时很容易陷入到“解决这个问题”的焦虑中，而很少会去思考“为什么会出现这个问题”，很少试图去发现问题背后的真相，很少从更高层级思考问题本身的问题。
一句话总结
跳出思维的束缚，重新定位出真正的问题并一劳永逸地解决掉，这是卓越者的基本素质。
问题不可怕，可怕的是问题本身就有问题。
问题不可怕，可怕的是用有问题的方法对待问题。
（请关注、点赞啊，华为20年的镭师兄提供最实战的职场思路，不断强化你的优势。）