Первые три месяца на новой работе задают репутацию надолго. Без рамки легко уйти в две крайности: три недели читать вики без артефакта или тащить огромную фичу и сгореть на ревью. План 30/60/90 нужен, чтобы двигаться от «разобраться» к «вносить вклад» и к «владеть куском» — особенно на удалёнке, где никто не подсядет объяснить между делом.
Ниже — что класть в каждый отрезок, заполненный пример для junior backend и как сверяться с менеджером, чтобы план не стал декоративным файлом в Notion.
Коротко:
- 30 дней: продукт, люди, запуск, первый PR, записанные критерии срока.
- 60 дней: задача среднего размера до прода, участие в ревью, меньше сюрпризов на 1:1.
- 90 дней: зона ответственности, измеримый результат, фидбэк и курс дальше.
- План согласуют с менеджером на первой неделе и сверяют, не «напишу себе красиво».
- На удалёнке в план явно входят видимость статуса и эскалация блокеров.
Зачем план, а не «просто работать»
Работа сама по себе не складывается в историю для испытательного срока. Складываются контрольные точки: что умеете запустить, что влили, чем владеете. План — это договорённость, что считать прогрессом. Без неё менеджер в голове держит одну картинку, вы — другую.
Документ короткий: одна страница на отрезок или одна таблица в заметках. Не стратегия на год. Детали первой недели вынесены отдельно в план первой недели; 30/60/90 — зум-аут. Как разговор про критерии вести — в материале про испытательный срок.
Первые 30 дней: разобраться
Цель отрезка — перестать быть туристом в репозитории и процессе.
- Продукт: какой пользовательский сценарий кормит ваш сервис, какие статусы и ошибки вам нельзя ломать.
- Команда: кто менеджер, ментор, соседи, куда писать инцидент.
- Процесс: доска, ревью, релиз, дежурство — хотя бы как наблюдатель плюс один проход руками.
- Запуск: локально или честно на стенде, с записанными дырами инструкции.
- Вклад: маленький PR по конвенциям. Как его собрать — в гайде про первый pull request.
- Критерии срока: черновик подтверждён менеджером.
Вопросы в этот месяц — норма. Молчание «пока всё не пойму» — нет. Карта кода строится срезами, не энциклопедией: как разобраться в чужой кодовой базе.
60 дней: вносить вклад
К середине срока вы уже не только чините опечатки. Берёте задачу, у которой есть продуктовый смысл и несколько файлов, и доводите до прода без того, чтобы ментор сидел в паре на каждом шаге.
- Оценка: умеете назвать риски и зависимости («нужен контракт с платежами», «нужен флаг»).
- Ревью: не только получаете комментарии, но и смотрите чужие PR своего контура — хотя бы на очевидные дыры.
- Негласные правила: когда писать в канал, когда тикет, что считается «готово к QA».
- Коммуникация: соседние роли узнают о вашем изменении до сюрприза на стенде.
Если к 60 дням вы всё ещё только «изучаете» — это уже тема 1:1, не повод ещё почитать. Либо задач не дают (эскалация), либо вы сами не берёте (поведение).
90 дней: владеть
К концу испытательного команда должна понимать, с чем идти к вам, а не «к любому, кто свободен».
- Кусок продукта или сервиса: ручки, воркер, админка, пайплайн — названный контур.
- Измеримый результат: меньше падений на известном сценарии, закрытый долг, быстрее разбор, стабильный релиз куска. Цифра из мониторинга лучше эпитета «улучшил».
- Фидбэк собран заранее, не в последний четверг срока.
- Следующие три месяца понятны: что углублять, чего не брать.
«Владеть» не значит «никто больше не смеет трогать». Значит, вы знаете инварианты, дежурите по куску без паники и можете объяснить новичку вход.
Заполненный план: junior backend, сервис заказов
Контекст: удалёнка, русскоязычная команда, испытательный срок около трёх месяцев, стек привычный, домен новый. Это образец, не норматив всех компаний — подставьте свои сервисы и даты.
Дни 1–30. Разобраться
Продукт: пройти сценарий «гость → заказ → оплата → статус в кабинете». Записать статусы заказа и кто их меняет (ручка vs воркер платежей).
Запуск: orders-api поднимается командами из Makefile. Дыры README — отдельный PR.
Люди: менеджер Анна, ментор Марина (домен заказов), Илья (платежи), канал #orders.
Вклад: влить фикс пустого списка заказов (не 500, а пустой массив) плюс тест. Второй PR — правка migrate в README, если ещё живо.
Процесс: один полный путь задачи от доски до релиза как наблюдатель; свои PR — как автор.
Сверка: 1:1 каждую неделю. К дню 30 Анна письменно подтверждает: «первый мёрж + карта сервиса = нормальный темп».
Риски: доступы к staging. Если нет к дню 5 — эскалация, не «работаю вслепую».
Дни 31–60. Вносить вклад
Задача среднего размера: ручка повторной отправки чека / идемпотентность создания заказа — что даст продукт. Оценка с Мариной, зависимости с Ильёй записаны в тикете до кодирования.
Довести до прода с флагом или без — как принято. Самим пройти QA-чеклист команды, не «ну там посмотрите».
Ревью: смотреть все PR в orders-api, которые касаются статусов. Писать по делу, не «lgtm» без открытия diff.
Дежурство: один слот в паре с Мариной, без права быть единственным дежурным.
Сверка на дне 45: если средний тикет буксует — дробим, не геройствуем. К дню 60 в проде должен быть ваш контурный кусок, не только мелкие фиксы.
Дни 61–90. Владеть
Зона: HTTP-слой orders-api и запись статусов created/paid/failed. Воркеры платежей — совместно с Ильёй, не единолично.
Результат: закрыть два известных класса ошибок пустого списка и таймаута на чтение заказа; добавить алерт, если команда так делает, или хотя бы ручной чеклист дежурства по этим ручкам.
Онбординг: короткая шпаргалка для следующего новичка — входы, команды, кого звать. Это проверка, что вы владеете, а не только «помните в голове».
Фидбэк: встреча с Анной и Мариной в районе дня 75, не 89. Вопросы: что усилить, что не брать, есть ли продление зоны.
Дальше: либо углубление идемпотентности заказов, либо следующий соседний кусок — решение за менеджером, не за вашим FOMO.
Как сверяться с менеджером
План без сверки — дневник. На 1:1 приносите три строки: сделано по плану, сдвиг, вопрос. Раз в месяц обновляйте сам документ: что вычеркнули, что добавили. Если менеджер говорит «не надо бюрократии» — оставьте ещё короче, но критерии срока всё равно письменно.
Не подгоняйте факты под красивую схему. Если 30 дней съели доступы — так и напишите, сдвиньте «средний тикет», попросите помощь. Скрытый сдвиг вскрывается на дне 80 и выглядит хуже.