Как составить 30-60-90 дневный план для IT-специалиста: пошаговый гайд с примерами

# Как составить 30-60-90 дневный план для IT-специалиста: пошаговый гайд с примерами

Почему 30-60-90 дневный план — must-have для IT-рекрутинга

В IT-сфере текучка кадров бьёт рекорды: по данным HeadHunter, 35% новых сотрудников уходят в первые три месяца. При этом средний срок адаптации разработчика в компании — 6-8 месяцев, а стоимость замены одного специалиста достигает 180-250 тыс. рублей. 30-60-90 дневный план решает обе проблемы: ускоряет интеграцию и снижает риск преждевременного увольнения.

В IT-компаниях из нашей практики внедрение такого плана сократило time-to-productivity (время до выхода на полную эффективность) с 4 месяцев до 6 недель. Например, в команде backend-разработчиков одного fintech-стартапа план помог новому сотруднику за 30 дней не только изучить кодовую базу, но и закрыть первый инцидент в продакшене. А в компании с 50 IT-специалистами план для junior-разработчиков снизил количество обращений в поддержку на 40% уже к 60-му дню.

HR-директора часто недооценивают роль такого документа. Между тем, он решает три ключевые задачи:

- Менеджеру — понятные KPI и контроль прогресса

- Сотруднику — ясные ожидания и структура для самообучения

- Команде — прозрачные процессы передачи знаний

