问题是你想要的和你感知到的之间的差异。 不是你想要的和事物本来面目之间的差异，因为你永远无法直接接触事物的本来面目。你只有你的感知，而你的感知被定义问题的同一个框架所塑造。
说到底，没多少人真的想让自己的问题被解决。
简单的画面
一栋办公楼收到投诉说电梯太慢。工程解决方案：更快的电机、更好的算法、更多电梯。昂贵且实施缓慢。实际的解决方案：在电梯旁装镜子。人们不再投诉，不是因为电梯更快了而是因为他们现在忙着看自己。问题从来不是”电梯慢”。问题是”等待不愉快”。
镜子方案只有在你质疑问题定义时才能看到。每一个工程方案都假设问题是”电梯慢”。工程算法说：在优化电梯之前，先问电梯到底是不是问题。
问题定义陷阱
大多数人被学校训练成抓住第一个看起来像问题的陈述然后尽快解决。考试上速度很重要。这种本能延续到职业生涯中，第一个说得通的问题定义不经审视就被采纳了，所有后续的努力都花在解决一个可能不是真正问题的问题上。
思考的意志命名了认知版本：大多数人在有了一个听起来对的答案时就停下来。问题解决在更上一层有同样的陷阱：大多数人在有了一个听起来对的问题时就停下来。缓存思维不仅仅是解决方案，是问题定义本身。
如果你想不出至少三个你对问题的理解可能有什么错，你就还不理解这个问题。 这是节奏应用于问题解决：对第一个问题定义的过早利用产生的脆弱结果和对任何心智模型的过早利用一样。探索阶段，在问题是什么的模糊中停留，必须先于解决它的利用阶段。
问题转移
工程师认出了自己的安全问题但没看到它可能是别人的问题。这就是问题转移，通过把问题挪到系统的另一部分来解决它，在那里它对”解决”了它的人变得不可见。
系统圣经从结构上框定了这个：系统诞生的瞬间就发展出自己的目标，一个系统的解决方案是另一个系统的问题。约束理论加上了具体性：改善非约束处把注意力和资源从真正的瓶颈转移开，让系统变糟的同时局部指标改善。
如果你是今天解决方案的一部分，你就是明天问题的一部分。
这翻转了通常的框架。解决了一个问题的人创造了一个新的系统配置，最终会产生它自己的病理。当前方案的局部最优变成下一次改进的障碍，而建造当前方案的人最不可能质疑它，因为他们的身份被投入其中。
为什么人们抵制解决方案
书中最深的洞见：人们往往对自己的问题比对任何可能的解决方案更执着。一个问题一旦被接受，就提供了结构，它解释了为什么日子不好过，为当前行为提供正当性，给受苦者一个叙事身份。解决问题会让这一切都溶解。
这直接映射到心理层面的局部最优。功能障碍不是bug，它在服务一个目的。那个抱怨工作但从不离开的人从抱怨中得到了什么。那个辨认出流程问题但从不修复的团队从拥有这个问题中得到了什么。IFS说每个部分都服务一个功能；温伯格说每个未解决的问题也服务一个功能。聚焦问题是最纯粹的版本：总有什么是错的，如果你解决了，下一个已经在等着了——因为问题的功能不是被解决，而是在什么都没错时遮挡那种无着落感。
别人能自己完美解决的问题，别替他们解决。 这是边界表述为问题解决原则，阿德勒形式化的同一种课题分离。这是谁的问题？如果他们能解决，替他们解决剥夺了他们的成长也剥夺了你本可以更好利用的时间。
推论：如果一个人有能力对一个问题采取行动但他没有这个问题，那就做点什么让他有。 这是反馈管道在行动，让问题对有权力修复它的人可见，而不是自己吸收它。
文字游戏与重构
文字游戏通常比不想要的解决方案便宜。
在投入资源解决问题之前，玩弄定义。重构它。测试问题是否在被不同地描述后还存活。如果不，如果改变措辞就消解了问题，那问题在框架中，不在现实中。
人们很少知道自己想要什么直到你给了他们要求的东西。 米洛准则在此基础上构建：用户声称的需求永远是错的，发现真正需求的唯一方式是给他们某样东西然后看他们实际上怎么用。不存在最终的问题定义，只有越来越接近”想要的”和”感知到的”之间真实落差的逐次近似。
低/中/高水平理解
低水平理解：“别想那么多直接解决就行了。”
中等水平理解：“我们需要更好的需求收集和利益相关者对齐才能开始做方案。”
更好的理解：问题定义是任何项目中最有价值也最危险的产物，比错误的解决方案更危险，因为对正确问题的错误答案可以迭代，而对错误问题的正确答案是方向性的永久浪费。 快速解决的本能是敌人。质疑问题的纪律，在承诺之前先坐在三种可能的误解中，是工程、治疗和生活中杠杆率最高的技能。大部分看起来像问题解决的东西实际上是问题回避：解决一个方便的问题来逃避面对真正的那个。
核心收获
我们从来没有足够的时间把它做对，但我们总有足够的时间重做。
这是糟糕问题定义的沉没成本动力学。急着解决错误问题的组织花的总时间比前期投资于定义正确的组织更多。批量生产出抓住第一个问题陈述快速解决的人的学校系统，生产的是将用整个职业生涯重做事情的人，出色地、高效地、朝着错误的方向。McGraw结晶了它：“没有规格，系统不会出错，它只会令人惊讶。” 构建程序的大部分本质是在调试规格，不是代码。
参考：
- Donald C. Gause and Gerald M. Weinberg, Are Your Lights On? How to Figure Out What the Problem Really Is