解决问题，先把问题弄明白

看到“老哥聊技术”关于解决问题能力的分享，其中三个动作很值得展开：识别问题、组织资源、根据反馈调整。它提醒我，知识储备能帮助我们判断，但面对陌生情况时，还要把这些知识变成推动事情的具体行动。

遇到问题，人很容易急着给方案。团队交付慢，就加人、加班、上工具；产品转化低，就改页面、发优惠、加投放。看起来反应很快，却可能一直没有碰到真正的障碍。

解决问题，往往要先放慢半步，把问题说清楚。

先把现象变成一个可以检查的问题

“团队效率低”是一种感受，还不是足够明确的问题。

假设一个项目反复延期，先要看清楚：哪些任务晚了？卡在开发、评审，还是等待决策？原本预期多久完成，实际用了多久？是每个人都慢，还是某个环节让其他人一直等？

原因可能是能力不匹配，也可能是需求频繁变化、任务依赖不清，或者负责人迟迟无法拍板。这些情况看上去都叫“效率低”，需要的解决方式却不同。

这一步要把已经发生的事实、希望达到的结果，以及对原因的猜测分开。先知道自己究竟要改变什么，后面的投入才有方向。

问题清楚一些之后，也不必马上推倒重来。

先看看手里已经有什么：谁了解这个业务？哪些数据能帮助判断？有没有可复用的流程和经验？时间、预算和人手允许做到哪一步？还有什么信息值得向一线同事或用户确认？

仍以交付延期为例。如果主要耗时在等待确认，增加开发人手未必有效；让关键决策提前、明确谁来拍板，可能更值得先试。

跨领域经验也能提供线索。软件开发中的任务依赖，可以借鉴生产排程的思路；客服反复收到的问题，也可能暴露产品流程的缺口。但借鉴之后仍要核对条件，不能因为表面相似，就把旧答案直接搬过来。

组织资源，是判断当前最缺什么，再把有限的精力用到那里。

分析不能代替行动，行动也需要有边界。

如果怀疑延期与需求反复有关，可以选一个小任务，先确认验收标准，约定变更处理方式，再观察一轮。提前想好看什么：返工是否减少，等待时间是否缩短，交付质量有没有下降？

结果改善，说明这个方向值得继续验证；没有改善，就要回头检查假设，看看是否遗漏了其他原因。出现新的代价，也要考虑调整或停止。

所谓边做边调，是让每一次尝试都带回一点有用的信息，帮助下一次判断。

真正棘手的问题，通常不会在第一次讨论时就露出全貌。我们需要逐渐明确目标，识别约束，找到可以借力的人和方法，再通过行动缩小不确定性。

这三步也不是走完就结束的流程。执行中的新发现，可能要求我们重新定义问题、重新安排资源。专业知识和现场证据，始终需要跟上。

下一次遇到难题，可以先问自己：我现在看到的是事实，还是猜测？眼下最值得验证的判断是什么？能不能用一个代价较小的动作，让事情更清楚一点？

问题还没弄明白时，急着找一个漂亮答案，往往比暂时没有答案更耽误事。

本文受“老哥聊技术”《什么才是真正的“解决问题的能力”？》的分享启发，重新梳理并延伸；文中团队交付场景为解释方法的假设案例。