找出真正的约束
收录 2026-11-03
限制通常只有一两个，其余都是借口。
我觉得一件事做不成（情况稍后给你）。请帮我找真正的约束：1）列出所有被提到的限制（时间、预算、人、规则、技术）；2）逐个判断「如果解决它，事情真的能推进吗」；3）找出那个一旦解决其他限制都可绕开的约束；4）指出哪些限制其实是我自己假设的；5）给一个验证约束的方法（一周内可完成）。
本站原创
中文原文
使用建议
找到真约束，方案会突然变简单。
可以这样改
- 要求它列出「什么证据会推翻这个判断」。
- 让它分别扮演支持方与反对方各说三条理由。
交付物（这次应拿到什么）
- 决策要点表：假设 / 证据 / 反证
- 明确的下一步动作与观察指标
常见错法
- 只问「我该不该做」，得到两边都对的废话。
- 没让它给反例，于是只听到支持自己的理由。
输出验收（怎么判断能用）
- 列出了什么证据会推翻当前判断。
- 正反理由都有，且标出哪些是假设。
适用场景与注意
- 适合：把决策拆成假设、证据、反面情形，再让你自己拍板。
- 注意：要求它给出“什么证据会推翻这个判断”，否则容易只听到支持你的理由。
适合什么场景
- 项目反复延期，团队列出很多「做不到的理由」，但没人确认哪个是真约束。
- 准备申请资源或改方案前，想先分清「真的被卡住」和「只是习惯性这么说」。
不适合的场景
- 已经明确知道卡点（例如审批流程）并且正在解决——再分析约束只是拖延。
- 约束明显是硬性的（法律禁止、物理限制）——重点应放在绕开或接受，而不是重新定义。
示例
输入
上线一直拖延。团队说：时间不够、测试人手不足、需求总在变、服务器申请流程慢、设计稿没定稿。
你会得到
先逐个做「如果解决它，事情真的能推进吗」：测试人手与设计稿可能只是次生问题；服务器流程是固定时长、可提前申请；需求变化是关键——如果需求仍在变，前四项解决也上不了线。于是真约束是「需求未冻结」，其余是它的后果。验证方法：把本周需求变更次数记下来，若为零仍延期，则约束判断错了。
常见误用
- 把「最常被提到的限制」当成真约束：提到次数多不等于因果强。
- 不验证就改方案：绕过一个假约束，真约束仍在，白花一轮时间。
可以这样改
- 按「可改变性」排序：先处理能改的，再看剩下的硬约束是否可绕。
- 换成「如果只允许解决一个限制」：强制找出单点约束，输出更接近真实瓶颈。