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

Столкнувшись с некорректными требованиями, действую по следующему алгоритму:

1. Уточнение и диалог: Первым делом обращаюсь к автору требований (аналитик, продакт, заказчик). Задаю конкретные вопросы, чтобы выявить истинную потребность:

   • "Какую бизнес-проблему мы решаем?"
   • "Каков ожидаемый результат для пользователя?"
   • "Есть ли примеры или аналоги в системе?"
   • "Каковы критерии успеха (метрики)?"

2. Анализ и исследование: Если прямой диалог невозможен (legacy-код, устаревшая документация):

   • Изучаю контекст: логи, историю коммитов, связанные модули.
   • Создаю минимальный воспроизводимый пример проблемы.
   • Провожу реверс-инжиниринг существующего поведения.

3. Документирование и предложение решений:

   • Четко фиксирую найденные противоречия и неясности.
   • Предлагаю варианты решений с оценкой рисков и трудозатрат.
   • Обсуждаю варианты с командой и стейкхолдерами.

4. Фиксация решения: Принятое решение обязательно документирую в задаче (Jira, GitHub Issue) или в коде (комментарии). Это создает "историческую справку" и снимает ответственность за догадки.

Пример:

Исходное требование: "Сделать фильтрацию быстрее". Мои уточняющие вопросы:

• Текущая скорость? Целевая скорость? (например, "с 2 сек до 200 мс")
• На каком объеме данных? (100 или 1 млн записей?)
• Какие фильтры самые частые? Нужно ли кэширование?
• Есть ли UX-ограничения (индикатор загрузки)?

Такой подход превращает размытое требование в измеримую техническую задачу.