Appearance
从发现问题到解决问题，中间隔着什么？
一、从两个实际场景说起
在日常软件开发和维护工作中，我经常会发现一些需要改进的地方。
对于部分后端问题，我可以自行分析、修改代码并完成上线。
但涉及产品页面的优化，情况有所不同。
我曾向产品经理提出过一些针对某业务系统的优化建议。该产品经理在口头沟通中认可这些建议，但表示没有时间处理。
这位产品经理仅有部分工作时间投入该系统。
沟通之后，这些优化没有进入排期，也没有明确的后续安排。
这让我产生了一个疑问：
为什么同一个人发现的改进事项，有些能够自行完成，有些却停留在建议阶段？
最直接的差别是，我可以独立处理部分后端问题，却无法独立完成涉及其他岗位的产品优化。
但要解释其中的原因，还需要进一步区分：发现问题、提出方案、具备能力、拥有权限和获得资源，分别意味着什么？
我尝试从五个维度分析：
- 发现问题
- 解决思路
- 解决能力
- 解决权限
- 解决资源
这五个维度不是一套全新的管理理论，也不是保证问题解决的公式，而是我在实际工作中整理的一组分析角度。
它们要回答的核心问题是：
当一个问题没有得到解决时，我们应当如何判断它究竟受阻于哪个环节？
二、解决问题的五个维度
2.1 发现问题：实际状态与预期状态之间存在什么差异？
发现问题，首先需要观察客观事实。
例如，一个接口的响应时间为两秒。
这个数据可以通过日志核实，但仅凭两秒这个事实，还无法判断接口是否存在性能问题。
如果业务要求接口在 500 毫秒内返回，那么实际情况明显偏离预期。
如果业务允许数秒完成，两秒可能属于正常范围。
因此，发现问题至少涉及三个环节：
- 观察事实： 实际发生了什么？
- 明确标准： 预期状态是什么？
- 识别偏差： 实际状态与预期状态之间有什么差异？
据此，可以将发现问题定义为：
基于客观事实，对照目标或标准，识别实际状态与预期状态之间的差异。
这里需要区分现象与原因。
“接口响应缓慢”描述的是现象。
“缺少索引导致查询缓慢”则是对原因的判断，需要进一步验证。
问题也不完全等同于优化机会。
系统返回错误数据，通常属于功能缺陷；而通过调整页面交互、减少操作步骤，则可能属于产品优化。
两者都可能值得处理，但评价其必要性、收益和成本的标准不同。
所以，发现问题的核心任务，是明确究竟发生了什么，而不是立即解释为什么发生。
2.2 解决思路：知道应该怎样改变现状吗？
发现问题之后，需要分析原因，并提出改变现状的方法。
解决思路，是基于问题分析，提出具有逻辑依据、能够接受可行性检验的解决方案或行动路径。
例如，发现数据库查询缓慢之后，可以通过执行计划、索引情况和数据分布分析原因，再提出调整索引或改写 SQL 的方案。
这个阶段关注的是方案本身。
为什么选择这种方案？
它针对什么原因？
可能带来什么收益和代价？
应当如何验证效果？
一个人即使没有亲自实施过某项方案，也可能通过知识、经验和逻辑推理提出合理的解决思路。
但方案合理，并不能直接证明提出者能够完成实施。
这就涉及第三个维度。
2.3 解决能力：能够把方案落实吗？
我认为，解决思路与解决能力的区别尤其值得讨论。
例如，一名开发人员通过阅读资料和分析系统结构，提出将大型遗留系统拆分为多个模块。
他的方案可能在技术上具有合理依据。
但真正实施时，还需要处理模块依赖、事务边界、历史接口兼容、测试和生产发布等实际问题。
提出方案和完成实施，对知识、经验与执行能力的要求并不相同。
因此，可以将解决能力定义为：
具备实施方案所需的知识、技能、经验和判断能力，能够将方案转化为实际行动，并处理实施过程中出现的复杂情况。
这里还有一个问题：解决能力是否等于实际做过？
我的理解是，实战经验是判断能力的重要证据，但不是能力本身。
一个人处理过类似问题，能够提供有价值的经验依据。
但过去完成任务，不意味着在任何环境下都能重复成功。
同样，没有处理过完全相同的问题，也不意味着无法通过已有知识和相关经验完成新的任务。
因此，我们需要分别判断：
- 解决方案是否合理；
- 实施者是否具备相应能力；
- 实际执行是否达到预期效果。
此外，还需要明确能力的评价对象。
复杂问题可能由团队共同完成，不能要求一个人具备所有专业能力。
2.4 解决权限：谁有权推动改变？
即使一个人有解决思路，也具备实施能力，仍然可能无法自主行动。
因为具体行动需要相应的决策权和授权。
解决权限，是指相关主体在特定组织或制度环境中，拥有作出必要决定、批准变更或推动行动的授权范围。
例如，我可以自行修改部分后端代码并完成上线。
但涉及产品页面的优化，需要产品经理参与。我无法自行安排该产品经理的工作。
这里可以引入一个辅助概念：控制边界。
控制边界指的是，一个主体能够自主完成某项工作所需决策和实施的范围。
如果某项工作完全处于个人控制边界内，可以由个人自主推进。
如果需要其他人员作出决定或提供支持，那么问题的解决便超出了个人能够独立控制的范围。
这个概念并不是另一个独立维度，它帮助我们判断：
从哪个环节开始，解决问题需要依赖其他主体的行动？
能力与权限在这里有明确区别。
能力关注能否承担工作。
权限关注能否自主决定或推动工作。
如果真正的障碍来自授权，仅仅提高个人专业能力，未必能够改变局面。
2.5 解决资源：实施条件能否真正获得？
拥有方案、能力和权限之后，还需要实施所需的资源。
资源可以包括时间、人力、资金、信息、工具等。
解决资源，是指实施方案所需的条件，以及这些条件能否被实际获得和投入。
我认为，资源分析中有三个容易混淆的状态。
第一，资源存在。
组织拥有相关人员或工具。
例如，公司有产品经理、开发人员和测试人员。
第二，资源可用。
相关人员在特定时间具备承担新增工作的余量。
第三，资源投入。
相关人员的工作时间或其他资源，已经被安排用于某项具体工作。
三个状态之间存在联系，但不会自动转化。
公司有产品经理，说明产品岗位资源存在。
产品经理是否有空余时间，需要看实际工作安排。
即使具备可用时间，也需要决定将其投入哪些事项。
因此，不能只问组织有没有资源，还需要问：
资源是否可用，以及是否已经投入具体事项？
资源的使用还涉及成本与收益。
一个技术上可行的优化方案，如果投入成本明显高于预期收益，暂缓实施也可能是合理的选择。
所以，资源分析除了确认实施条件，还需要结合方案价值与优先级作出判断。
三、五个维度为什么需要分别考察？
五个维度可以简要整理如下：
| 维度 | 回答的问题 |
|---|---|
| 发现问题 | 哪里出现了偏差？ |
| 解决思路 | 可以怎样改变？ |
| 解决能力 | 能否完成改变？ |
| 解决权限 | 谁有权推动改变？ |
| 解决资源 | 有没有条件实施改变？ |
这里有一个重要的逻辑问题：
既然五个维度相互影响，为什么还要分别讨论？
3.1 相互关联，不意味着概念相同
以解决权限和解决资源为例。
一个负责人可能有权调配人员，但当前所有人员都承担着其他任务，没有足够时间处理新增工作。
这是资源可用性问题。
另一种情况是，某个团队存在可用人员，但提出优化建议的人没有权限安排这些人员。
这是权限问题。
两种情况可能发生在同一个组织里，也可能同时限制同一项工作。
但它们的处理方式不同。
前者可能需要调整资源安排，后者则需要明确谁有权作出决定。
解决思路与解决能力也是如此。
一个人通过实际经验形成更好的解决方案，说明两者相互影响，却不意味着提出方案和实施方案属于同一种能力。
因此，五维分析并不是要求每个问题只能属于其中一类。
它是将不同性质的条件分别识别，再分析它们之间的关系。
3.2 条件可能掌握在不同主体手中
对于复杂问题，发现者、方案提出者、执行者、决策者和资源控制者可能不是同一个人。
例如，开发人员发现某项产品优化机会，产品经理负责业务分析，相关负责人决定是否安排工作，前后端开发人员负责实际实施。
在这种情况下，即使组织整体具备相关条件，也需要将不同主体的行动协调起来。
这说明：
解决问题不仅涉及条件是否存在，还涉及这些条件能否被实际用于某个问题。
但这并不意味着多角色协作必然低效。
跨角色协作增加了需要处理的依赖关系，能否顺利推进，还需要观察具体的决策与执行过程。
3.3 解决意愿与优先级应该放在哪里？
此前我们将解决意愿和优先级视为前置条件。
经过进一步讨论，我认为这需要说得更准确一些。
解决意愿回答的是：相关主体是否希望改变现状？
优先级回答的是：在多个事项之间，为什么先处理这一件？
两者不是同一个概念。
一个人可能认可某项改进，也愿意推动，但由于其他任务更重要，暂时没有投入资源。
因此，优先级并不只发生在解决问题之前。它可能在方案评估、排期和资源分配过程中反复发挥作用。
本文仍然保留原有五维结构，但将意愿、优先级和实施决策作为与五个维度共同考察的因素。
这不是因为它们不重要，而是因为它们主要解释为什么决定做、何时做，五个维度则用于分析识别问题及实施改变需要哪些条件。
这样的区分是一种分析安排，不要求所有问题解决方法都采用相同划分。
四、将五个维度用于真实案例
回到文章开头的两个场景。
一个是我可以自行修改并上线的后端问题。
另一个是涉及产品页面、获得口头认可却没有进入排期的优化建议。
我们可以尝试用五个维度检查这两种情况。
不过，首先需要遵守一个原则：
把事实、根据事实作出的判断，以及尚未确认的信息分开记录。
如果一个事项已经完成，就直接推断所有条件始终具备；如果一个事项没有完成，就直接认定某个人缺乏能力，那么分析很容易变成根据结果寻找解释。
4.1 两个场景的对照
| 维度 | 后端问题 | 产品优化 |
|---|---|---|
| 发现问题 | 我发现了相关后端问题 | 我发现并提出了优化机会 |
| 解决思路 | 已实际修改，具体方案形成过程未在本文展开 | 提出了优化方向，完整方案尚未验证 |
| 解决能力 | 有自行完成修改和上线的实际经历 | 尚未进入实施，整体实施能力无法据此判断 |
| 解决权限 | 能自主修改并上线 | 不能独立安排产品经理的工作 |
| 解决资源 | 具体资源配置未单独调查 | 产品经理表示没有时间处理 |
| 实际状态 | 已修改并上线 | 口头认可，未排期，无明确后续安排 |
这张表的价值，不是让五个维度全部得到确定答案。
相反，它展示了不同事项掌握的信息并不一样。
对于后端问题，我有实际完成修改和上线的经历，能够据此判断自己在这些具体任务中的行动能力和权限范围。
对于产品优化，我们掌握的则主要是问题提出、沟通和当前处理状态的信息。
这些信息还不足以对完整方案、实施能力及最终资源配置作出全面判断。
4.2 同一个人，控制边界发生了什么变化？
在后端案例中，我可以自主决定修改并完成上线。
在产品优化案例中，一旦工作需要产品经理参与，我便无法独立完成后续安排。
这就是两个场景中能够明确识别的控制边界差异。
但需要注意，这种差异只能说明两类事项对外部决策和资源的依赖不同。
它不能单独解释两个事项最终结果的全部差异。
后端修改与产品优化可能具有不同的工作量、收益和优先级。
因此，控制边界在本例中的作用，是识别从哪里开始需要其他主体参与，而不是证明跨部门协作存在问题。
4.3 产品优化目前究竟是什么状态？
根据实际经历，这些优化建议经历了以下过程：
- 发现优化机会。
- 向产品经理进行口头沟通。
- 产品经理认可建议。
- 产品经理表示没有时间。
- 沟通之后，没有进入排期，也没有明确的后续安排。
这里需要说明实际工作流程。
口头沟通属于提出和初步讨论建议的阶段。只有决定排期后，相关事项才会进入书面环节。
所以，不能将没有书面材料直接解释为没有推进的原因。
现在可以明确作出一个判断：
这些建议已经完成初步沟通，但尚未形成明确的实施安排。
这是一种实际存在的处理状态。
它既不同于已安排实施，也不同于明确决定放弃。
而且，口头认可建议，不等于已经完成可行性评估，更不等于作出了投入资源的决定。
因此，我们能够确定事项停留的位置，却不能仅凭目前的信息确定所有原因。
4.4 资源与权限在这里如何发挥作用？
已知产品经理仅有部分工作时间投入该系统，并表示没有时间处理这些优化。
这说明：在当前工作安排下，相关优化没有获得所需的产品工作时间。
与此同时，我并没有自主安排产品经理工作的权限。
这两个因素可能联系紧密，但分别属于资源与权限两个不同角度。
如果某个人有权调整工作安排，但当前没有可用时间，需要处理的是资源配置问题。
如果存在可用时间，但建议提出者没有权力安排，则需要明确决策和授权关系。
在本例中，谁能够最终决定排期、是否有可能调整现有任务，我们还没有足够信息。
因此，五维分析能够定位已知限制，却不能自动提供未经调查的答案。
4.5 如果继续调查，应该了解什么？
如果我们确实需要深入解释这些建议为什么没有进入后续实施，那么可以从以下几个方面继续检查。
首先，方案是否具备进一步评估的基础？
具体改善什么问题？预计收益是什么？需要多少工作量？
这关系到解决思路及方案价值。
其次，谁有权决定实施和排期？
由产品经理自主安排，还是需要其他人员决定优先级？
这涉及解决权限。
再次，为什么没有投入产品工作时间？
是既定工作安排已经占满可用时间，还是其他事项被赋予更高优先级？
这涉及解决资源与优先级。
最后，是否作出过明确的暂缓或不实施决定？
目前已知的是没有明确后续安排。要进一步解释这种状态，需要了解决策过程。
这些调查方向并不意味着必须重新追问产品经理，也不代表我们已经知道问题的最终原因。
它们只是说明：通过五个维度的区分，我们可以将原本笼统的“为什么没做”，转化为几个具体问题。
五、五维分析的实际价值与局限
到这里，五个维度已经不仅是概念上的区别。
它们可以在分析问题时产生两个实际作用。
5.1 不同障碍，对应不同处理方式
假设某个事项长期没有推进。
如果问题没有被准确识别，首先需要补充事实、明确标准。
如果已经发现问题，却没有合理方案，应当继续调查原因、评估解决路径。
如果方案合理，但实施人员缺乏必要能力，可以考虑技术支持、培训或调整执行人员。
如果实施者具备能力，但没有相应权限，需要明确授权和决策关系。
如果能力和权限具备，却无法获得必要资源，需要重新评估工作安排、资源投入或方案成本。
如果上述条件基本具备，事项仍然没有推进，就应该继续检查实施决策、优先级、协作和利益关系。
不同的障碍，要求采取不同的处理方式。
问题分析的意义，不只是找到一个看起来合理的原因，而是避免针对错误原因采取行动。
5.2 评价能力，需要考虑任务与实施条件
一个人完成了某项工作，可以为评价他在该任务中的能力提供证据。
但评价能力还需要结合具体任务和实施条件。
例如，我能够独立完成部分后端修改，不能据此认定自己具备解决所有技术问题的能力。
同样，涉及产品页面的优化没有实施，也不能据此判断我或产品经理缺乏相应的专业能力。
因为该事项尚未进入实施阶段。
因此，结果可以作为评价能力的证据，但不能代替对任务过程和实施条件的分析。
这并不是否定结果评价，而是让评价更有明确的依据。
5.3 五个维度什么时候不够用？
这套框架不属于完整的问题解决理论。
例如，有些问题的主要障碍来自利益冲突。
不同部门都具备能力和资源，却可能因为实施成本、收益归属或工作目标不同，无法形成一致决定。
此时，仅检查五个维度可能不足以解释实际情况。
有些问题涉及复杂的权衡取舍，甚至没有已知的可行解法。
还有些事项虽然具备实施条件，但相关主体经过价值评估，决定暂缓或不实施。
因此，五维分析适合用于识别问题解决的基本条件和可能障碍。
如果调查发现真正原因来自组织激励、利益分配、复杂决策或问题本身的不可解性，就需要进一步分析，而不是强行归入五个维度。
类似的区分也并非全新的理论发现。例如，COM-B 行为模型从能力、机会和动机等方面解释行为是否发生。本文与这类模型在问题意识上存在交集，但研究对象和维度划分不同，并不主张建立了能够替代现有理论的新模型。
本文更接近一份基于实际工作经历形成的逻辑分析方法。
六、结论：先识别障碍，再决定如何行动
现在可以回到文章开头的问题：
为什么同一个人发现的改进事项，有些能够自行完成，有些却停留在建议阶段？
根据已有事实，两个场景存在明确的条件差异。
对于部分后端问题，我能够自主完成修改和上线。
而产品优化需要其他人员参与，已经超出我能够独立控制的范围。相关建议虽然获得口头认可，但没有进入排期，也没有明确的后续安排。
目前能够确认的直接限制，是产品经理表示没有时间投入。
至于为什么没有投入，是工作安排、优先级还是其他决策因素，需要更多事实才能确定。
这个案例没有证明五个维度能够解释所有问题，却展示了区分它们的必要性。
发现问题、提出解决思路、具备解决能力、拥有行动权限，以及获得实施资源，是五个需要分别判断的维度。
它们可能相互影响，也可能由不同主体掌握。
当问题没有解决时，我们首先应该明确：事项停留在哪个阶段，已经具备哪些条件，又缺少哪些条件。
如果问题在方案阶段受阻，处理方向可能是重新分析原因。
如果问题受限于能力，需要解决的是实施能力。
如果障碍来自权限或资源，则需要检查相应的决策与投入条件。
如果事项尚未获得实施决定，那么就应该先研究为什么没有进入实施，而不是直接评价执行能力。
因此，五维分析真正提供的不是一个必然正确的答案，而是一种更有针对性的判断方式：
先区分事实、推断和未知，再识别具体障碍，最后决定下一步应该调查什么、改变什么。
从发现问题到解决问题，中间隔着的不只是个人有没有能力，还包括方案、权限、资源，以及这些条件能否在具体事项中形成实际行动。
只有明确问题究竟受阻于哪里，解决问题的行动才可能真正针对原因，而不是只针对结果。