问题框架怎么搭：先把问题问对，再谈解决方案

摘要

问题框架，是我们决定“这到底是什么问题”的方式。很多解决方案失败，不是因为执行不够努力，而是因为一开始就把症状当成问题，把立场当成问题，或者把太大的困境压缩成一个看似简单的选择。搭好问题框架，意味着先看清对象、边界、原因、约束和判断标准，再谈方案。

为什么问题框架比答案更早

一个问题被说出口时，往往已经带着方向。

“怎样让用户多点按钮”和“为什么用户没有继续完成任务”，听起来都在讨论转化率，但前者默认按钮是关键，后者还保留了重新理解场景的空间。问题框架不同，后面会收集不同信息，也会排除不同可能性。

所以，解决问题前最该警惕的不是“我有没有答案”，而是“这个问题是不是已经把答案偷偷塞进去了”。

不要把症状当成问题

症状是表面可见的异常，问题是导致异常反复出现的结构。

团队会议很低效，这是症状。真正的问题可能是议题没有负责人，决策权不清，信息提前准备不足，或者大家把同步会当成汇报会。只盯着症状，就会得到“缩短会议”“少开会”这样的表层方案；它们有时有用，但不一定触及原因。

判断一个描述是不是问题，可以问一句：如果这个现象消失了，背后的冲突还会不会以别的形式出现？如果会，它可能只是症状。

不要把立场当成问题

很多争论卡住，是因为双方讨论的不是同一个问题，而是在维护各自立场。

比如“要不要做这个功能”，表面是功能取舍，实际可能包含三层问题：这个用户需求是否真实？这个需求和产品定位是否一致？当前团队有没有能力维护后续复杂度？

如果只停留在“做”或“不做”，争论会变成输赢。把立场拆回问题，才可能讨论证据、成本和判断标准。

给问题加边界

太大的问题会让人无从下手。比如“怎样提升产品体验”，这个问题几乎没有边界。更好的问法是：在哪个用户阶段、哪类任务、哪种失败体验、什么时间范围内提升？

边界不是缩小野心，而是让行动变得可检验。

一个可工作的框架至少包含四件事：

• 对象：我们讨论的是谁、什么场景、哪个环节。
• 现象：现在发生了什么，和期望有什么差距。
• 原因假设：可能是什么机制导致了差距。
• 判断标准：怎样算这个问题被改善了。

把问题从“谁错了”改成“什么机制在起作用”

糟糕的问题框架很容易把复杂情况变成人的道德判断。

“为什么大家不主动”往往比“什么机制让主动变得没有收益”更难推进。前者把问题压到个人身上，后者会逼我们看激励、反馈、权限、风险和协作方式。

这不是替人找借口，而是让问题进入可改变的层面。

好问题会改变可见范围

真正好的问题框架，往往让原本看不见的东西浮现出来。

当你问“为什么用户不喜欢这个功能”，你看到的是态度；当你问“用户在什么任务里会觉得这个功能值得学习”，你看到的是场景；当你问“这个功能增加的复杂度由谁承担”，你看到的是长期成本。

问题不是越抽象越高级，也不是越具体越好。好的问题能把注意力放在最能解释现实的位置。

结论

问题框架的价值，不是让我们显得更会分析，而是减少错误努力。

很多时候，我们不是缺少答案，而是太快接受了第一个问题。先把问题问对，意味着愿意慢一点：区分症状和原因，拆开立场和事实，给对象加边界，明确判断标准。这样得到的方案未必完美，但更可能对准真正需要改变的地方。