一、理解问题
- 问题的输入、输出、边界、约束、具体难点是什么
- 很多问题都有假设作为前提,弄清楚这个假设,因为这个假设并不一定总是成立的
- 大多数情况下都要弄清楚这个问题更大的背景是什么,即为什么要解决这个问题。很多时候问题本身不一定成立
- 如果问题是其他人提出的,和提出该问题或者了解该问题的人对齐认知:讲出自己对问题的理解,让对方确认或者纠正(这一过程肯能有多轮)
- 理解问题时,要更多的利用事实(客观发生的)和数据,而不是主观,包括
- 先入为主的概念:标签、经验、偏见等
- 别人同步的信息:其他人同步的信息常常是不完整或者有错误的,可能来自于有意(自己的目的)或者无意(本身就不了解、认知错误、偏见等),必须要注意甄别
- 基于事实和数据的推导结论:有时会觉得靠谱但会造成难以察觉的误区
关于理解问题,20250225 新补充 [1]:
XY 问题是一种常见的沟通问题,当有人寻求帮助时,他们关注的是自己的“尝试性解决方案(X)”,而不是“根本问题本身(Y)
“如果我有一个小时来解决一个问题,我会花 55 分钟思考这个问题,5 分钟思考解决方案。” ― 爱因斯坦
二、广泛的信息收集
以下方案不分先后,并行使用
- 询问的方式
- 这个问题之前的处理人解决思路是什么
- 一些 “老人”(这里有一个更深的概念,就是软件乃至技术公司,很多时候是基于员工的内在知识维持的,这种知识常常不是以书面的形式呈现,也很难系统记录)
- 和人交流时的技巧
- 注意提供自己的意图(真的或假的),可以打消对方的顾虑
- 注意使用合理提问的方式,挖掘潜在信息
- 如果可以,找到自己在做的事情和对方的利益共同点,但我发现常常很难找到
- 内部资料,wiki、邮件等(公司内部的知识积累与检索真的非常重要)
- 网络搜索(google、ai)处理该问题或者类似问题的思路是什么
- 搜索很考验关键词的检索技巧
- 中英文都要尝试搜索,最好使用多种搜索引擎
- ai 很考验如何提问题(prompt)
- 找到该问题领域的专家,询问意见和思路
三、常见的解决问题的思路
问题拆解
- 横向拆解
1.1 一般如果可以横向拆解的问题,都可以通过加人或者加资源的方式解决,要注意拆解后的每个问题如何提升处理效率,以达到高效和节省。
1.2 有时可以按照功能模块(职责)拆解问题
1.3 有时可以按照时间或者空间维度拆解 - 纵向拆解
2.1 按流程拆解为一系列步骤,哪些步骤没有问题,哪些步骤有问题;哪些问题是核心问题,哪些问题无关轻重。
2.2 按照因果链拆解
拓扑关系梳理
复杂系统或关系都有哪些组件(或者团体、部门),这些部分是正向关系还是负向关系
分析该如何通过改造网络拓扑结构,达到解决问题的目的。
类比推理
借鉴相同或不同领域类似问题的解决思路
模型简化
一种思路是提取最核心的流程(或者矛盾、结构等),不去分析次要内容
另一种是缩小问题规模,或输入,找到小规模问题的解决方案,再逐步升级难度,思考方案
直接让 AI 提供解决思路
现在 AI 都已经很强大了,可以提供很多问题的解决思路
但是要注意提供好充足的信息,并且需要认真多次迭代提问方式
解决问题时其他需要注意的点
- 畅所欲言:鼓励大家提出问题并分享想法。一个能够开诚布公交流的团队往往能共同找到最佳解决方案 [1]
- 注意尽可能地说清楚解决方案的逻辑,在说逻辑的时候课题提前甄别无逻辑的思路。这种思路的特征是推理链的跳跃,或者推理的基础不可靠等。
一种例外情况是由于客观原因(例如:信息不足、约束过多)难以得到逻辑上清晰的方案,这时也可以尝试实施一些模糊的方案,但是一定要注意实施的成本(投入、是否可逆、最坏情况等)。这一条不是因为懒惰减少思考的接口,勿滥用
四、方案验证与评估
对于需要验证的解决方案
评估验证实施成本,最好可以先小成本验证,再扩大验证范围
对于需要多次反复验证的方案,尽可能地降低每次验证的时间和资源消耗,将大大提升验证效率
必须要提出方案实施后的评估手段
评估时,一方面是与问题直接相关的数据、指标、现象
另外还要从更高层级关注系统或者组织的其他核心数据、指标、现象,避免 “按下葫芦浮起瓢”
根据实施结果迭代方案
一句话:形成闭环
[1] 20250225 补充新的参考资料:https://newsletter.rafapaez.com/p/stop-solving-the-wrong-problem