自从读了《创新算法》这本书，里面的思维模型对日常工作和思考非常有用。这周和同事出现了沟通障碍，一分析就立刻发现了其实是犯了「思维惯性」的问题。要清楚地描述事情本身，而不是描述这个过程要如何，也不是描述目前的问题困扰是什么，因为这个问题很可能不是实际真正的问题，而是在过程产生的其他问题。
分析客户需求问题的沟通案例：
一个客户需要我们 AI 图片识别的测试结果，商务同事在邮件里说：
- 客户只要一个xx识别结果的数据，不需要我们来核验是否正确了。
- 并且客户需要用 excel 里的 号码 来匹配图片的识别结果。
而实际上，要交付给客户的东西，PM 需要自己去衡量，而不是商务要我们做什么（或者客户说他要什么），我们就做或者不做什么。首先定义清楚问题是什么，然后如何提供给客户需要的东西，并且对最终的结果，产品经理需要对产品有一定的理解和掌握。比如我们要交付给客户的是什么呢？==> 上面邮件说的是他的目的还是手段？
最终，这个 case 应该如何解决？
- 产品的最终目标：满足客户真实需求和预期，让商务签单，后续合作
- 客户的真实需求：图片识别准确率，验证我们的算法是否可靠
- 我们能给客户提供的内容：
- 目前已经统计出的识别准确率是多少？
- 重新计算识别的准确率：需要检查测试数据的图片质量；并且做标注，算法评测。
- 如果测试图片的数量很多，是否可以抽样做？
- 引导客户提供什么样的图片做测试数据
- 给客户提供一些避免错误的案例清单
- 进一步走下面的流程，直到提供对方要的数据结果。而不是让客户自己以为的方式去做测试。客户提出的方案很可能是对问题错误的描述。
在《创新算法》中提到，惯性思维总是误导我们用错误的方式描述问题。
创新过程的每一个阶段都避免在问题描述上犯错，这一点非常重要。发明家绝对不能接受别人编排好的问题陈述，任何正确陈述的问题可能早已被解决。不正确的描述可能导致陷于迷宫的死角。
- 问题陈述包括两部分：目的和手段，目的很容易正确地陈述，但是同样的目的可以通过不同方法实现。发明家在陈述问题可能存在两种可能：一是正确陈述了问题，二是在执行方法进行到一半发现障碍的时，将问题本身变成了陈述方案的障碍，这就导致进入障碍陷阱。
- 检验问题是否描述正确的方法是：对照其他行业相同问题的陈述，尤其是哪些问题陈述的比较准确，或者操作规模更大的行业。
包括给开发提产品需求的时候，我也是下意识的思考了解决方法，而不是思考问题本身。
不能撤回好痛苦，貌似可以增加一个点击图片后，确认发送按钮，而不是直接发送
应该：描述事实是什么，理想解是什么，而不是描述具体方法如何更好，事实是：我发送了错误的图片 – 减小用户发送错误图片（信息）的行为
所以在分析问题的时候，需要：
- 摆脱思维惯性，正确地描述问题
- 最终目标（理想解）是什么，思考如何达到最终理想解
- 清楚关键的技术矛盾是什么
- 清楚地描述技术矛盾，而不是描述现在遇到了什么问题（很可能不是最大的矛盾）
- 先不要考虑解决方法，也不要考虑中间结果是什么
- 如果遇到不懂的问题，要问关键的人（知道这件事的人），不要四处瞎问
问题和答案像一条河的两岸，从要解决的问题中分析出矛盾，从分析矛盾中找出解决的方法。
《创新算法》还提到其他的反常识和思维误区：
- 问题的区分：我们需要知识来判断什么问题必须解决，并且把必须解决的问题和能否解决的问题分开。
- 问题的解决：问题必须通过知识来解决，而不是通过大量实验解决。
- 问题的本质：（几乎）「不需要任何东西」就能提供需要的功能，理想的解决方案是「机器不存在也能做功」。
- 用行业中已知方法改进一个特性，将会恶化另一个特性。
- 创新的频率：如果创新问题的间隔时间很长，会丧失以前的创新过程中得到的经验和技巧。持续的创新工作能丰富发明家的原理「武器库」，增强他对个人能力的信心。
当然，神作级别的书籍真的挺难理解的，还没能给把整本书全部吸收的层次，一点点改变自己的思维惯性，从小事做起。
- created，161213
