分享者
Plidezus
少楠说：这篇文章更多的是提供一个角度，用来检查自己是否会犯类似的错误 ——没有去问怎么解决问题X，而是去问解决方案Y应该怎么去实现和操作。在日常观察中，许多恶心的产品和代码都是因为这样的问题导致的。因为提问题的人以为自己找到了问题所在，而解决问题的人懒得思考就根据问问题的人给的方案开始实现了。
比如「我们日活不够所以需要增加一个打卡签到功能，最好是 xxoo 那个产品上的那种」，类似的例子屡见不鲜，尤其是偏运营的同学更容易出现类似的情况 ——因为相比提出这样一个明确的解决方案，思考本质的问题实在是非常辛苦而且很容易徒劳无功。这样提出来 case 能显得自己也是思考过的，不至于两手空空。但这样非常不利于成长，这里我试着给这种问题一个自己的解法：
- 向上看：在提出问题的时候，先停下来思考是否这是某个大问题的子集。比如你发现导出的 Excel 表格上总有一栏数据对不上，那么要思考的不是这张表格的问题，而是整个系统处理这类数据是否都会有类似的问题。
- 向前看：思考下如果解决了这个问题，是否会衍生其他问题。如果发现即使这个问题解决了后续还有不能解决的问题，要停下来思考的是这个问题是否是本质问题，或者说这条路是否能走得通。比如即使 Excel 导出不出错了，但是核对表格还是很麻烦。
- 向后看：思考是否是因为之前的一些（临时性的）策略导致今天的问题产生。那时候的决策放在今天来看是否还合理？是否需要对原始的规则进行修改？比如当时因为需要快速上线才做的 Excel 导出对账，那么今天和供应商已经配合默契且有开发资源，可以做到自动对账。
如那本讲述王兴的《九败一胜》书中所说：
发现一个问题千万不要立即去解决这个问题，而是应该思考到底系统上有什么漏洞，才导致了这个问题的产生。
X-Y Problem | | 酷 壳 - CoolShell
咨询公司方法论 | 如何在提问时避免「XY问题」