认识问题和求解问题的一种思考框架
认识问题很关键。
引子问题
客满提了一个订单查询工单。商家按照指定条件查询不到订单。经排查，是因为历史的某个线上问题导致订单状态不正确。通过工具修复了该订单的状态，结束这个工单。
周会上，技术支持同学提到，这种工单的数量时不时冒出一两个，有没有办法避免类似工单重新提出 ？ TL 听了，问到：这种历史问题订单，有办法一次性彻底解决干净么 ？
问题是什么
日常工作和生活中，会遇到、面临、分析和解决很多问题。可问题究竟是什么 ？
先来看看，问题的常见种类：
- 诊断型： 今天很乏力，咋回事呢 ？昨天没睡好？工作投入精力透支 ？生病了 ？如果是生病了，那么究竟是身体的什么部位犯病了 ？ 急性还是慢性 ？ 严不严重 ？
- 原因型：如果是某个部位犯病了，为什么会出问题呢 ？ 是哪些因素导致了这个部位犯病 ？为什么这些因素会导致这个部位犯病呢 ？ 其中的机理和规律是怎样的 ？
- 目标型：如果诊断到是某个部位犯病了，那么我期望最终达到什么目标呢 ？ 完全痊愈，还是能够正常生活自理 ？
- 方案型：如果要痊愈，该怎么治疗呢 ？ 预算是多少，在这个预算下的治疗方案是怎样的 ？
- 观点型：各国防控疫情的措施优劣如何 ？对各国防控疫情措施是怎么看的呢 ？ 为什么会这样认为 ？
问题是什么 ？如何准确地描述一个问题 ？ 在 《你的灯还亮着吗》中谈到：问题就是现实状态与期望状态之间的差距。
我期望时时都精力充沛，可吃饭后头脑就乏力；我期望身体健康，可偶尔也会犯病；我期望能准确找到犯病的部位，可现在似乎扑朔迷离； 我期望知道治疗的方案和可行性，可现在一片空白。如果有一个模板的话，就是 “我期望……可目前……”
问题通常可以归结为： who-what-why-where-how 模式。
- who : 关注。 谁关心这个问题的解决，受益人是谁，干系人有哪些；
- what ：描述。指明期望状态与现实状态；
- why ： 规律。揭示构成要素、事物和系统的运行机制和规律；
- where ：目标。完美、令人满意、基本满意、最小可用 ？
- how ：方案。有哪些方案，可行性和成本如何 ，达成效果如何 。
问题的源头
问题从何而生 ？前面谈到，问题就是现实状态与期望状态之间的差距，而期望状态则是从需要中产生。在受限环境中，需要产生需求。问题源自需求。关于需求，广为人知的就是马斯洛的需求理论：
- 生理需要：维持自身生存的最基本要求，包括食、衣、住、行的方面的要求。生存往往是最强大的驱动力源头之一。
- 安全需要。保障自身安全、摆脱事业和财产威胁等方面的需要。在基本满足生理需要之后，为了在文明社会的群居生活中立足，人需要安全。
- 感情需要。在群居生活中的融洽关系和归属的需要。
- 尊重的需要。被认可、接纳、人格尊严。
- 自我实现的需要。实现个人理想、抱负，发挥个人的能力到最大程度。
分析这个历史问题订单的问题，可以归类于第二类需求：财产安全需求。商家需要根据订单状态发货，或者做一些财务分析。而状态不正确的订单，有可能导致不能及时发货引起投诉，可能导致财务对账不合理，引发困惑，最终可能导致的是财产分配不正确。
值得注意的是，问题也可能是解决方案引发的。比如，开发工具去修复历史问题订单，但工具没有做限速，瞬时大批量更新引发消息堆积从而引发线上问题，导致更多要修复的问题数据；或者工具没有考虑周全，把一些正确的数据修复错误了，这些错误的数据又会连锁导致一些问题，需要修复被修复错误的数据以及连锁导致的问题。不完善的解决方案会制造更多的问题，引发一个更长的问题链条。
日常生活的节奏： 需要 -> 问题 -> 求解 -> 方案 -> 事情 -> 新需要 -> 新问题 -> 求解 -> 方案 -> 事情 -> 新需要 -> ……
问题的求解
问题的求解，即是探求事情的 how 。 要得到 how 的答案，先弄清楚 who, what, why, where 极为重要。
- who : 弄清楚关注者的立场，往往影响着解决方向；
- what : 提出一个好问题，就是解决了一半；
- why : 理解了问题的根因，问题求解的途径就清晰了很多；
- where : 确定最终要达成的期望，提供了有益的方向，适可而止。
who
人是问题的中心。人是问题的提出者、关注者，通常也是问题解决的受益者。因此，求解问题，人是一个关键要素。技术人员解决问题的一个毛病，就是容易忽视人。忽视人的解决方案，往往是费力不讨好。
问题来自哪里 ？ 哪些人关注问题的解决 ？ 哪些人尤其关注这个事情的解决 ？ 谁将从中受益 ？ 每个干系方能从中获得什么 ，谁占主导 ？ 这些往往影响着解决问题的方向。
比如说，一个线上工单，虽然是客满提供的，但使用软件的客户才是真正的受益者。客满和 TL 是关注者，而客户是受益者。客满关注的是这个问题是否及时被解决，服务的满意程度；TL 关注的是线上工单的处理效率，团队管理的效率衡量；客户关注的是这个问题本身能否被解决。必须能解答客户的问题才行。这里展示了一种情形： 问题的直接提出者不一定是问题的受益者。因为存在转达者的角色。要真正解决问题，需要借助转达者，直达问题的真正关注者和受益者。问题最终是否解决，也必须经由受益者确认。
who 也可以成为问题求解的关键要素。 谁应该来解决这个问题 ？ 问题的提出者 ？ 关注者 ？ 受益人 ？ 在求解问题时，先弄清楚 who 是非常有必要的。
在求解问题时，还需要避免一些“陷阱”。在《你的灯还亮着吗》第五部分中，提到了两种情形：
- 问题的提出者，并不真正关心问题的解决，—— 只是提出而已。花了三个月开发程序，由于可能至多多出一美分，拒绝程序解决方案，仍然回到原来的套路。新方案总有不足的地方，如果真正想解决方案，只要略加优化即可，而不是直接抛弃。
- 提出的问题，仅仅是些无关紧要的问题，解决了也不会产生多少价值，徒耗时间。花费大量精力破解密码，结果破解的都是些琐碎的支出账目。
要谨防这两种情况，避免解决问题的热情放错了地方。在不希求问题解决的地方，问题的解决本身就成了问题。去做点其他事情是个好的选择。
what
what 涉及到看问题的视角。对于同一个事物，不同的视角，不同的问法，往往会走到不同的求解路径。
比如，排查一个订单查询的工单，发现索引里的订单数据有问题。然而， 索引的数据问题，往往并不是单例，而是批量的一个缩影。
怎么才能批量修复索引里的非正确数据呢 ？ 且慢 ，—— 这是一种解决方案的问法，当然有其意义。不过，回到问题的源头，原初问题应该是： 如何避免出现因为历史问题订单导致的订单查询工单呢 ？
-
方案一：全量地批量检测和修复历史问题订单。这或许可以彻底解决历史问题订单，但代价很大，因为几亿的历史订单里，可能有几百单有问题。并且，新的问题订单还可能诞生，历史问题订单无法根绝。问题：如何找到一个有效的方案，能够海量地捞取数据、检测并更新 ？
-
方案二：根据工单中的订单问题特征批量检测和修复数据。这不一定能彻底解决所有历史问题订单，但能够以较小的代价解决可能存在的历史问题订单。因为它抓住了问题订单的一个特征：问题订单往往是一个时段的系统BUG 导致的聚集性现象。它还抓住了另一个点：要消灭的不是问题数据，而是工单。问题：如何定位具有问题特征的所有订单 ？类似的问题特征有哪些？ 如何定位具有类似问题特征的所有订单 ？如何修复找到的这些订单 ？
-
方案三：谁提出这个工单，把这个人教训一顿或者联络好感情，令其不再提类似工单。问题：怎么找到问题提出者？ 如何教训一顿使之以后敢怒不敢言 ？ 或者如何与之联络好感情 ？
当然，明眼人能看出，方案二和方案三都有点取巧，不一定能根治问题。不过，解决方案本身要考虑可行性，即时间、质量和成本因素。方案一虽然更彻底些，但在当前技术能力下，时间和成本都偏大，并不一定是最佳方案；而随着技术的进步，方案一所花的时间和成本会越来越小，而成为最佳方案。因此，最佳方案往往来自在特定背景下对问题的多角度审视及特定背景下的能力支撑。
话说回来，现实世界里，有多少问题被根治了呢 ？有多少人真的期望能根治问题呢 ？根治问题真的能带来最好的结果吗 ？
why
why 揭示问题的构成要素，相关事物的运行机理和规律。弄清楚 why ，往往为 how 指明了方案的可能途径。
why 属于科学的范畴。通过科学和知识，精确地指明事物的功能是如何实现的：涉及的关键要素，关键要素的形式结构，关键要素的动态协作。
比如订单状态不一致，其机理是多表更新的乱序消息同步订单索引，解决方案就是重新触发一次表更新。
where
where 指明了问题的解决方向。
匠心之人往往投入大量时间和精力做到极致美妙，而现实则需要恰恰好。恰恰好包含了对时间、成本和质量的要求。明确确定要做到什么程度，并写到书面合同里，能很大程度上避免不必要的纠纷。
弄清楚 who 和 what ，基本就弄清楚了 where 。
how
how 是在弄清事物机制和规律的基础上，提出的工程可行的方案。方案，包含设备、工具、步骤、检验；可行性，包含时间、质量和成本因素。
大多数情况下，弄懂 why 是知道 how 的必要条件。不过，有时限于时间所迫，会直接去寻求其他已经遇到和解决过相同问题的人的解答。这是一条捷径，不过，也有其弊端：由于未能弄懂 why ，遇到一类问题时，仍然需要去寻求解答，甚至不一定能获得解答。因此，走捷径解决问题要事后做点功课，把 why 弄明白。
基本问题模式与策略
复杂问题往往是一系列简单问题的叠加组合。 由于问题需要“具体问题具体分析”，这里先讨论一些基本的问题模式和策略。
-
数量关系型。 比如 1+1 = ？ 就是最典型的数量抽象型问题。这类问题，需要抽象出若干个基本的相互关联的量，这些量满足一定的数量关系，通过数量关系可以求解。再比如，本金为 N ，年利率为 m ， 那么存 P 年能获得利息多少 ？ 有 p 个银行窗口并行办事，每个人平均需要 5-7 分钟处理，前面还有 N 个人在等待，那么现在需要等待多久才能轮到处理 ？
-
统计型。 比如帮我找出最近使用了 F 插件的店铺数量。 特征统计型的问题，通常需要事先埋点，有若干字段的组合能够容易地标识出某个特征或功能的使用。
-
事实型。 比如中华人民共和国成立于什么时间，08北京奥运花了多少钱。事实型的问题，通常具有固定唯一的真相答案（天地知道），不会因为人类喋喋不休的纷争而有任何偏移。
-
知识型。 比如水到多少摄氏度会沸腾。 知识型的问题，通常伴随着人的探索和发明活动，是在人类范畴内的具有相对稳定的事实性的问题。知识会随着人的认识而变化。
-
选择型。 比如今天中午吃什么。选择型的问题，主要基于个人的需求、口味、受限的环境供应，来作出选择。
-
判断型。 比如这个房子是否适合居住。 此类问题，通常需要一些基本常识和敏锐的观察力，判断事物的品质优劣，从而做出合适的决定。
-
诊断型。 比如肚子不舒服，想知道咋回事 。 此类问题，通常需要通过专业知识和经验来判断和定位原因，对症下药。 忌瞎蒙。
-
原理型。比如锻炼身体为什么能减少疾病的产生。十万个为什么。此类问题，需要对事物和系统有深入的认识、探索和研究。
-
人事型。 比如如何取社保买房。此类问题，建立在社会密切分工协作的基础上，往往需要经过一些人事，完成一些程序和手续作为后续凭证，避免不必要的纠纷。
-
组织型。 比如如何筹办一场培训活动。 此类问题，涉及到大量人员的组织，大量事情在指定时间内的安排妥当，具有明显的组织性的特点。组织型的问题，需要事务管理能力，以及对人的关怀与督促。
-
观点型。 比如如何看待各国防控疫情的措施。 此类问题，建立在对相关领域的充分调研的基础上，结合个人的世界观和价值观来作出论述。
复杂问题往往可以拆解为基本问题，再运用一些基本策略来求解。
问题求解的误区
急于求解问题
还没认清问题，急于着手求解问题，是问题求解的一个误区。
这种习惯可能源于应试教育。应对考试，需要在短时间快速思考并找到第一个有价值的线索，并按照这个线索走下去。考试锻炼了人的“急中生智”的应对能力，却容易让人缺乏周全缜密的思考和谋略。不经细思，没弄清楚 who-what-why-where ，就急于求解 how ，往往就容易碰壁、费力不讨好、治标不治本、南辕北辙等。
在现实生活中，需要的不是在短时间做会十几道题，而是聚焦一段时间解决一个重大的问题。这是性质差异很大的问题模式。
问题描述不清
问题描述不清，很容易误导人，耗费大量时间却是一场徒劳。
问题描述不清，常见原因有：
- 关键点掩埋。要提的问题比较多，或者信息过多，掩埋了关键问题。
- 歧义理解差异。词语及表述的歧义导致在不同人的思维语境里理解成了不同的意思。
- 缺乏必要线索。只描述了一个最基本的现象，什么线索都没有提供。
- 传递失真。在问题的传递过程中，最初的信息一步步剥落，变成了一个失真严重的伪问题。
治标不治本
治标不治本往往源自对问题的不够清晰的认识。
- 只解决了眼前看到的问题，没有看到问题产生的根因，这种根因会导致持续产生新的问题单例，要持续不断去解决一个又一个产生的单例；
- 只解决了给定的历史单例，没有意识到存在批量的历史单例，结果要时不时花点时间去处理提出的历史单例；
- 只解决了被转述失真的问题，但实际上问题依然没有解决，问题解决的受益者面临依然如旧的处境。
- 只解决了技术上的问题，没有满足问题的某个关注者的期望。
- 只解决了方案式的问题，没有触达原始的需求。
小结
本文探讨了更为立体的认识问题和求解问题的 “who-what-why-where-how” 框架。要解决问题，认识问题很关键。
最后，人的欲望是无止境的，需求是无止境的，问题也是没完没了的。别指望一晚上能搞定所有事情，放放手，去休息吧 ！
