Тебе нужно разобраться в legacy-системе без доки, чтобы описать текущие процессы. С чего начнешь и какие источники информации используешь?

Бояться сильно таких вопросов не надо. Никто не ждет, что вы за 5 минут поймете систему, которой 15 лет 🤦‍♀️

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

1. Сначала понять цель Первая ошибка – пытаться разобрать сразу все. Это невозможно и не нужно. Правильный подход – начать задавать вопросы:

• зачем вообще нужно описание? • для замены, оптимизации или просто чтобы понять, что там происходит? • какие процессы самые болезненные?

Даже одно уточнение сильно сужает объем работы 💯

2. Определить границы На собесе можно прямо сказать: «Я бы начал с самого критичного процесса, а не со всей системы сразу».

Legacy – это иногда свалка функций, костыли и мертвые фичи. Поэтому: • фиксируем ключевые бизнес-процессы (например, через интервью) • определяем, какие роли и пользователи реально работают с системой • выбираем 1–2 процесса для старта, а не все подряд

3. Источники информации Документации нет, но следы остаются всегда. И вот, где их можно искать:

1. Пользователи системы Это те, кто работает с системой каждый день. Спрашиваем у них: что делают чаще всего, где система тормозит, какие шаги выполняют уже на автомате. 2. Бизнес и владельцы процессов У них узнаем: зачем вообще нужен процесс, какие этапы важны для бизнеса, а какие просто исторически сложились. 3. Система как есть Смотрим на данные: куда пишутся логи ошибок, какие таблицы самые большие и какие чаще обновляются, на какие внешние сервисы система ходит.

Если есть доступ к интерфейсу, логам, тестовому стенду, API - изучаем. Даже без кода можно понять логику.

4. Разработчики (если остались) Спрашиваем, куда лучше не лезть и что точно нельзя трогать без последствий.

4. Как начать описывать Не с идеальной BPMN, а с простого: • черновая схема процесса • список шагов «как сейчас» с пометками: «из слов пользователя», «предположение», «нужно уточнить» • фиксация вопросов и серых зон

Только потом переходим к уточнению: схемам данных (ER-диаграммам), юз-кейсам и т.д.

🟢Главное - показать что ты идешь поэтапно: • Сначала разбираешь ключевой процесс, а не все сразу • Начинаешь с самого критичного (потому что времени и ресурсов всегда не хватает) • Понимаешь, что без разговора с пользователями и изучения логов точно не скажешь, сколько времени займет работа • Видишь не только текущее состояние (AS‑IS), но и точки, для улучшения в будущем

На собесе ждут, что ты сможешь разложить задачу на шаги и оставить после себя понятную картину, с которой дальше сможет работать команда 🧊