X-Y Problem

X-Y Problem

X-Y Problem

对于X-Y Problem的意思如下:

1)有人想解决问题X
2)他觉得Y可能是解决X问题的方法
3)但是他不知道Y应该怎么做
4)于是他去问别人Y应该怎么做?

简而言之,没有去问怎么解决问题X,而是去问解决方案Y应该怎么去实现和操作。于是乎:

1)热心的人们帮助并告诉这个人Y应该怎么搞,但是大家都觉得Y这个方案有点怪异。
2)在经过大量地讨论和浪费了大量的时间后,热心的人终于明白了原始的问题X是怎么一回事。
3)于是大家都发现,Y根本就不是用来解决X的合适的方案。

X-Y Problem最大的严重的问题就是:在一个根本错误的方向上浪费他人大量的时间和精力

示例

举个两个例子:

Q) 我怎么用Shell取得一个字符串的后3位字符?
A1) 如果这个字符的变量是$foo,你可以这样来 echo ${foo:-3}
A2) 为什么你要取后3位?你想干什么?
Q) 其实我就想取文件的扩展名
A1) 我靠,原来你要干这事,那我的方法不对,文件的扩展名并不保证一定有3位啊。
A1) 如果你的文件必然有扩展名的话,你可以这来样来:echo ${foo##*.}

再来一个示例:

Q)问一下大家,我如何得到一个文件的大小
A1)  size = ls -l $file  | awk '{print $5}'
Q) 哦,要是这个文件名是个目录呢?
A2) 用du吧
A3) 不好意思,你到底是要文件的大小还是目录的大小?你到底要干什么?
Q)  我想把一个目录下的每个文件的每个块(第一个块有512个字节)拿出来做md5,并且计算他们的大小 ……
A1) 哦,你可以使用dd吧。
A2) dd不行吧。
A3) 你用md5来计算这些块的目的是什么?你究竟想干什么啊?
Q) 其实,我想写一个网盘,对于小文件就直接传输了,对于大文件我想分块做增量同步。
A2) 用rsync啊,你妹!

这里有篇文章说明了X-Y Problem的各种案例说明,我从其中摘出三个来让大家看看:

你试图做X,并想到了用Y方案。所以你去问别人Y,但根本不提X。于是,你可以会错过本来可能有更好更适合的方案,除非你告诉大家X是什么。

— from Re: How do I keep the command line from eating the backslashes? by revdiablo

有些人问怎么做Y,但其它他想做的是X。他问怎么做Y是因为他觉得Y是最好搞定X的方法。 于是大家不断地回答“试试这个,试试那个”来帮助他,而他总是在说“这个有问题,那个有问题,因为……”。基本不同的情况,其它的方案可能会更好。

— from Re: Re: Re: Re: regex to validate e-mail addresses and phone numbers by Limbic~Region

X-Y Problem又叫“过早下结论”:提问者其实并不非常清楚想要解决的X问题,他猜测用Y可以搞定,于是他问大家如何实现Y。

— from <[email protected]> by Alan J. Flavell

其实这个问题在我之前的《你会问问题吗》里提到的那篇How To Ask Questions the Smart Way中的提到过,你可以移步去看一下

所以,我们在寻求别人帮助的时候,最好把我们想解决的问题和整个事情的来龙去脉说清楚。

一些变种

我们不要以为X-Y Problem就像上面那样的简单,我们不会出现,其实我们生活的这个世界有有各种X-Y Problem的变种。下面我个人觉得非常像XY Problem的总是:

其一、大多数人有时候,非常容易把手段当目的,他们会用自己所喜欢的技术和方法来反推用户的需求,于是很有可能就会出现X-Y Problem – 也许解决用户需求最适合的技术方案是PC,但是我们要让他们用手机。

其二、产品经理有时候并不清楚他想解决的用户需求是什么,于是他觉得可能开发Y的功能能够满足用户,于是他提出了Y的需求让技术人员去做,但那根本不是解决X问题的最佳方案。

