Кто занимается сбором требований, написанием технических заданий и управлением фичами
Что проверяют
Как устроен путь от идеи до задачи в ваших командах и где в нём разработчик. Интервьюеру важно, работаете ли вы только по готовым ТЗ или умеете сами уточнять требования и спорить о них. Нередко этот вопрос задаёт и кандидат, чтобы понять, придётся ли самому вытаскивать требования из бизнеса.
Как отвечать
Опишите, как было у вас и где вы вмешивались:
- продакт или владелец продукта: решает, что делать и в каком порядке, ведёт бэклог и приоритеты;
- системный или бизнес-аналитик: собирает требования у заказчиков, пишет спецификацию, сценарии и ограничения;
- разработчик: проверяет требования на реализуемость, добавляет техническую часть и оценивает задачу.
Для Go-разработчика техническая часть требований обычно выглядит так:
- контракт: схема OpenAPI для HTTP или
.protoдля gRPC, согласованная с потребителями до начала работы; - нефункциональные требования: ожидаемый RPS, допустимая задержка по p99, поведение при недоступности зависимостей, таймауты и ретраи;
- данные: миграции схемы, объём, нужна ли очередь;
- выкатка: фича за флагом, чтобы включать её частями и выключать без релиза.
Хороший пример: аналитик принёс «нужен экспорт отчётов», вы уточнили объём и выяснили, что синхронная ручка упрётся в таймаут балансировщика, поэтому сделали асинхронную задачу с очередью и статусом.
Если аналитика не было и требования приходили сообщением в мессенджере, так и скажите, и расскажите, как сами доводили их до задачи с критериями приёмки.
Задавая этот вопрос работодателю, уточните, кто решает, что фича готова, и можно ли вернуть задачу с непонятными требованиями.
Где спотыкаются
Говорят «мне дают ТЗ, я делаю». Это звучит как позиция исполнителя без влияния на результат.
Забывают про нефункциональные требования. Без цифр по нагрузке и задержкам спецификация для бэкенда неполная.
Путают управление фичами как процесс приоритизации с feature flags как техническим механизмом и отвечают про одно, когда спрашивают про другое.