[Оставьте заявку](#request), если нужна помощь с настройкой процесса адаптации под вашу IT-команду.

Структура идеального 30-60-90 дневного плана для IT

Стандартный план должен включать три блока: обучение, погружение в процессы и вклад в продукт. Для IT-специалистов добавляются технические чек-листы и менторские сессии. В IT-компании из 30 человек мы внедрили следующий шаблон, который подходит как для junior, так и для senior разработчиков:

В IT-стартапах на seed-раунде мы адаптируем план под ограниченные ресурсы: например, вместо ментора назначаем buddy-систему (наставника из другой команды), а вместо полного курса по продукту — краткий брифинг с ключевыми фичами.

Кейсы: как план работает в разных IT-ролях

Для junior-разработчиков

В одном московском стартапе по автоматизации бизнес-процессов 30-60-90 план для junior-разработчика выглядел так:

- Первые 30 дней: Изучение Python, прохождение курса по внутренним API, написание первого теста. Результат — успешное прохождение code review.

- 60 дней: Выполнение 3 задач по правкам UI, участие в daily stand-up. Результат — положительная обратная связь от тимлида.

- 90 дней: Закрытие первой фичи (например, добавление нового поля в форму), участие в ретроспективе спринта. Результат — повышение зарплаты на 15% по итогам испытательного срока.

Ключевой момент: план должен включать не только технические задачи, но и soft skills — например, участие в митингах или проведение мини-презентации о проделанной работе.

Для тимлидов и менеджеров

В компании с 200 IT-специалистами план для нового тимлида включал:

- 0-30 дней: Аудит текущих процессов, интервью с каждым членом команды, анализ бэклога.

- 31-60 дней: Реструктуризация процессов (например, внедрение Kanban вместо Scrum), проведение 1:1 с каждым сотрудником.

- 61-90 дней: Запуск нового процесса (например, внедрение code review), презентация результатов руководству.

Такой подход помог сократить время на адаптацию тимлида с 6 месяцев до 3, а также снизил текучку в команде на 25% за год.

Для DevOps-инженеров

В fintech-компании план для нового DevOps-специалиста включал:

- Первые 30 дней: Изучение инфраструктуры (Kubernetes, Terraform), настройка CI/CD для одного микросервиса.

- 60 дней: Оптимизация процессов деплоя, написание документации по инфраструктуре.

- 90 дней: Автоматизация рутинных задач (например, мониторинг), участие в планировании релизов.

Результат: сокращение времени деплоя с 2 часов до 15 минут, что напрямую повлияло на бизнес-метрики компании.

Чек-лист: что должно быть в плане для IT-специалиста

Создавая план, учитывайте специфику роли. Для разработчика это:

Технические задачи:

1. Ознакомление с кодовой базой (структура проекта, ключевые модули, стиль кодирования)

2. Настройка локального окружения (Docker, IDE, зависимости)

3. Выполнение первых задач (например, исправление багов или добавление фичи)

4. Участие в code review и написание тестов

5. Изучение системы мониторинга и логирования

Процессы и коммуникации:

1. Знакомство с командой (включая удалённых коллег)

2. Понимание процесса разработки (Agile/Scrum/Kanban)

3. Участие в митингах (daily, планирование, ретроспектива)

4. Взаимодействие с другими командами (например, QA, продуктовая)

5. Ознакомление с внутренними гайдлайнами (например, как писать документацию)

Личное развитие:

1. Обучение новым технологиям (например, переход с Python 2 на 3)

2. Участие в корпоративных тренингах или митапах

3. Получение фидбэка от ментора или тимлида

4. Постановка личных KPI на следующие 3 месяца

5. Анализ прогресса и корректировка плана при необходимости

В IT-компаниях с распределёнными командами важно добавить пункты по удалённой работе: например, как быстро отвечать на сообщения в Slack или как проводить эффективные онлайн-митинги.

Ошибки, которые убивают план адаптации

Даже идеальный план не сработает, если допустить типичные ошибки:

1. Отсутствие менторства

В одной IT-компании из 15 человек новый разработчик не получил наставника и за 3 месяца так и не понял архитектуру проекта. В результате он уволился, а команда потеряла 2 месяца на его замену. Решение: назначайте ментора сразу, даже если это junior-сотрудник с опытом.

2. Перегрузка задачами

В стартапе на seed-раунде новичку поставили 10 задач в первый месяц. В результате он не справился ни с одной, получил стресс и уволился. Решение: начинайте с 3-5 небольших задач, постепенно усложняя нагрузку.

3. Недостаток обратной связи

В компании с 50 IT-специалистами план не включал регулярные 1:1. Новый сотрудник не знал, как оценивается его работа, и через 2 месяца ушёл. Решение: проводите еженедельные митинги с ментором и ежемесячные 1:1 с тимлидом.

4. Игнорирование культуры компании

В международной IT-компании новый сотрудник не был ознакомлен с корпоративными ценностями. Через месяц он не вписался в команду и уволился. Решение: включайте в план знакомство с культурой (например, участие в тимбилдинге или корпоративных мероприятиях).

5. Отсутствие адаптации плана под роль

В одной компании план для DevOps-инженера был идентичен плану для frontend-разработчика. В результате новый сотрудник не получил нужных знаний по инфраструктуре и ушёл. Решение: кастомизируйте план под конкретную роль.

Как внедрить план в компании: пошаговая инструкция

Шаг 1. Создайте шаблон под вашу команду

Начните с базового шаблона, который можно адаптировать под разные роли. В IT-компаниях мы рекомендуем использовать следующий формат:

[Роль] 30-60-90 дневный план

**0-30 дней:**
- [ ] Изучить документацию проекта
- [ ] Настроить локальное окружение
- [ ] Выполнить 1-2 простые задачи под руководством ментора
- [ ] Пройти курс по внутренним процессам

**31-60 дней:**
- [ ] Выполнить 3-5 задач средней сложности
- [ ] Участвовать в code review
- [ ] Провести мини-презентацию о проделанной работе
- [ ] Начать работу над реальной фичей

**61-90 дней:**
- [ ] Закрыть 2-3 задачи наравне с командой
- [ ] Предложить 1-2 улучшения процесса
- [ ] Пройти фидбэк-сессию с тимлидом

Шаг 2. Назначьте ответственных

- Ментор — опытный сотрудник, который будет помогать новичку

- Тимлид — контролирует выполнение плана и даёт обратную связь

- HR — следит за соблюдением процесса адаптации

Шаг 3. Проведите вводную сессию

Организуйте встречу, где объясните:

Шаг 4. Обеспечьте ресурсами

Шаг 5. Контролируйте и корректируйте

В IT-компаниях с гибкими процессами (например, в стартапах) план можно адаптировать под Agile: например, обновлять его каждую неделю на основе новых задач.

Пример: 30-60-90 дневный план для Python-разработчика

Вот реальный пример плана, который мы использовали для junior-разработчика в компании с 20 IT-специалистами:

0-30 дней:

31-60 дней:

61-90 дней:

Результат: сотрудник успешно прошёл испытательный срок, получил повышение зарплаты на 20% и стал частью команды.

Выводы: почему план работает и как его масштабировать

30-60-90 дневный план — это не просто документ, а инструмент управления талантами. В IT-компаниях он решает три ключевые задачи:

1. Снижает текучку — по нашим данным, план уменьшает количество увольнений в первые 3 месяца на 30-40%.

2. Ускоряет адаптацию — средний срок выхода на полную эффективность сокращается с 4-6 месяцев до 6-8 недель.

3. Улучшает коммуникацию — план делает процесс адаптации прозрачным для сотрудника, ментора и тимлида.

Для масштабирования плана в крупных IT-компаниях рекомендуем:

Если у вас нет ресурсов на создание плана с нуля, [оставьте заявку](#request) — мы поможем адаптировать шаблон под вашу IT-команду и внедрить его в процесс адаптации.