Проблема XY, или как правильно задавать вопросы

Автор оригинала: Živković Miloš
  • Перевод


Допустим, у вас возникли проблемы с файлами из-за их расширений. Вам нужно получить три последних символа, чтобы определить тип файла. Вы начинаете задавать вопросы об этом.
Вы ищете код для поиска трёх последних символов. Вероятно, у коллег могут быть какие-то предложения, так что вы спрашиваете и у них.

Вы застряли на месте со своим решением, но не возвращаетесь обратно к исходной проблеме.
Так вы столкнулись с проблемой XY. Давайте поговорим о ней подробнее.

Что такое «проблема XY»?


Проблема XY — это когда вы задаётесь вопросами о предпринятом решении Y. Но вместо этого нужно задаваться вопросами о проблеме X.

xyproblem.info

Давайте выявим общий алгоритм проблемы XY. Определение взято с сайта xyproblem.info, так что стоит заглянуть на него.

  • Пользователь хочет сделать X.
  • Пользователь не знает, как сделать X, но считает, что сможет нащупать путь к решению, если ему удастся сделать Y.
  • Пользователь не знает, как сделать и Y.
  • Пользователь начинает просить помощи с Y.
  • Люди пытаются помочь пользователю с Y, но Y кажется странной для решения проблемой.
  • Пользователю нужна помощь с X, а Y даже не является приемлемым решением X.

Вы пытаетесь получить расширение файла из трёх последних символов. Это проблема Y. Но истинная проблема заключается в нахождении всех расширений файлов. Это X.

Вместо того, чтобы обсуждать X, вы говорите об Y.

<n00b> Как получить echo трёх последних символов в имени файла?

<feline> Если они в переменной: echo ${foo: -3}

<feline> Почему 3 символа? Что тебе нужно НА САМОМ ДЕЛЕ? <feline> Ты хочешь получить расширение?

<n00b> Да.

<feline> Нет никаких гарантий, что все файлы имеют трёхбуквенные расширения,

