Как уточняешь непонятные задачи?

Мой подход к уточнению задач: системность и проактивность

В 10+ лет фронтенд-разработки я выработал строгий протокол уточнения задач, который минимизирует риски недопонимания и повторной работы. Неясная задача — не проблема, а нормальная часть процесса; проблема — это не уточнить её вовремя.

Шаг 1: Анализ и документация вопроса

Я никогда не задаю вопрос "что вы имели в виду?" без предварительной работы. Сначала я сам анализирую задачу:

## Контекст задачи:
- **Цель бизнеса:** Какая метрика улучшается? (конверсия, скорость, retention)
- **Пользовательская проблема:** Какую боль решаем для юзера?
- **Существующее решение:** Что сейчас не так?
- **Непонятные места:** Конкретные пункты, требующие уточнения

Шаг 2: Формулировка гипотез и вариантов

Перед обращением к stakeholders я готовлю альтернативные варианты реализации:

// Пример: "Непонятная задача: улучшить загрузку изображений"

// Вариант А: Lazy loading + WebP конвертация
const optionA = {
  effort: '2 дня',
  impact: '40% улучшение LCP',
  risks: ['Старые браузеры', 'Серверная нагрузка']
};

// Вариант Б: CDN + responsive images
const optionB = {
  effort: '5 дней', 
  impact: '60% улучшение LCP',
  risks: ['Стоимость CDN', 'Миграция']
};

Шаг 3: Структурированное обсуждение с правильными людьми

Я определяю, кого именно нужно привлекать:

• Продуктолог/владелец продукта — для бизнес-целей и приоритетов
• Дизайнер — для UX-нюансов и edge cases
• Бэкенд-разработчик — для API контрактов и ограничений
• Другие фронтендеры — для consistency в кодовой базе

Конкретные техники вопросов

Техника "Пример-Контрпример"

**Непонятное:** "Кнопка должна быть более заметной"
**Уточнение:**
✓ Пример: "Как кнопка 'Купить' на главной странице Apple.com?"
✗ Контрпример: "Не как красная кнопка в нашем старом админ-интерфейсе?"

Метод "5 почему" для глубины

1. "Почему нужно изменить навигацию?" → Уменьшить количество кликов
2. "Почему важно уменьшить клики?" → Увеличить конверсию в заказ
3. "Почему конверсия низкая?" → Пользователи теряются в меню
4. "Почему теряются?" → Слишком много nested пунктов
5. "Почему так сделано?" → Исторические причины, нет исследований

Шаг 4: Документирование договорённостей

После уточнения я сразу фиксирую решение в формате ADR (Architecture Decision Record):

## ADR: Реализация lazy loading для галереи
**Дата:** 2024-01-15  
**Статус:** Принято  
**Участники:** @product, @design, @frontend-team

**Решение:** Используем вариант Б (CDN + responsive images)  
**Причины:**
1. Лучшее долгосрочное масштабирование
2. Готовое решение для мобильных устройств
3. Совместимость с нашим tech stack

**Acceptance Criteria:**
- [ ] LCP < 2.5s на 3G
- [ ] Поддержка Safari 14+
- [ ] Fallback для отключённого JavaScript

Инструменты и привычки

Живая документация:

• Комментарии в коде с ссылками на тикеты
• Storybook для компонентов с use cases
• Коммиты с понятными сообщениями: feat(gallery): add lazy loading with CDN support (#123)

Регулярные checkpoints:

• Демонстрация промежуточного результата каждые 2-3 дня
• Валидация с дизайнером на ранних этапах
• Проверка acceptance criteria перед код-ревью

Работа с ambiguity в Agile

В условиях неопределённости я применяю spike solutions — прототипы для исследования:

// Файл: `spike-image-optimization.md`
## Цель спайка: определить оптимальный подход
## Ограничение времени: 4 часа
## Выходные данные:
1. Benchmark 3 вариантов на lighthouse
2. Оценка сложности реализации  
3. Рекомендация для команды

Эскалация сложных случаев

Если после всех уточнений остаются фундаментальные противоречия:

1. Создаю decision matrix с критериями (стоимость, время, качество)
2. Организую встречу с техлидом и проджектом
3. Предлагаю A/B тест или поэтапный rollout для рискованных изменений

Ключевой принцип: задача считается уточнённой, когда я могу объяснить её другому разработчику, перечислить acceptance criteria и оценить сроки с погрешностью ±20%. Стоимость уточнения на раннем этапе в десятки раз ниже стоимости переделки работающего кода.