Первые три месяца на новой работе задают репутацию надолго. Без рамки легко уйти в две крайности: три недели читать вики без артефакта или тащить огромную фичу и сгореть на ревью. План 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 и выглядит хуже.

Особенности удалёнки

В план явно входят действия, которые в офисе случаются сами:

  • Ежедневный статус в канале контура, пока вас не знают.
  • Запись договорённостей после созвона: «делаем A, не делаем B».
  • Отдельная строка про пересечение часов с ревьюерами и QA.
  • Блокеры не копятся до синхрона раз в неделю.

Видимость — ваша работа, не работа менеджера «догадаться». Артефакты и статусы заменяют взгляд на монитор.

Что не класть в план

  • Переписать архитектуру сервиса «как надо».
  • Выучить все микросервисы компании.
  • Стать единственным дежурным к дню 40.
  • Оптимизировать производительность без измерения и без запроса.
  • Личные курсы на 10 часов в неделю внутри рабочего плана без согласия менеджера. Учиться можно, маскировать отставание учёбой — нельзя.

План должен быть проверяемым. «Стать лучше» — нет. «Влить фикс + провести средний тикет + закрыть фидбэк к дню 75» — да.

Чек-лист контрольных точек

  • День 5: доступы эскалированы, 1:1 стоит в календаре, черновик 30/60/90 отправлен менеджеру.
  • День 15: первый PR открыт или влит; карта одного пользовательского пути записана.
  • День 30: сверка «темп нормальный / что сдвинуть».
  • День 45: средняя задача в работе, зависимости названы.
  • День 60: кусок в проде, участие в ревью видно по истории.
  • День 75: фидбэк собран.
  • День 90: зона названа, следующий квартал не сюрприз.

Скрипт сверки на день 30

Встреча 25–30 минут. Приносите факты, не ощущения. Цель — услышать «темп нормальный / вот сдвиг», а не «ну, в целом ок».

По плану 30 дней я закрывал: запуск, карту статусов заказа, первый PR (ссылка), правку README, еженедельные 1:1.

Сделано: оба PR влиты, шпаргалка в личной заметке, доступы к staging получили на дне 8 — сдвиг по сравнению с днём 5.

Не сделано: не дежурил даже в паре — слотов не было. Не смотрел PR платежей, только orders-api.

На 60 дней в черновике: идемпотентность создания заказа, ревью чужих PR по статусам, одно дежурство в паре. Что вырезать или заменить, чтобы это осталось реалистичным?

Красные флаги с вашей стороны за этот месяц — какие? Лучше услышать сейчас.

После встречи в тот же день отправьте пять строк в личку: что подтвердили, что сдвинули, какая следующая контрольная дата. Если менеджер отменил 1:1 — не переносите молча на «когда получится». Назначьте новый слот в ту же неделю. План 30/60/90 без этой сверки снова становится дневником.

На дне 30 уже можно сузить зону, если фактов мало: лучше честно владеть HTTP-слоем заказов, чем обещать «весь домен вместе с биллингом» к 90. Сужение, записанное вместе, — зрелость. Сужение втихую в последний месяц — сюрприз. Тот же принцип, что на испытательном сроке вообще: видимость важнее героизма. Если сверка показала, что вас держат без задач — это тоже результат дня 30, и его надо эскалировать, а не маскировать чтением репозитория ещё четыре недели.

Частые вопросы

Нужно ли показывать план всей команде?

Достаточно менеджера и ментора. Команде важнее статусы и PR, чем ваш документ. Исключение — если онбординг в компании и так публичный.

Что, если испытательный срок два месяца, а не три?

Сожмите: 20 / 40 / 60 календарных дней с теми же смыслами «карта — вклад — владение», меньшим объёмом зоны. Не выкидывайте сверки, выкидывайте ширину.

Можно ли менять план каждую неделю?

Да, если меняются факты: релизы, болезни, заморозка фичи. Нет, если вы просто не хотите смотреть на то, что не сделали. Сдвиг с причиной — зрелость. Бесконечный рерайт целей — туман.

Как измерить результат junior, если «просто закрывал тикеты»?

Считайте классы задач: сколько доведено до прода, какие инциденты вы разбирали, какие дыры онбординга закрыли. Даже junior может показать «два продакшен-фикса известного падения + шпаргалка для следующего».

План не сходится, я отстаю. Это провал срока?

Отставание с ранней эскалацией часто лечится сужением зоны. Отставание, вскрытое в конце, — уже риск. Несите факт на 1:1 в момент, когда ещё можно подвинуть объём.

Стоит ли копировать чужой 30/60/90 из блога один в один?

Нет. Этот текст — каркас. Имена сервисов, флаги и ритуал релиза только ваши. Подставьте контур, согласуйте, вычеркните лишнее.

Что сделать сейчас

Сегодня скопируйте заполненный пример junior backend в свою заметку и замените сервис, имена и тикеты на свои. Завтра отправьте черновик менеджеру: «предлагаю такие точки, поправьте». На этой неделе закройте кусок 30 дней — запуск и маленький PR — даже если до «владеть» далеко.

Если вы ещё не вышли на работу, держите шаблон до дня 1. Если оффер в процессе, не размывайте фокус десятью параллельными поисками без системы: сначала как найти работу, живые роли в каталоге, а план 30/60/90 откроете уже в новом календаре.