<feline> поэтому получение трёх символов не решит проблему. <feline> echo ${foo##*.}

xyproblem.info

Спросите у бизнеса, что ему не нравится


Коммуникация — важнейший инструмент хорошего разработчика. Делайте упор на то, чего бизнес не хочет. По ссылке, которую я указал ниже, Адам Ральф говорит о том, как задавать такие вопросы.

Компании не знают, чего хотят, зато знают, чего не хотят.

— Адам Ральф

Такое случалось со мной очень часто. Думаю, это относится и к вам. Вы можете обнаружить больше скрытых потоков, задаваясь вопросом, чего вы не хотите. Это приводит к формулированию более широких и чётких границ задачи.

Это — ваша ответственность. Задавая такие вопросы, вы будете совершенствоваться как разработчик. Чтобы быть специалистом в определении потребностей бизнеса, нужно достаточно хорошо знать язык неспециалистов.

Вам нужно спрашивать, что им нужно, а не что они хотят.

Почему стоит говорить о решении Z?


Один из подходов к решению этой проблемы заключается в обсуждении других решений. Почему вы их исключили? Какими будут последствия использования решения Z?

Так вы получите лучшее представление о своей проблеме, что приведёт вас к истинной проблеме X. Добавляя по пять копеек к каждому возможному решению, вы сделаете хороший вклад в разрешение основной проблемы.

Если вы не будете хорошо коммуницировать, от этого пострадает проект.

Как проанализировать проблемную область при помощи глупых вопросов


Организациям туго даётся моделирование проблемных областей. Вам нужно задавать вопросы, наводящие на размышления.

В своём докладе Адам спрашивает, влияет ли имя (first name) клиента (допустим, начинающееся на Ms) на его социальный статус (status), что вызывает лавину ответов. Он использует эти ответы для моделирования проблемных областей, состоящих из трёх частей.


Глупый вопрос, правда? Но он приводит к важным объяснениям и моделированию проблемной области. Так мы раскладывает проблемную область на несколько частей, раскрывающих поведение клиентов и продуктов.

Применение сценариев и поведений — отличный способ моделирования проблемных областей. Определение взаимосвязей сущностей разрешает проблему XY.

Попытки решений могут совершаться специалистами в конкретной области. Но на самом деле они не знают подробностей всей системы.

Глубинное понимание проблемных областей приводит к новым решениям. По сути, это разрешает проблему XY.





На правах рекламы


Многие клиенты уже оценили преимущества эпичных серверов от Вдсины.
Это недорогие VDS с процессорами AMD EPYC, частота ядра CPU до 3.4 GHz. Максимальная конфигурация позволит реализовать практически любую идею — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe. Закажите и вы!

VDSina.ru
Серверы в Москве и Амстердаме

Комментарии 7

    +4
    получение трёх символов не решит проблему. <feline> echo ${foo##*.}
    /дотошка моде: on

    Строго говоря, это буллшыт. :)
    Начнём с того, что расширения у файла может не быть вовсе. И такая конструкция вернёт всё имя. Продолжим тем, что файл может быть вместе с путём и точка может быть в названии одной из директорий и такой код порежет путь с именем файла на невообразимое нечто.
    Ну и на сладкое, в unix, а данная команда из unix-shell, есть ещё скрытые файлы, которые начинаются с точки. Я не припомню каких-либо надёжных соображений насчёт того, стоит ли считать .htaccess скрытым файлом с именем htaccess или файлом без имени, но с расширением .htaccess. Т.е. этот вопрос может оказаться дискуссионным. Тут ведь даже не вопрос реализации функций в тех или иных библиотеках или языках, а в том, что нужно пользователю. Т.е. как раз суть X.

    Таким образом, в примере «вместо X мы ищем неправильный Y» мы имеем в качестве правильного ответа на X — заведомо не правильный код, фактически тот же Y. Простите, но я тут поделил на ноль. :)
      0
      Ахиллес никогда не догонит черепаху
        0
        или файлом без имени, но с расширением
        Так ведь из самого термина «расширение» очевидно, что оно расширяет имя. Соответственно, из этого можно сделать вывод, что файла без имени, но с расширением, существовать не может.
          0
          Так же, если обратиться к классической документации, то «These are files that have a name starting with a dot.» т.е. имя начинается с точки. Однако, скорее всего (но это не точно) библиотечные функции, разбирающие путь и имя файла на составляющие с такой трактовкой не согласятся.
          Но это именно то, о чём я говорил: Пошла дискуссия. :)
        +1

        Бывает и так: мы лучше знаем, что тебе нужно, и с удовольствием ответим на вопросы, которые ты не задавал.

          0

          На SO это явление давно уже превратилась в доминанту. Ты спрашиваешь про какой-то сложный и непонятный X, а я знаю только Y, поэтому давай-ка я накатаю ответ "почему тебе на самом деле нужен Y, когда ты спрашиваешь про X".

          0
          Очень важная и интересная тема. Был бы рад если автор раскрыл ее подробнее. Свои замечания по данной теме:
          — У пользователе нет смысла спрашивать что ему нужно, получишь «вагон и маленькую тележку хотелок». Имеет смысл спрашивать какую проблему он решает таким способом (вопрос об опыте в открытой форме). С какими проблемами сталкивается в процессе, как их преодолевает.
          — Как часто он сталкивается с этой проблемой (вопрос об актуальности проблемы и приоритетах решения). Если проблема регулярная, возможно имеет смысл автоматизировать ее решение, если раз в год возможно проблема частная и достаточно просто результата решения, а не автоматизации.
          — Какой результат пользователь ожидает получить от решения проблемы (открытый вопрос о решении) и для чего он ему нужен (открытый вопрос о итоговом результате). Очень часто оказывается что и та версия XY проблемы лишь частный случай проблемы AB уровня выше и не одну из проблем XY решать не надо

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое