В целом по вопросу адаптации к любому новому проекту и в любой роли - я мог бы порекомендовать прочитать книгу “Первые 90 дней”. Она изначально для менеджеров, но аналогии проводить не так сложно.

Для всех этапов знакомства с системой, рекомендую вести заметки, так как эти списки будут сильно расти вглубь.

В целом это всё сугубо личное мнение о том, как идеально вкатываться в проект, если вы заинтерсованы в этом и планируете в этом проекте долго вариться.

Наладить технические детали работы

  1. Получить права доступа к коду и самой системе, где это возможно.
  2. Развернуть разрабатываемую систему локально.
  3. Добиться запуска автотестов, если они есть.
  4. Убедиться в нормальной работе дебаггера в тестах, найти возможность сопоставлять выполняющийся код приложения с SQL-запросами, которые он генерирует, чтобы не тыкаться как слепой котёнок.
  5. Найти тесно связанные с проектом компоненты, за которые вы не отвечаете напрямую, но которые влияют на проект. Для бэкендеров это, как правило, фронтенды и смежные бэкенды. Разобраться с надсистемами, то есть системами, в которые ваша система входит, как компонент.
  6. Познакомиться с данными. Получить доступ хотя бы к тестовым слоям, подцепиться к локальной базе, зацепиться дебаггером в процессе прогона тестов и посмотреть что появляется в БД. Хорошо понимать объёмы данных и потоков данных на проде, без этого невозможно принимать правильные решения по индексации и кэшированию.
  7. Познакомиться с пользовательским интерфейсом. Потыкать ручками админку, походить под тестовым пользователем, найти изменяемые в базе данные, в целом познакомиться, хотя бы с основными пользовательскими сценариями.
  8. Разобраться в том, как устроено развёртывание системы в тестовые слои и продакшн, генерация документации. Здесь можно позволить себе немного прокрастинации и поделать систему лучше - ускорить сборку, обновить инструменты, почистить зависимости, актуализировать всевозможные README, пока информация в голове свежа. Сюда же входит и работа с ветками.
  9. Разобраться с инфраструктурой сопровождения: найти логи, сбор ошибок, мониторинг, механизм сбора метрик и их охват. Поверхностно оценить их зрелость, достаточность и необходимость информации и объём работы по наведению порядка.
  10. Освоиться с ранее незнакомыми технологиями, используемыми в проекте. Пощупать фреймворки, ORM, систему разбора и валидации входных и выходных данных. Пару вечеров потыкать какой-нибудь пет-проект на их основе, чтобы они появились на кончиках пальцев.
  11. К этому времени архитектура системы должна стать понятной. Если этого не случилось - приложите целенаправленные усилия по систематизации полученных знаний.
  12. Если система большая. Составить более подробный план знакомства. Можно взять предыдущие пункты и применять их для каждого компонента большой системы по отдельности, отмечая те, в которых вы разобрались, а какие пока остаются терра-инкогнита. Иногда необязательно полностью понимать устройство системы, чтобы начать приносить пользу.

Наладить организационные детали работы

  1. Найти людей, отвечающих за остальные части системы. Понять как добиваться от них нужных вам действий - прямые поручения, промежуточные менеджеры и т.д.
  2. Найти людей, у которых можно вытягивать информацию об устройстве той части системы, которую вы сопровождаете. Оговорите как долго планируете этим заниматься до выхода на полностью самостоятельную работу, возможно, стоит составить совместный план, если человек заинтересован в передаче своего контекста (см. если система большая).
  3. Найти людей, отвечающих за процессы, кроме непосредственной разработки - тестирование, стратегия развития, постановка задач, взаимодействие с другими командами. Можно найти на их месте себя.
    1. Самое важное здесь - понять стратегию развития, чтобы не начать инициативно двигаться в противоположном направлении.
    2. Бывает так, что стратегии развития нет. Что оно не планируется. Что систему надо просто сохранить в том виде, в каком она есть.
    3. Стоит отдельно оценить их степень заинтересованности в развитии проекта. Будучи рядовым сотрудником, проявлять заинтересованность более 95 перцентиля большого смысла нет, лучше в свободное время потрогать траву или прибраться на кухне, противное лишь приведёт к выгоранию и пассивной агрессии.
  4. Оценить объёмы коммуникации, которые требует сопровождение системы. Как часто и от кого возникают вопросы, насколько они однообразны, может ли в этом помочь документация и, если да, почему она не работает. Может быть её нет. Может автогенерируемой документации недостаточно. Стоит отдельно оценивать внешние и внутренние потоки объёмы коммуникации, так как у них разные причины и разные проблемы.
  5. Оценить критичность системы. Нужно понимать какова цена ошибки, чтобы принимать решения о срезании углов ради большей скорости, простоты и так далее. Что произойдёт при выходе системы из строя. Можно ли сгладить это?
  6. Понять, кто является потребителем системы, это поможет замечать несоответствия в требованиях.

Просто начните работать

  1. Просто начните делать какую-то рутину и постепенно пробелы в знаниях начнут закрываться.
  2. По ходу дела записывайте обнаруженные недочёты, но не бросайтесь их сразу исправлять и даже записывать куда-либо кроме личных заметок. Через месяц знакомства с системой половина недочётов отпадёт, треть окажется некритичной. За оставшуюся 1/6 можно будет взяться.
  3. Где-то через 2-3 месяца плотной работы над проектом уже должно появиться видение списка хотелок и болей, которые хотелось бы закрыть, причём в отсортированном виде. Его стоит обсуждать со стейкхолдерами, приходить к какому-то общему видению, предварительно обдумав и причесав. Среди всего этого можно выделить какую-то топ-1 хотелку/боль, после закрытия которой можно будет считать, что ваше вкатывание в проект имело смысл.