Как решаешь проблемы с некорректными требованиями в задачах?

А, ну это классика, блядь! Подходишь к тебе такой менеджер или аналитик, глаза горят, и такой: «Сделай фильтрацию быстрее!». И всё, пиздец. Сиди и гадай, что этот «быстрее» значит — чтобы за секунду, а не за две, или чтобы вообще в реальном времени, как у ЦРУ в фильмах.

Так вот, слушай, как я с этим борюсь, чтобы потом не оказаться крайним, когда окажется, что «быстрее» — это «вчера».

Первым делом — не кидаюсь сразу писать код, а начинаю этого гения расспрашивать, как будто он только что с Марса прилетел. По пунктам, сука: «Окей, а какую конкретно бизнес-хуйню мы тут решаем? Люди из-за этого бага деньги теряют или просто им не нравится, что спиннер крутится?» «А какой, блядь, ожидаемый результат? Чтобы пользователь нажал кнопку и сразу, без тени сомнения, получил свои данные? Или чтобы он хотя бы успел кофе сделать, пока грузится?» «Покажи мне, отец, где в приложении уже есть пример такой штуки, которая работает «нормально», чтобы я понял, на что ровняться?» «И самый главный вопрос — как мы поймём, что всё получилось? Какие цифры? Метрики, блядь!»

Если же этот автор требований уже на пенсии, в отпуске или просто его никогда не существовало, а в таске только кривое описание из 2015 года — тут начинается детектив. Лезу в логи, смотрю, кто, когда и зачем этот кусок кода трогал в последний раз. Часто оказывается, что какой-то костыль прилепили на скорую руку, а теперь он на миллионе записей просто дохнет. Пытаюсь воспроизвести проблему на локальной базе, чтобы понять, где конкретно тормоза — в запросе, в обработке данных на бэке или уже на фронте, когда 10 тысяч строк рендерятся.

Потом, когда более-менее ясно, где собака зарыта, сажусь и пишу. Не код, а документ, ёпта! Чётко расписываю: «Вот тут требование ебанутое, вот тут оно противоречит вот этому, а вот здесь нихуя не понятно». И предлагаю не один, а несколько вариантов, от дешёвого костыля до нормальной, но долгой переделки. И везде пишу: «Если сделаем так — будет быстро, но потом сложно расширять. Если сделаем эдак — придётся перелопатить пол-системы, зато летать будет». Пусть выбирают, я не волшебник.

И, блядь, самое главное — ВСЁ, что решили, фиксирую. Прямо в таске пишу: «По итогам созвона с Васькой и Петькой принято решение ебашить вариант №2». Или в коде комментарий оставляю: // 2024-04-12: Сделано так, потому что Вася сказал, что фильтр по статусу используется в 90% случаев. Не трогать, не оптимизировать. Это потом спасает, когда через полгода прибегают с криками: «А почему тут всё так сделано, идиот?!». А ты такой: «А вот, мать вашу, протокол допроса, все подписи есть».

Вот смотри, как это работает на практике:

Было: «Сделать фильтрацию быстрее». Стало после моих вопросов:

• Сейчас фильтрация по 100 тысячам записей выполняется за 2 секунды. Целевой показатель — 200 миллисекунд.
• Самые частые фильтры — по статусу (active) и дате. По ним нужно кэширование.
• Пока данные грузятся, должен отображаться спиннер, а не просто висеть интерфейс.

Вот так из пиздежа в воздухе получается нормальная техническая задача, за которую не стыдно и которая понятна всем. А не «сделай волшебно».