其三、因为公司或部门的一些战略安排,业务部门设计了相关的业务规划,然后这些业务规划更多的是公司想要的Y,而不是解决用户的X问题。

其四、对于个人的职业发展,X是成长为有更强的技能和能力,这个可以拥有比别人更强的竞争力,从而可以有更好的报酬,但确走向了Y:全身心地追逐KPI。

其五、本来我们想达成的X是做出更好和更有价值的产品,但最终走到了Y:通过各种手段提升安装量,点击量,在线量,用户量来衡量。

其六、很多团队Leader都喜欢制造信息不平等,并不告诉团队某个事情的来由,掩盖X,而直接把要做的Y告诉团队,导致团队并不真正地理解,而产生了很多时间和经历的浪费。

所有的这些,在我心中都是X-Y Problem的变种,这是不是一种刻舟求剑的表现?

参考

(全文完)

(转载本站文章请注明作者和出处 酷 壳 – CoolShell ,请勿用于任何商业用途)

好烂啊有点差凑合看看还不错很精彩 (124 人打了分,平均分: 4.67 )
Loading...

X-Y Problem》的相关评论

  1. X-Y确实比较浪费精力,不过我觉得在自己探索学习的时候X-Y不失为一种积累经验的办法

  2. 呵呵,其实跟人的心理有关,X-Y其实是一种包装术,目的是为了掩饰自己的无知,他们害怕听到这样回复:
    ——如何才能获取文件扩展名?
    ——我拷,你连个文件扩展名都不会获取?!

  3. 从来没做过沙发,今天看到了想做一会~结果无情的被地板了~~博主加油

  4. 对于回答者来说,好好地回答Y问题就可以了。至于提问者有没有把 X 问题说出来,可能是提问者认为这并非关键。X-Y 背后可能还有一个 X-Y,构成一个问题链。

  5. @Leo
    这可以引申到整个东方文化圈的”面子问题”带来的低下的沟通效率, 我觉得这是东方在现代技术上败给西方的最根本原因, 可预见的将来这个局面都不会有改变, 可以读一下”飞机失事的族裔理论”.

  6. 提问的智慧里面有一条也是这个精神”描述问题症状而不是猜测”, 我也多次骂同事”说你的需求, 而不是你的分析”, 没人改, 回头还是得我诱导他说出需求

  7. CX3201 :
    X-Y确实比较浪费精力,不过我觉得在自己探索学习的时候X-Y不失为一种积累经验的办法

    1,2步没问题, 1,2,3,4就有问题了

  8. JimmyZ :

    CX3201 :
    X-Y确实比较浪费精力,不过我觉得在自己探索学习的时候X-Y不失为一种积累经验的办法

    1,2步没问题, 1,2,3,4就有问题了

    不错,4换成搜索还行,问别人问题就要考虑到对方的感受

  9. 有些leader把自己定位在分析问题的位置,把团队定位在执行其意图的位置,所以他根本不想让团队来一起分析问题。实际上,这样的人无法适应一群人共同讨论出一个方案的做法,他们只能适应一个人说一群人做。。。

  10. 互联网团队大量的产品经理是真的没有分析需求本质的能力的,导致整个研发团队疲劳低效,产品效果也不好。

  11. 因为很多编程社区的人(特别是学院派)都是傲慢的,一个傻逼的问题问得太直白会引起群嘲,然后那些“geek”就会趁机添乱(例如“老手是这样教新手编程的”),所以新手不得不随便糊弄出一个“自己的方案”,以表明“自己已经努力地想了这个问题”,不然老鸟们又叫他们先多想了。其实程序员圈子和其它以资历分等级的群体一样都是弱肉强食,无论新人怎么做都是错的

  12. 说到心坎上去了,有个同事问问题经常这样,饶了一大圈知道她想要什么后才发现之前的都是无用功。

  13. ……甚至遇到过XYZABCDEFG问题……

    有人问G怎么做,折腾很久才发现他想做F;于是告诉他F只要怎么就好了;结果他试过不行,说其实他想做的是E;好吧,E也很简单……N轮后,终于发现他不过是想解决X……

    怎么解决X呢?最蠢的,就把 怎么解决X 敲到google搜索框里,满屏都是答案。

    但人家就是不做这一步,楞是从X想入非非折腾到了G……

  14. 技术部们讨论:
    现在需要解决 X 问题.
    我认为用 C艹 解决这个问题很合适, 但我们需要一些会 C艹 的程序员.

    HR 发布招聘信息:
    岗位要求: 精通 C艹…
    (招来要干什么, 几乎写明白了)

  15. invalid :
    ……甚至遇到过XYZABCDEFG问题……
    有人问G怎么做,折腾很久才发现他想做F;于是告诉他F只要怎么就好了;结果他试过不行,说其实他想做的是E;好吧,E也很简单……N轮后,终于发现他不过是想解决X……
    怎么解决X呢?最蠢的,就把 怎么解决X 敲到google搜索框里,满屏都是答案。
    但人家就是不做这一步,楞是从X想入非非折腾到了G……

    +1

  16. 其实还是有必要的,领悟总是需要代价的,有时候,别人提出了更好的X的解决办法,我还是坚持先把Y的问题解决了再来看这个更好的办法,然后对比一下为什么自己没想到,熟能生巧,之后就能少走弯路..

  17. Y是用户提的问题、需求;X才是用户的背景需求!
    透过Y找到X,才是需求分析的功力所在。
    这种场合,才是老人的用武之地:阅历、经验非常重要

  18. 您好,第一个例子好像有一点小错误 “如果这个字符的变量是$foo,你可以这样来 echo ${foo:-3}”最后是不是应该在“-3”外加上括号?改为“ echo ${foo:-3}”

  19. 您好,第一个例子好像有一点小错误 “如果这个字符的变量是$foo,你可以这样来 echo ${foo:-3}”最后是不是应该在“-3”外加上括号?改为“ echo ${foo:(-3)}”
    ps:手一抖按错了,不好意思。

  20. 我一般不太喜欢向人提问题,我比较喜欢自己思考问题的解决方案,不行之后再Google之! 因为从别人那里问来的都是二手的知识,就算你完全领会了,你运用该知识的水平还是在别人之下! 要想能力不低于身边的人,你就必须自主学习,不断训练独自解决问题的能力.怎么训练独自解决问题的能力? 答案就在楼主所说的X-Y Problem里面了,假如那些高傲的回答者都鄙视提问者的Y问题的话,那么这些提问者的求知欲望就被你狠狠地打击下去了…假如在这X-Y Problem里面我是被提问者的话, 我会认真地回答提问者的Y问题,帮他解决了Y问题之后,如果提问者也告诉我X问题的话,我会很开心地跟他一起探讨X问题的解决方案的

  21. zln :
    因为很多编程社区的人(特别是学院派)都是傲慢的,一个傻逼的问题问得太直白会引起群嘲,然后那些“geek”就会趁机添乱(例如“老手是这样教新手编程的”),所以新手不得不随便糊弄出一个“自己的方案”,以表明“自己已经努力地想了这个问题”,不然老鸟们又叫他们先多想了。其实程序员圈子和其它以资历分等级的群体一样都是弱肉强食,无论新人怎么做都是错的

    嘲笑是不好但问蠢问题就别怪人嘲笑, 如果你得到了礼貌的回答那你很幸运, 如果不礼貌对方也没错, 他又不欠你一个礼貌的回答.

  22. 耀天 :
    我一般不太喜欢向人提问题,我比较喜欢自己思考问题的解决方案,不行之后再Google之! 因为从别人那里问来的都是二手的知识,就算你完全领会了,你运用该知识的水平还是在别人之下! 要想能力不低于身边的人,你就必须自主学习,不断训练独自解决问题的能力.怎么训练独自解决问题的能力? 答案就在楼主所说的X-Y Problem里面了,假如那些高傲的回答者都鄙视提问者的Y问题的话,那么这些提问者的求知欲望就被你狠狠地打击下去了…假如在这X-Y Problem里面我是被提问者的话, 我会认真地回答提问者的Y问题,帮他解决了Y问题之后,如果提问者也告诉我X问题的话,我会很开心地跟他一起探讨X问题的解决方案的

    请问你被别人问问题问过多少次?

  23. CX3201 :

    JimmyZ :

    CX3201 :
    X-Y确实比较浪费精力,不过我觉得在自己探索学习的时候X-Y不失为一种积累经验的办法

    1,2步没问题, 1,2,3,4就有问题了

    不错,4换成搜索还行,问别人问题就要考虑到对方的感受

    我觉得你好像没抓到原文的要点, 这样拐着弯儿问是浪费时间和精力, 不管对A还是Q, 当然了感受也会差, 但这不是重点

  24. 1、问问题 = 解决问题!= 上课求学

    别尼玛平常训练/讨论,需要你刻苦、需要你好奇、需要你举一反三的时候,你的精神头不知道哪里去了;等上战场了,你的好奇心、探索欲、研究欲、“开放性思维”反倒一个个来了。

    事实上,这根本不是什么好奇、不是什么研究,这叫固执。说难听点叫犟驴。

    这号人我见太多了……简单直白,十分钟能解决的方案,偏不用,非要把什么ACE、XML都用上。而且用的粗敝不堪、漏洞百出,而且要和他负责部分八杆子打不着的东西都扯到一块。最后多半是浪费了一个月甚至几个月,搞出无数bug,然后留下个烂摊子拍屁股走人。

    几个月前刚接过这么个烂摊子。功能就实现了十分之二、三,倒是到处bug,动不动死锁;非要搞个莫名其妙的消息队列,然后队列里给塞了上百万个定时任务(这都什么设计!),闹的连linux都崩溃了。偶和另外两位同事用了几周时间,才把他留下的东西清理了一遍,最后几乎删掉了所有逻辑,去掉了消息队列之类无聊的东西,这才勉强正常运行……
    然后又花了一周左右,把他没有实现的、另外十分之7、8的功能加上了。

    2、很明显,固执的背后,其实是无能……无能而又不愿承认自己的无能。

    搞出XYZABCDEFG问题,根本原因还是不知道怎么解决X问题。

    没有人天生能解决所有问题。但,至少有些人知道香臭。

    ——关于X问题,按照目前的认识水平,共有N个可行方案
    ——其中方案A、B业界有先例;其它方案理论上可行
    ——每个方案的优缺点是……
    ——每个方案的风险是……
    ——综合评估,考虑我们的技术能力,可行方案是……

    ——这就叫“需要你举一反三的时候”。这时候不提,一旦方案确定,后面就别来添乱。

    类似的,如果X问题由你一个人负责,那么你当然可以提出Y方案,而且当然可以就着Y方案去问问题——前提是,你必须自己保证Y方案的可行性。

    如果问来问去、折腾许久,哎呀,Y方案看来不行……其实我想做的是X……

    不好意思,这种情况只能说明,你根本不称职,根本就没资格去负责一个完整的X问题。
    最最起码,也是你在缺乏足够了解之前就贸然下了结论,说明性格上过于刚弼自用,不成熟且缺乏责任感——俗称大炮是也。

    当然,这种错误,极其偶然的发生几次,没问题,没谁是圣人,能生而知之。但如果老是这样,不是你的问题是谁的问题?

  25. 感觉是治标和治本的问题,有些问题提出来的时候就察觉到很奇怪或者能模糊的察觉到原始的意图。初学者难免。

  26. @zln

    JimmyZ :

    zln :
    因为很多编程社区的人(特别是学院派)都是傲慢的,一个傻逼的问题问得太直白会引起群嘲,然后那些“geek”就会趁机添乱(例如“老手是这样教新手编程的”),所以新手不得不随便糊弄出一个“自己的方案”,以表明“自己已经努力地想了这个问题”,不然老鸟们又叫他们先多想了。其实程序员圈子和其它以资历分等级的群体一样都是弱肉强食,无论新人怎么做都是错的

    嘲笑是不好但问蠢问题就别怪人嘲笑, 如果你得到了礼貌的回答那你很幸运, 如果不礼貌对方也没错, 他又不欠你一个礼貌的回答.

    新手问 for … in … 这类什么意思的问题,你怎么看 ?

  27. @invalid
    你举的这个例子很普遍,在当事人所知范围内他只能搞出个“莫名其妙的消息队列”,这肯定对他来说已经是最优方案了,已经do了他的best,可以说是能力不够,但这跟x-y关系不大吧。

  28. mashiguang :
    @invalid
    你举的这个例子很普遍,在当事人所知范围内他只能搞出个“莫名其妙的消息队列”,这肯定对他来说已经是最优方案了,已经do了他的best,可以说是能力不够,但这跟x-y关系不大吧。

    首先,搞一个消息队列出来,仅仅是为了做“周期性任务”;和直接用crontab或者线程来定时执行任务,哪个需要的能力更高?

    ——我的改进方案你知道是什么吗?
    ——直接用一个线程来定时调用他的定时任务代码!
    ——就这一点“改进”,所有相关bug就消失了,系统完全达到设计指标。

    其次,哪怕他的确是“do了他的best”、甚至哪怕唯一正确的方案就是消息队列,这仍然不仅仅是一个能力问题。

    ——XX方面我不熟,请给我一些时间学习:说句真话会死?
    ——我就经常说这句话,还有个同事也这样。
    ——别人总是“几天就行了”;我们总是“最少得一个月”。
    ——但,最难最复杂的任务,只有我们两个能接:别的人一个个“精通”的不得了,但上面还是只敢用我们两个“这也不懂那也不懂”的。

    因为这是在做工程。
    不是做实验,不是学校学习,更不是吹牛开玩笑:耽误了发行时间,经常可能是上百万甚至数百万的事。

    什么叫工程?
    工程就是尽量学懂到十分,但却只敢用到一分。
    非如此,怎么可能做到十拿九稳?连九成的把握都没有,你怎么保证工程的质量?

    如果你即便“do了best”,也不过是这个屌样,怎么当初接任务敢接那么干脆?

    说一句不懂,没什么。多给你几天甚至一个月学习,行不?
    有这句话,你并不会丢掉工作,更不会如此狼狈的丢掉工作——跑路?!
    有这句话,PM会合理调整计划,就不会天天跟屁股后面催进度——越催你越抓瞎。

    靠谱的人,就不会做如此不靠谱的事。

  29. JimmyZ :

    zln :
    因为很多编程社区的人(特别是学院派)都是傲慢的,一个傻逼的问题问得太直白会引起群嘲,然后那些“geek”就会趁机添乱(例如“老手是这样教新手编程的”),所以新手不得不随便糊弄出一个“自己的方案”,以表明“自己已经努力地想了这个问题”,不然老鸟们又叫他们先多想了。其实程序员圈子和其它以资历分等级的群体一样都是弱肉强食,无论新人怎么做都是错的

    嘲笑是不好但问蠢问题就别怪人嘲笑, 如果你得到了礼貌的回答那你很幸运, 如果不礼貌对方也没错, 他又不欠你一个礼貌的回答.

    所以说,这才是逼着菜鸟们去乱想一些方案,然后再问该方案怎么做,这才显得他们“想过了”。这种现象在美国的学校很常见,学生问问题通常叫兽都叫他们先自己想,于是大部分人都想了一堆错误的方案,但是叫兽不会当面说你错,于是他们就越陷越深了

回复 伟程 取消回复

您的电子邮箱地址不会被公开。 必填项已用*标注