Comments 35
UFO just landed and posted this here
Мне кажется, что все случаи XY так или иначе относятся к неправильной коммуникации. Классический пример XY-проблемы возникает, когда оба участника не очень знают, где иксы, а где игреки.
Неосознанная компетентность в распознавании XY быстро формируется у тех, кто много общается с клиентами. А это довольно широкий спектр профессий: от аптекаря до тимлидов разработки.
Вот в этом классическом примере feline раскусил намерения n00b как орешек. А мог ведь схалатничать и остановиться на Y.
Неосознанная компетентность в распознавании XY быстро формируется у тех, кто много общается с клиентами. А это довольно широкий спектр профессий: от аптекаря до тимлидов разработки.
Вот в этом классическом примере feline раскусил намерения n00b как орешек. А мог ведь схалатничать и остановиться на Y.
Чаще сталкиваюсь с обратной проблемой. Спрашиваю, как сделать Y, а мне начинают предлагать тысячу альтернативных решений проблемы X.
Самое забавное, что в конечном итоге находится человек, который не умничает, а отвечает на поставленный вопрос, и проблема X таки оказывается решена способом Y.
Самое забавное, что в конечном итоге находится человек, который не умничает, а отвечает на поставленный вопрос, и проблема X таки оказывается решена способом Y.
Обратный проблема тоже довольна интересная. Вам, видимо, встречаются заботливые люди, которые хотят всех уберечь от ошибок.
Люди, не желающие отвечать на вопрос, а желающие спросить в ответ «тебе это зачем?» — они повсюду. Бесит предельно.
*не обновил комменты — JustDont именно об этом пишет.
*не обновил комменты — JustDont именно об этом пишет.
Бесит =) Если те люди, которым задают вопросы, являются экспертами (а не псевдоэкспертами и всезнайками) в своей области, то их можно понять. У них же тоже есть ограничения по времени, накопившаяся усталость от повторяющихся вопросов и т.д. Другой вопрос: зачем они начинают отвечать на вопрос, если на самом деле не собираются?)
Надо сразу спрашивать так, чтобы было понятно, почему вас не устраивает X. Например, уточнить, что вы пишете диссертацию по механическим свойствам микроскопов с прицелом на Шнобелевскую премию.
С появление SO обратную проблему можно там наблюдать вообще каждую минуту.
— Как мне сделать Y?
— А зачем тебе нужно сделать Y?
— Я решаю задачу X, и после изучения всех вариантов пришел к выводу, что способ Y будет наилучшим для меня.
— Зачем тебе Y, возьми лучше A, B, C, или вот попробуй крутое D! (это на самом деле означает, что отвечающий тоже не знает, как сделать Y, и просто тратит твоё время зря)
Через некоторое время уже начинаешь понимать что к чему, и пытаешься сразу писать вопрос в стиле «нужно Y для X, варианты A, B, C, и даже D — не предлагать по религиозным причинам». Еще через некоторое время понимаешь, что задавать такие вопросы бесполезно, на SO и подобных ресурсах никому не интересны сложные вопросы.
— Как мне сделать Y?
— А зачем тебе нужно сделать Y?
— Я решаю задачу X, и после изучения всех вариантов пришел к выводу, что способ Y будет наилучшим для меня.
— Зачем тебе Y, возьми лучше A, B, C, или вот попробуй крутое D! (это на самом деле означает, что отвечающий тоже не знает, как сделать Y, и просто тратит твоё время зря)
Через некоторое время уже начинаешь понимать что к чему, и пытаешься сразу писать вопрос в стиле «нужно Y для X, варианты A, B, C, и даже D — не предлагать по религиозным причинам». Еще через некоторое время понимаешь, что задавать такие вопросы бесполезно, на SO и подобных ресурсах никому не интересны сложные вопросы.
не интересны сложные вопросы
В итоге появляется мотивация создавать кучу проф.соц.связей, чтобы всегда был список контактов в скайпе, кому можно задать вопрос. А порой обсудить проблему коллективным надмозгом.
P.S. Понял плюсы конференций и всевозможных слетов.
Есть обратное мнение, что на таких ресурсах наоборот тусуются люди, ожидающие сложных вопросов. Знаете, как искушенные люди, которые всегда хотят нового, свежего, уникального контента. Вы приходите к ним со своей уникальной проблемой, но они проскринив её принимают решение, что всё это уже было. И вот вам варианты от A до Z. В итоге все уходят неудовлетворёнными.
А вообще в XY проблемах предполагается же, что задающий вопрос знает меньше, а отвечающие знают больше. Но на SO другое соотношение спрашивающих и отвечающих, там много знающих спрашивающих у знающих. В таких случаях, наверное, целесообразно вступать в тематические телеграм-чаты, где пока много заряженных на конструктив участников.
А вообще в XY проблемах предполагается же, что задающий вопрос знает меньше, а отвечающие знают больше. Но на SO другое соотношение спрашивающих и отвечающих, там много знающих спрашивающих у знающих. В таких случаях, наверное, целесообразно вступать в тематические телеграм-чаты, где пока много заряженных на конструктив участников.
Есть обратное мнение, что на таких ресурсах наоборот тусуются люди, ожидающие сложных вопросов.
Мой опыт свидетельствует строго об обратном. Да и принципы работы таких сайтов с этим согласуются: геймификация направлена на поощрение тех, кто даёт максимально много хороших ответов на вопросы, при этом сложность вопроса вообще никак не учитывается (SO) или учитывается по принципу «палец, небо, тык» (Тостер). Отсюда вытекает главный принцип успешного отвечальщика: отвечать на много вопросов. Сложные вопросы требуют тратить на них время, и поэтому они отвечальщиков не интересуют; можно лишь надеяться на то, что чисто случайно ваш вопрос увидит специалист нужной области, случайно заглянувший в вопросы в нужное время. Но с ростом объема вопросов эта вероятность стремительно падает.
Под эту проблему пытаются вставлять костыли в виде монетизации процесса спрашивания-отвечания, но это всё работает очень посредственно.
Есть такое мнение, что люди, которые что-то умеют, и заняты чем-то полезным — ни на каких ресурсах не тусуются.
По мне так вы немного путаете кислое с мягким…
Проблема ХУ говорит о том, что при постановки задачи в большинстве случаев хорошо бы начать собственно с описания проблемы, а не формулировки как именно ее надо решить. Это актуально во всех случаях, когда вы обращаетесь к специалистам в области решения подобных проблем, квалификация которых, как минимум не ниже вашей (вы как пользователь ставите задачу программисту, вы как заказчик ставите задачу строителю и тп...).
Описанная же вами и JustDont проблема относится к вопросам, заданным в профессиональной среде (на тематических ресурсах по обмену опытом), где все «по одну сторону баррикад» (все специалисты, а не заказчики) и собственно вариант решения Y cамоценен сам по себе… Просто некоторые из отвечающих забывают переключиться. ;)
Ну и конечно если задача ставится исполнителям их непосредственным руководителем — в подавляющем большинстве случаев вопросы типа «а почему вот именно так, а не иначе, а зачем… » — лишняя трата времени. Не всегда, но часто. Обычно конкретный программист не очень представляет проект в целом, и обосновать применение того или иного подхода в данном случае чревато долгой и утомительной философской беседой…
Проблема ХУ говорит о том, что при постановки задачи в большинстве случаев хорошо бы начать собственно с описания проблемы, а не формулировки как именно ее надо решить. Это актуально во всех случаях, когда вы обращаетесь к специалистам в области решения подобных проблем, квалификация которых, как минимум не ниже вашей (вы как пользователь ставите задачу программисту, вы как заказчик ставите задачу строителю и тп...).
Описанная же вами и JustDont проблема относится к вопросам, заданным в профессиональной среде (на тематических ресурсах по обмену опытом), где все «по одну сторону баррикад» (все специалисты, а не заказчики) и собственно вариант решения Y cамоценен сам по себе… Просто некоторые из отвечающих забывают переключиться. ;)
Ну и конечно если задача ставится исполнителям их непосредственным руководителем — в подавляющем большинстве случаев вопросы типа «а почему вот именно так, а не иначе, а зачем… » — лишняя трата времени. Не всегда, но часто. Обычно конкретный программист не очень представляет проект в целом, и обосновать применение того или иного подхода в данном случае чревато долгой и утомительной философской беседой…
пытаешься сразу писать вопрос в стиле «нужно Y для X, варианты A, B, C, и даже D — не предлагать по религиозным причинам».
И это почти правильный подход. Правильный подход еще и в двух словах описать что за причины, вместо «религиозных».
В том числе и потому, что никто не гарантирует что вы правы в своих предположениях, и не поймете что-то новое. А может даже так оказаться, что когда начнете расписывать причины, сами поймете что это не причины а говно, и сделаете вариантом D.
Даннинг-Крюггер не дремлят, в общем.
Зависит от того, кто именно ставит задачу… ;) Условно пользователь/клиент, или начальник/коллега (в широком смысле).
Если пользователь — то ему нужно не спрашивать, как сделать что-то, а описывать проблему с которой он столкнулся, потому, что весьма вероятно, что его проблема решается проще. А если, допустим, программист на тематическом форуме спросил как «выстрелить себе в ногу», то его цель именно узнать, как выстрелить в ногу и рассказывать ему, что в ногу лучше не стрелять — в принципе означает сомневаться в его компетенции. Другое дело, если человек сам сразу говорит, мол «я в этом деле новичок, разъясните дураку»… ;)
Если пользователь — то ему нужно не спрашивать, как сделать что-то, а описывать проблему с которой он столкнулся, потому, что весьма вероятно, что его проблема решается проще. А если, допустим, программист на тематическом форуме спросил как «выстрелить себе в ногу», то его цель именно узнать, как выстрелить в ногу и рассказывать ему, что в ногу лучше не стрелять — в принципе означает сомневаться в его компетенции. Другое дело, если человек сам сразу говорит, мол «я в этом деле новичок, разъясните дураку»… ;)
Правильный подход еще и в двух словах описать что за причины, вместо «религиозных».
Правильный подход — не описывать вообще ничего, а вникать самому (или не вникать и работать вообще в другом направлении).
Если вам требуется существенное количество времени, чтоб описать суть проблемы и всех ограничений для того же SO — это первый признак, что вы тратите время зря и в итоге получите вопрос с 0 ответов и 0 полезных комментариев.
Иногда можно выкинуть все тонкости и надеяться (именно надеяться), что кто-нибудь из отвечающих таки расскажет что-то полезное про требуемый вам Y. Но если тонкости выкинуть нельзя — сайты а-ля SO вам просто не помогут.
Есть довольно забавный вариант XY (И вариаций XYZ, и больше, и больше букв) проблем — корпоративный. Когда сотрудник не может решить проблему X/ему это не выгодно/это приведёт к его увольнению, поэтому он убеждает всех, что есть проблема Y, которую все пытаются решить, не приближаясь к решению изначальной проблемы, но позволяя сотруднику зарабатывать или получить другую выгоду. Вокруг просто тысячи примеров:
* Абстрактная компания не готовит вкусную еду за соответствующую сумму денег? А давайте продавим найм кучи менеджеров/программистов/аналитиков, чтобы стабилизировать это плохое соотношение цены/качества и гарантировать доставку за n минут. Теперь мы научились доставлять еду быстро, премии нам! О, а давайте ещё приложение переделаем, люди не заказывают, так как сложно выбрать напиток. Вкус еды хуже, чем у разогретой заморозки из супермаркета? Отстань, мы занимаемся реальными проблемами, а не этим. При этом решение реальных проблем становится ещё более сложным, так как нужно разгонять толпу менеджеров и айтишников, чтобы сэкономить деньги на решение проблем.
* Зачем нанимать одного-двух способных программистов, когда можно объявить, что задача очень сложная, требует кучи времени, потом создать целый департамент и получать зарплату начальника департамента, а с премий покупать машины?
* Зачем условному менеджеру проекта следить за безопасностью, когда можно заявить, что нам нужны именно фичи, делать ещё одну фичу за спринт, получать премии и ездить на конференции. Вот когда утекут данные, тогда можно один месяц без премий посидеть, сказать, что вся проблема в недостаточном количестве фич и тестировщиков, получить ещё и бонус за их найм. Безопасность пользователей? Лохи, заткнитесь.
* Сложно решать реальные запросы пользователей в техподдержке, когда сотрудники на местах допускают кучу косяков? А давайте объявим, что повышение скорости ответа принесёт лояльность, будем повышать скорость. Есть куча способов, на год хватит. В итоге получаем тех поддержку уровня «Ого, мы продолбались, сорян. Нам так жаль. Иди, сделай что-нибудь сам завтра.»
* Зачем бороться с просрочкой, грубыми продавцами в магазине? Объявляешь, что наступила эра лояльности, будем выдавать всем карты. Купил гнилую рыбу в одном магазине, а тухлое мясо в другом. Ну и лох, а у меня премия за то, что проникновение карт лояльности вросло с 76.2% до 76.8%
Куча разных XY-проблем и неоптимальностей — это на самом деле попытки конкретных людей получить себе побольше ништяков. И реальное решение значительной части — выжигание из компании хитреньких, лояльненьких, умненьких с хорошими оральными навыками (во всех смыслах и почти во всех компаниях), а не вопросы «А что на самом деле вызывает трудности?»
* Абстрактная компания не готовит вкусную еду за соответствующую сумму денег? А давайте продавим найм кучи менеджеров/программистов/аналитиков, чтобы стабилизировать это плохое соотношение цены/качества и гарантировать доставку за n минут. Теперь мы научились доставлять еду быстро, премии нам! О, а давайте ещё приложение переделаем, люди не заказывают, так как сложно выбрать напиток. Вкус еды хуже, чем у разогретой заморозки из супермаркета? Отстань, мы занимаемся реальными проблемами, а не этим. При этом решение реальных проблем становится ещё более сложным, так как нужно разгонять толпу менеджеров и айтишников, чтобы сэкономить деньги на решение проблем.
* Зачем нанимать одного-двух способных программистов, когда можно объявить, что задача очень сложная, требует кучи времени, потом создать целый департамент и получать зарплату начальника департамента, а с премий покупать машины?
* Зачем условному менеджеру проекта следить за безопасностью, когда можно заявить, что нам нужны именно фичи, делать ещё одну фичу за спринт, получать премии и ездить на конференции. Вот когда утекут данные, тогда можно один месяц без премий посидеть, сказать, что вся проблема в недостаточном количестве фич и тестировщиков, получить ещё и бонус за их найм. Безопасность пользователей? Лохи, заткнитесь.
* Сложно решать реальные запросы пользователей в техподдержке, когда сотрудники на местах допускают кучу косяков? А давайте объявим, что повышение скорости ответа принесёт лояльность, будем повышать скорость. Есть куча способов, на год хватит. В итоге получаем тех поддержку уровня «Ого, мы продолбались, сорян. Нам так жаль. Иди, сделай что-нибудь сам завтра.»
* Зачем бороться с просрочкой, грубыми продавцами в магазине? Объявляешь, что наступила эра лояльности, будем выдавать всем карты. Купил гнилую рыбу в одном магазине, а тухлое мясо в другом. Ну и лох, а у меня премия за то, что проникновение карт лояльности вросло с 76.2% до 76.8%
Куча разных XY-проблем и неоптимальностей — это на самом деле попытки конкретных людей получить себе побольше ништяков. И реальное решение значительной части — выжигание из компании хитреньких, лояльненьких, умненьких с хорошими оральными навыками (во всех смыслах и почти во всех компаниях), а не вопросы «А что на самом деле вызывает трудности?»
Так же часто причиной XY проблем является желание разработчиков поиграться с технологией в проме.
Пример из жизни.
Вопрос: Ребята, а как передать через Kafka файл размером более 500 MB?
Начинаем разбираться понимаем, что для решаемой задачи сервиса вообще Kafka не нужна. И мало того, что приводит к излишнему усложнению, так еще и выступает в роли микроскопа, когда через нее пытаются перегнать такие большие файлы.
Но конкретный разработчик слушать про более вменяемые варианты не хочет, т.к. ему надо в резюме дописать Apache Kafka, о чем он конечно никогда не признается.
Это я к тому, что «хитрожопыми» в крупных компаниях бывают не только руководители департаментов.
Пример из жизни.
Вопрос: Ребята, а как передать через Kafka файл размером более 500 MB?
Начинаем разбираться понимаем, что для решаемой задачи сервиса вообще Kafka не нужна. И мало того, что приводит к излишнему усложнению, так еще и выступает в роли микроскопа, когда через нее пытаются перегнать такие большие файлы.
Но конкретный разработчик слушать про более вменяемые варианты не хочет, т.к. ему надо в резюме дописать Apache Kafka, о чем он конечно никогда не признается.
Это я к тому, что «хитрожопыми» в крупных компаниях бывают не только руководители департаментов.
UFO just landed and posted this here
И скриншоты со stackoverflow.
В этом блоге вы можете увидеть статьи о том, какие технологии мы применяем, о том, какие процессы проходят у нас в командах. Так вот, например, сейчас команда SRE активно погружает команду разработки в специфику нашей инфраструктуры. XY-ситуации стали практически ежедневной практикой. Иногда нам смешно от этого, иногда не очень. При этом круто же, что есть знание практик модерации таких ситуаций.
Что касается копипасты: о феномене XY я узнала в прошлом месяце и офигела. Не нашла на Хабре статей на эту тему (на тему самого феномена; того, как это мешает жить; того, как вовремя очухаться и не профукать кучу времени), поэтому решила написать. Также я не нашла в статье на Википедии, ссылку на которую вы даёте, как распознать XY-проблему, не нашла там, что в России это называется иначе, как и на нашла там чек-листа по выходу из этой ситуации.
Что касается копипасты: о феномене XY я узнала в прошлом месяце и офигела. Не нашла на Хабре статей на эту тему (на тему самого феномена; того, как это мешает жить; того, как вовремя очухаться и не профукать кучу времени), поэтому решила написать. Также я не нашла в статье на Википедии, ссылку на которую вы даёте, как распознать XY-проблему, не нашла там, что в России это называется иначе, как и на нашла там чек-листа по выходу из этой ситуации.
не нашла там, что в России это называется иначеГде вы нашли, что именно в России «проблема XY» называется именно «ошибкой молотка»?
Золотой молоток придумали и начали использовать отнюдь не в России, и в оригинале речь шла отнюдь не про микроскоп. Проблема молотка вполне может приводить к проблеме XY, но это все же разные проблемы.
P.S. От XY хорошо помогают «пользовательские истории», когда перед постановкой задачи описывают исходную проблему, а не просто просят помощи с инструментом.
зато тут есть комментарии, которые добавляют гораздо больше чем простая статья в википедии — например про корпоративные варианты или про SO-шные, или когда ХУ проблема на самом деле просто У проблема
Какие же криповые у вас изображения идут =)
Задачедатель не понимает сути задачи? Так это же один из основных постулатов ТРИЗ! Но тем не менее не документированный в явном виде, как именно постулат. Первая публикация по ТРИЗ — 1956 г. А в 2001 Eric Steven Raymond наконец-то дал этому феномену название? Очень своевременно.
Eric Steven Raymond довольно случайно дал феномену название, которое закрепилось и стало использоваться как устойчивое. На самом деле основной задачей его публикации был детальный разбор того, как задавать и как не задавать вопросы так, чтобы вам ответили.
Принцип Арнольда же.
Привет! Вы использовали наши с Александром Баракиным иллюстрации из ответа о проблеме XY. Классно, что они и к вашей статье подошли. Как и всё на SO, они были опубликованы под лицензией CC-BY-SA. Пожалуйста, укажите авторов и дайте ссылку на источник.
Я прочитал первые абзацы и начал протирать глаза.
— Люди начали жаловаться, что вынуждены невыносимо долго ждать лифт.
— Другие люди потратили много времени, сил и денег на то, чтобы улучшить работу лифтов.
— Первоначальная проблема — «люди начали жаловаться».
Что за хрень? Отсутствие жалоб на качество парашютов говорит о их безупречном качестве?!
— Люди начали жаловаться, что вынуждены невыносимо долго ждать лифт.
— Другие люди потратили много времени, сил и денег на то, чтобы улучшить работу лифтов.
— Первоначальная проблема — «люди начали жаловаться».
Что за хрень? Отсутствие жалоб на качество парашютов говорит о их безупречном качестве?!
Отсутствие жалоб на качество парашютов говорит о их безупречном качестве?!
Или о мастерстве укладчика.
Это довольно характерная особенность кучи компаний: работа не с проблемами, а с жалобами. Нет жалоб — нет проблем, премию руководству отдела. Но такой подход приводит к интересной проблеме: например, я достаточно давно перестал жаловаться в поддержку Перекрёстков и Спаров на проблемы, так как понял, что это убогие магазины, которым выгоднее торговать просрочкой и плесневелыми овощами. Их руководители перестали получать пинки от руководства, стали выглядеть в их глазах лучше — «Ого, а количество жалоб уменьшилось, молодец, Настенька». Но в итоге куча аналитиков (вроде толпы в 70 человек, о которой недавно писали на Хабре) считает, что нет проблем, поэтому надо улучшать мелочи, в то время как люди не покупают кучу товаров, так как опасаются потратить выходные на очистку организма.
Sign up to leave a comment.
Феномен XY: как избежать «неправильных» проблем