Как происходит ревью технического задания и разбор задач

Что проверяют

Умеете ли вы превратить текст аналитика или заказчика в задачи, которые можно сделать, проверить и оценить, и замечаете ли дыры до того, как написан код. Следом обычно спрашивают: что вы делаете, если ТЗ неполное, а сроки уже названы.

Как отвечать

Опишите процесс вашей команды на реальном примере, по шагам:

• чтение с вопросами: проходите ТЗ и фиксируете всё неоднозначное прямо в комментариях к задаче или документу, а не в личке. Типовые дыры: что делать при ошибке внешнего сервиса, у кого какие права, какие данные уже есть в базе;
• нефункциональные требования: объём данных, ожидаемая нагрузка, допустимое время ответа, логи и аудит. Для Python-сервиса отсюда следует выбор между синхронным кодом и asyncio, между фоновой задачей в Celery и обработкой прямо в запросе;
• контракт: до реализации согласуете схему API. В FastAPI её удобно описать моделями Pydantic и показать фронтенду и тестировщикам готовый OpenAPI;
• изменения в данных: какие таблицы и миграции Alembic понадобятся, нужна ли совместимость со старой версией сервиса;
• декомпозиция: режете на задачи размером в один или два дня, у каждой понятный критерий готовности. Непонятную часть выносите в отдельный спайк с ограничением по времени;
• оценка и фиксация: на груминге команда оценивает задачи, спорные решения записываются в задачу или в короткий ADR.

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

Где спотыкаются

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

Путают ревью ТЗ с код-ревью и переходят к рассказу о пулреквестах.

Не упоминают нефункциональные требования и критерии приёмки. Потом выясняется, что задача «готова», но тестировщик и заказчик понимали её по-разному.