Как происходит ревью аналитики
Что проверяют
Под ревью аналитики в продуктовой разработке почти всегда понимают проверку постановки от системного аналитика до того, как задача уходит в разработку. Интервьюер хочет понять, читаете ли вы требования критически или начинаете кодить по тому, что дали. Следом часто просят пример дыры в требованиях, которую вы нашли.
Как отвечать
Опишите, как это устроено у вас:
- артефакт: спецификация в Confluence или в самой задаче: сценарии, модель данных, контракт API в OpenAPI, диаграммы последовательностей, маппинг полей для интеграций;
- участники: разработчики, часто техлид и QA. Формат «трёх друзей» (аналитик, разработчик, тестировщик) хорошо ловит пробелы, потому что каждый смотрит со своей стороны;
- формат: комментарии в Confluence или встреча на груминге. В Jira бывает отдельный статус вроде «Ревью аналитики», и в разработку задача переходит только после него, это часть Definition of Ready.
Дальше перечислите, что вы проверяете как Java-разработчик:
- ошибки, а не только успешный сценарий: какой HTTP-статус вернуть при таймауте смежной системы, что делать с повторным запросом, нужна ли идемпотентность;
- данные: откуда берётся каждое поле, типы и обязательность, что станет с существующими строками после новой колонки, нужен ли индекс;
- интеграции: синхронный вызов или событие в Kafka, ретраи, порядок сообщений, кто владелец контракта;
- нефункциональные требования: объём данных, нагрузка, допустимая задержка, аудит и права доступа;
- реализуемость: противоречия с текущей архитектурой и трудоёмкость.
Хорошо, если приведёте пример: на ревью заметили, что не описан сценарий отмены, и сэкономили круг доработок после тестирования.
Где спотыкаются
Путают с ревью аналитических отчётов и рассказывают про дашборды и BI. Если сомневаетесь, о каком ревью речь, уточните у интервьюера.
Проверяют только успешный сценарий. Ошибки и граничные случаи всплывают на тестировании, когда переделывать дороже.
Превращают ревью в переписывание спецификации под свою реализацию. Задача разработчика указать на пробелы и риски, а решение по бизнес-логике остаётся за аналитиком и продактом.