Что будешь делать если аналитик пришлет некорректное тз?

Мои действия при получении некорректного ТЗ от аналитика

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

1. Структурный анализ и фиксация неясностей

Я не начинаю с претензий. Вместо этого я тщательно изучаю документ, чтобы конкретизировать проблему. «Некорректность» может проявляться по-разному:

• Противоречивые требования (в одном месте указано "загрузка по кнопке", в другом — "автоматическая").
• Отсутствие ключевых сценариев (нет описания поведения при ошибках или пустых состояниях).
• Техническая нереализуемость (требование, противоречащее возможностям браузера или архитектуре проекта).
• Неясные формулировки ("удобный интерфейс", "быстрая загрузка" без конкретных метрик).

Я выделяю все такие моменты, нумерую их и, по возможности, сразу предлагаю варианты решений. Это смещает фокус с поиска виноватых на совместное решение проблемы.

2. Инициирование диалога, а не переписки

Ключевое правило: обсуждать сложные вопросы лучше синхронно. Я напишу аналитику краткое сообщение в корпоративный чат, например:

Привет! Получил ТЗ для виджета N. Спасибо! Чтобы избежать недопонимания на этапе реализации, давай созвонимся на 15 минут?
Есть несколько важных моментов для уточнения (логика валидации, обработка крайних случаев). Звонок поможет быстрее все согласовать.

После этого я готовлюсь к встрече: открываю ТЗ, свои заметки и, если есть, набрасываю простые примеры кода или схемы.

3. Конструктивное обсуждение на встрече

Цель встречи — не указать на ошибку, а достичь общего понимания. Я использую технику «Уточняю для себя»:

• «Правильно ли я понимаю, что здесь пользователь должен...?»
• «Давай проверим крайний случай: если API вернет ошибку, мы показываем тост или блокируем всю форму?»
• «Требование X с точки зрения браузера может привести к проблеме с производительностью. Предлагаю рассмотреть альтернативу Y, которая даст тот же результат для пользователя».

Часто в процессе такого диалога выясняется, что у аналитика уже есть ответы или допущения, которые просто не попали в документ, либо открываются новые бизнес-ограничения.

4. Фиксация договоренностей и обновление ТЗ

После встречи я обязательно фиксирую результат. В зависимости от процессов в команде, это может быть:

• Комментарий в задаче в Jira/YouTrack с кратким резюме: "По итогам обсуждения с [Имя аналитика] принято: 1) ... 2) ...".
• Прямое внесение правок в ТЗ (если есть доступ) с отправкой аналитику на подтверждение.
• Отправка краткого письма-резюме участникам обсуждения.

Это создает историю изменений и защищает всех от "а я думал, что мы договорились иначе".

5. Проактивное улучшение процессов

Если ситуация повторяется, я перехожу на системный уровень. На ретроспективе команды я могу поднять вопрос, не как жалобу, а как предложение по улучшению:

• «Ребята, давайте внесем в наш шаблон ТЗ обязательный раздел "Обработка ошибок и пограничные состояния"».
• «Предлагаю перед стартом сложных задач делать короткий (15 мин.) калибрующий созвон всей командой (аналитик, разработчик, тестировщик) для быстрого снятия неясностей».

Пример из практики: Как-то раз мне прислали ТЗ, где требовалось реализовать "перетаскивание файлов в любую часть страницы". На первый взгляд, это некорректно с UX-точки зрения. Вместо отказа я подготовил варианты:

1. Реализация как в ТЗ (с объяснением риска случайных срабатываний).
2. Выделенная зона дропа.
3. Гибридный вариант: подсветка всей страницы при начале перетаскивания файла в браузере.

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

Итог: Моя главная задача — не просто написать код по документу, а реализовать корректную и ценную для бизнеса и пользователя функциональность. Некорректное ТЗ — это точка роста для коммуникации и процессов команды. Подход, основанный на уважении, диалоге и документировании решений, почти всегда позволяет быстро устранить неясности и двигаться дальше эффективно.