作为一个产品研发工程师，我们的工作就是解决问题（Problem Solving）。我们会遇到来自产品经理、业务人员甚至客户的问题，需要给出解决方案。

面对这些问题时，我们需要先想一下，它是否存在 XY 问题。

Problem Solving

什么是 XY 问题？

Wikipedia 定义

XY problem by Wikipedia

The XY problem is a communication problem encountered in help desk, technical support, software engineering, or customer service situations where the question is about an end user’s attempted solution (Y) rather than the root problem itself (X).

XY 问题是在服务台、技术支持、软件工程或者客户服务过程中遇到的沟通问题，用户并没有问他实际想解决的问题（X 问题），而是在问他自己假设的解决方案（Y 问题）

xyproblem.info 定义

https://xyproblem.info/

  • 用户期望解决 X。
  • 用户不知道怎么解决 X，但是认为只要解决了 Y 就可以解决 X。
  • 用户不知道怎么解决 Y。
  • 用户来问，怎么解决 Y。
  • 我们来试图去解决 Y

浪费了大量的时间和精力后，我们最终发现，原来用户希望解决的是 X，并且 Y 并不是解决 X 的最优方案。

实际的例子

在我的工作经历中，有着大量的 XY 问题发生过。

在金数据产品中，用户可以在共享表单时设置自定义权限。假设我有一个学校郊游统计表，那么我可以创建一个自定义角色，某个老师只可以看到自己班级学生提交的信息。

有一天，一个客户反馈，他希望可以在不同的表单上「批量复制自定义角色」，原因是表单上的自定义角色太多了（多大几十个），每次新添加一个表单就得手工创建一遍角色非常的麻烦。

单纯看这个问题，wow，他的表单上有几十个自定义角色，确实如果每次手工添加一次，会非常麻烦。为了提升效率，我们开发一个「批量复制自定义角色」的功能，貌似是理所应当的。

这里就陷入了 XY 问题。

因为「复制自定义角色」，是客户自己假设的解决方案（Y 问题），但是我们并没有搞清楚，客户实际的 X 问题是什么。

经过沟通，实际的 X 问题，是希望可以更高效的配置自定义角色。我们的自定义权限无法使用更复杂的账号属性去配置。例如全校 50 个老师，那么客户就需要配置 50 个自定义权限（X 问题）分配给每个老师。

实际的 X 问题：

角色：1年1班老师，权限：学生.班级 = 1年1班
角色：1年2班老师，权限：学生.班级 = 1年2班
...
角色：6年4班老师，权限：学生.班级 = 6年4班

所以我们只需要解决了 X 问题，Y 问题也就不存在了。

实际的 X 问题解决方案（只需要配置一个自定义角色，50个老师都可以使用）：

角色：班主任，权限：学生.班级 = 当前老师.班级

这样子也就不存在 Y 问题了。每次新建表单，只需要添加一个自定义角色，这个过程是 OK 的，也就不需要「批量复制自定义角色」的功能了。

如何避免 XY 问题？

XY 问题的本质，是一个 沟通的问题 。

你以为你讲清楚了，其实并没有。或者，你以为你理解了，其实并没有。

所以解决 XY 问题，需要提升沟通的能力。

如果你是一个提问者

提问需要智慧。(关于 提问的智慧 ，又会是一个单独的文章，可以参考 github上的总结。

简单来讲，提问一定要给出 上下文 (Context)。

我自己在工作中，在聊天工具中，每天都会遇到大量的这种问题：

  • 冯sir，我们系统能否支持 A 功能？
  • 冯sir，我们系统 B 这里优化需要几天？
  • 冯sir，有个客户想要定制功能，我们可不可以做？
  • 冯sir，解压 1 个 G 的代码怎么写？

很多团队现在都是 remote 远程工作比较多，大多数沟通都无法 face 2 face 当面完成。

如果你是一个提问者，千万不要提这种「一句话问题」，一定要给出对方上下文（Context）。一个优秀的问题，应该是下面这样子的：

冯sir，我有一个客户 xxx，他的业务是 xxxx，现在是计划升级到套餐 xx，但是遇到了问题 xxx，我们已经尝试过 xxx 和 xxx，但是 xxx 因为 xxx 不行。想问一下你是否有更好的解决方案。

当我看到这样子的问题时，我的心情是非常好的。

如果你是一个问题解决者

那很简单，在你试图解决问题前，先和对方搞清楚，避免陷入 XY 问题。

对于一个产品的工程师（或者产品经理），一个很重要的能力，就是区分「需求」和「要求」。因为我们无法约束客户提问的能力，大多数客户只会说「我希望这个按钮是红色的」，而不会说「我希望这个按钮是容易点击的」。

特别是对于 2B 产品的产研团队，我们的产品一般都是业务复杂度较高的，需要我们有更高的「抽象」能力，从客户的要求（Y 问题），识别出客户真实的需求（X 问题）。

参考链接

  • Wikipedia https://en.wikipedia.org/wiki/XY_problem
  • https://xyproblem.info/
  • X-Y PROBLEM（@左耳朵耗子）https://coolshell.cn/articles/10804.html