90-дневный план онбординга с AI: понедельный разбор и промпты
Что такое AI-генерация 90-дневного онбординга?
AI-генерация 90-дневного онбординга — это практика использования языковых моделей для создания структурированных понедельных планов адаптации сотрудников, включающих задачи, ожидаемые результаты, метрики успеха и повестки для 1:1-встреч, настроенных под конкретную роль, стек и контекст команды. Это важно потому, что структурированный онбординг значительно улучшает трёхлетнее удержание сотрудников (Brandon Hall Group), однако создание полного плана вручную занимает 15–20 часов времени руководителя. С помощью LLM тот же план создаётся за 2–3 часа, а адаптация под другую роль — за 30–40 минут.
TL;DR
- -Структурированный онбординг значительно улучшает трёхлетнее удержание (Brandon Hall Group), но создание полного 90-дневного плана занимает 15–20 часов вручную — LLM сжимают это до 2–3 часов.
- -Трёхфазная структура (Погружение дни 1–30, Вклад дни 31–60, Автономность дни 61–90) привязана к измеримым критериям завершения фазы, исключая размытые решения «испытательный срок пройден».
- -Подготовка Недели 0 до первого рабочего дня — наиболее ценный шаг: аккаунты, доступы, ссылки на документацию и первая онбординг-задача в трекере должны быть готовы до дня выхода, а не в процессе.
- -Красные флаги, требующие немедленного реагирования: нулевые PR за неделю, отсутствие вопросов к ментору (замкнутость, а не самостоятельность), повторяющееся одинаковое замечание на код-ревью, негативная обратная связь от 2+ коллег.
- -Адаптация плана backend-инженера под другую роль (PM, QA, DevOps) через промпт занимает 30–40 минут — 5 позиций в квартал означают 3 часа вместо 80.
Создание понедельного онбординг-плана на 90 дней с учётом роли, стека, корпоративных процессов и метрик успеха занимает 15–20 часов. Это время руководителя, которого и так не хватает — особенно в командах до 50 человек. Разрыв между «знаем, что онбординг важен» и «реально делаем» — хронический.
LLM сжимают работу до 2–3 часов: генерация структуры, наполнение по неделям, критерии оценки, адаптация под позицию.
Статья содержит полный шаблон 90-дневного онбординг-плана, промпты для генерации каждого блока и чеклисты по неделям. Тот же подход к автоматизации документации процессов, что описан в руководстве по SOP-генерации с AI.
Структура 90-дневного плана: три фазы адаптации
90 дней делятся на три фазы. Каждая имеет отдельную цель, набор задач и критерии завершения.
Фаза 1 (дни 1–30): погружение. Новый сотрудник изучает контекст: продукт, стек, процессы, команду. Результат фазы — способность самостоятельно выполнять типовые задачи без постоянного сопровождения.
Фаза 2 (дни 31–60): вклад. Самостоятельная работа над задачами средней сложности. Участие в код-ревью, планированиях, дежурствах. Результат — стабильная производительность на уровне 60–70% от среднего по команде.
Фаза 3 (дни 61–90): автономность. Работа над задачами полного цикла. Инициатива в улучшении процессов. Результат — полноценный участник команды, способный принимать самостоятельные решения в рамках своей зоны ответственности.
Фаза 1: Погружение Фаза 2: Вклад Фаза 3: Автономность
Дни 1–30 Дни 31–60 Дни 61–90
──────────────────── ──────────────────── ────────────────────
Цель: понять контекст Цель: стабильный Цель: полная
и выполнять типовые вклад в команду самостоятельность
задачи
Ментор: ежедневно Ментор: 2–3 раза Ментор: еженедельно
в неделю
Промпт для генерации базового плана онбординга
Генерация начинается с одного детального промпта. Он создаёт скелет всего плана, который затем дорабатывается по фазам.
Сгенерируй 90-дневный план онбординга для следующей позиции.
## Контекст
- Позиция: [Senior Backend Engineer]
- Стек: [Python, FastAPI, PostgreSQL, Redis, Docker, Kubernetes]
- Размер команды: [8 человек]
- Методология: [Scrum, 2-недельные спринты]
- Основной продукт: [B2B SaaS платформа для логистики]
- Ключевые системы: [API Gateway, Order Service, Billing Service]
## Требования к плану
1. Разбей на 3 фазы: Погружение (дни 1–30), Вклад (дни 31–60), Автономность (дни 61–90)
2. Каждую фазу разбей по неделям
3. Для каждой недели укажи:
- Конкретные задачи (не абстрактные "изучить документацию")
- Ожидаемый результат
- Кто отвечает за поддержку (ментор, тимлид, конкретная роль)
4. Для каждой фазы укажи критерии завершения (measurable)
5. Включи как техническую, так и организационную адаптацию
6. Учти первую неделю как "нулевую" — настройка окружения, доступы, знакомства
## Формат
Markdown-таблица для каждой недели. Колонки: День/Период | Задача | Результат | Ответственный
Этот промпт генерирует план на 3–5 страниц. Качество зависит от детализации контекста: чем точнее описаны стек, процессы и специфика продукта, тем меньше ручной доработки потребуется.
Фаза 1: понедельный план погружения (дни 1–30)
Неделя 0 (до первого дня)
Подготовка начинается до выхода сотрудника. Промпт для генерации чеклиста подготовки:
Сгенерируй чеклист подготовки к выходу нового сотрудника на позицию
[Senior Backend Engineer].
Включи категории:
- Доступы (Git, CI/CD, cloud, мониторинг, чаты)
- Оборудование и софт
- Документация для изучения в первый день
- Назначение ментора и расписание встреч первой недели
- Onboarding-задача в трекере (первый PR)
Формат: чеклист с ответственным за каждый пункт.
Чеклист подготовки:
- Учётные записи: Git, Jira/Linear, Slack, корпоративная почта
- Доступы: AWS/GCP консоль (read-only), CI/CD pipeline, staging-окружение
- Мониторинг: Grafana, Sentry, логи (read-only)
- Документация: ссылки на архитектурные ADR, API-спецификации, runbooks
- Ментор назначен, календарь первой недели заполнен
- Онбординг-задача создана в трекере (описание, acceptance criteria)
- Welcome-сообщение в канале команды (подготовлено, отправляется в первый день)
Неделя 1: ориентация и первый PR
| День | Задача | Результат |
|---|---|---|
| 1 | Настройка рабочего окружения. Клонирование репозиториев, запуск проекта локально | Проект запускается, тесты проходят |
| 1 | Знакомство с командой: 15-минутные 1:1 с каждым участником | Понимание ролей и зон ответственности |
| 2–3 | Изучение архитектуры: обзор от ментора + самостоятельное чтение ADR | Способность нарисовать верхнеуровневую схему системы |
| 3–4 | Первая задача: исправление несложного бага или добавление теста | Первый PR на ревью |
| 5 | Ретроспектива первой недели с ментором | Список вопросов и план на вторую неделю |
Неделя 2: процессы и кодовая база
| День | Задача | Результат |
|---|---|---|
| 6–7 | Участие в планировании спринта (наблюдение) | Понимание процесса приоритизации |
| 6–8 | Глубокое изучение одного сервиса (назначается ментором) | Code walkthrough: ключевые модули, data flow |
| 8–9 | Вторая задача: фича или улучшение в изученном сервисе | PR с тестами, прошедший код-ревью |
| 10 | Обзор CI/CD пайплайна: как деплоится код | Способность самостоятельно задеплоить в staging |
Неделя 3: расширение контекста
| День | Задача | Результат |
|---|---|---|
| 11–12 | Изучение второго сервиса. Чтение кода + обсуждение с владельцем | Понимание межсервисного взаимодействия |
| 13–14 | Задача, затрагивающая два сервиса | PR с интеграционными тестами |
| 14–15 | Участие в код-ревью чужих PR (2–3 ревью) | Обратная связь от ментора по качеству ревью |
Неделя 4: закрепление и оценка
| День | Задача | Результат |
|---|---|---|
| 16–18 | Самостоятельная задача средней сложности | PR без существенных замечаний на ревью |
| 19 | Презентация изученного: 15-минутный обзор архитектуры для ментора | Валидация понимания системы |
| 20 | 1:1 с руководителем: оценка Фазы 1 | Решение о переходе к Фазе 2 |
Критерии завершения Фазы 1:
- Локальное окружение работает стабильно
- 3+ PR замержено
- Способность самостоятельно деплоить в staging
- Знание архитектуры минимум двух ключевых сервисов
- Участие в одном полном спринте (планирование → ретроспектива)
Фаза 2: понедельный план вклада (дни 31–60)
Промпт для детализации Фазы 2:
Детализируй Фазу 2 (дни 31–60) онбординг-плана для [Senior Backend Engineer].
Контекст из Фазы 1:
- Изучены сервисы: [Order Service, Billing Service]
- Замержено PR: [5]
- Знает CI/CD, может деплоить в staging
Требования к Фазе 2:
1. Переход от наблюдения к активному участию в процессах
2. Задачи уровня "средний" и "сложный"
3. Начало участия в дежурствах (с подстраховкой)
4. Первая самостоятельная фича от дизайна до деплоя
5. Обратная связь от 3+ коллег в конце фазы
Формат: понедельная таблица с задачами и метриками.
Неделя 5–6: самостоятельные задачи полного цикла
| Период | Задача | Результат |
|---|---|---|
| Неделя 5 | Самостоятельная фича: от технического дизайна до PR | Техдизайн согласован с ментором, реализация начата |
| Неделя 5 | Первое дежурство (shadow): наблюдение за дежурным | Понимание процесса обработки инцидентов |
| Неделя 6 | Завершение фичи, деплой в staging, демо команде | Фича работает в staging, получена обратная связь |
| Неделя 6 | Участие в ретроспективе с предложением улучшения | Активная роль в процессах команды |
Неделя 7–8: расширение влияния
| Период | Задача | Результат |
|---|---|---|
| Неделя 7 | Первое самостоятельное дежурство (с подстраховкой) | Обработан минимум один тикет без эскалации |
| Неделя 7 | Код-ревью: 5+ ревью за неделю | Конструктивная обратная связь, находки реальных проблем |
| Неделя 8 | Задача уровня “сложный” (performance, рефакторинг, новая интеграция) | PR с измеримым улучшением |
| Неделя 8 | 360-обратная связь от 3+ коллег | Документ с сильными сторонами и зонами роста |
Критерии завершения Фазы 2:
- Самостоятельная фича доведена до production
- 10+ PR замержено (суммарно)
- Способность дежурить без подстраховки
- Код-ревью оценивается коллегами как полезное
- 360-обратная связь без критических замечаний
Фаза 3: понедельный план автономности (дни 61–90)
Промпт для детализации Фазы 3:
Детализируй Фазу 3 (дни 61–90) онбординг-плана для [Senior Backend Engineer].
Контекст:
- Фаза 1 и 2 пройдены успешно
- Самостоятельно ведёт задачи полного цикла
- Участвует в дежурствах
- 360-обратная связь: [вставить ключевые пункты]
Требования к Фазе 3:
1. Полная автономность в рамках зоны ответственности
2. Инициатива: предложение улучшений процессов или кода
3. Менторство: помощь другим (джуниорам, новичкам)
4. Подготовка к финальной оценке испытательного срока
5. Определение зоны ownership
Формат: понедельная таблица + критерии прохождения испытательного срока.
Неделя 9–10: ownership и инициатива
| Период | Задача | Результат |
|---|---|---|
| Неделя 9 | Определение зоны ownership (сервис или домен) | Согласовано с руководителем, задокументировано |
| Неделя 9 | Инициативная задача: улучшение, которое сотрудник определил самостоятельно | Техдизайн и обоснование (ROI, impact) |
| Неделя 10 | Реализация инициативной задачи | PR замержен, impact измерен |
| Неделя 10 | Помощь коллеге с задачей вне своей зоны ownership | Демонстрация кросс-функциональности |
Неделя 11–12: подготовка к оценке
| Период | Задача | Результат |
|---|---|---|
| Неделя 11 | Полностью самостоятельный спринт: планирование задач, execution, демо | Спринт завершён без эскалаций |
| Неделя 11 | Документирование: описание своей зоны ownership (архитектура, runbook) | Документация, полезная для будущих сотрудников |
| Неделя 12 | Самооценка: достижения, зоны роста, план развития на следующий квартал | Документ для финальной оценки |
| Неделя 12 | Финальная встреча с руководителем: оценка испытательного срока | Решение о прохождении |
Критерии прохождения испытательного срока:
- Производительность на уровне 80%+ от среднего по команде
- Определена и документирована зона ownership
- Минимум одна инициативная задача доведена до production
- Способность самостоятельно дежурить и обрабатывать инциденты
- Положительная обратная связь от 4+ членов команды
- Отсутствие повторяющихся критических замечаний на код-ревью
Промпт для адаптации плана под конкретную роль
Базовый шаблон выше заточен под backend-инженера. Для адаптации под другие роли:
Адаптируй 90-дневный онбординг-план под роль [Product Manager / QA Engineer / DevOps / Designer].
Текущий план (backend engineer):
[вставить сгенерированный план]
Изменения для новой роли:
1. Замени технические задачи на релевантные для роли
2. Сохрани структуру трёх фаз и понедельную разбивку
3. Адаптируй критерии завершения каждой фазы
4. Укажи специфичные инструменты и процессы для роли
5. Сохрани организационную адаптацию (знакомства, процессы, культура)
Примеры адаптации задач:
- "Первый PR" → "Первый тест-план" (QA) / "Первый PRD" (PM)
- "Код-ревью" → "Ревью тест-кейсов" (QA) / "Ревью спецификаций" (PM)
- "Дежурство" → "Triage багов" (QA) / "Приоритизация бэклога" (PM)
Автоматизация чеклистов: промпт для трекера задач
Понедельный план работает только внутри трекера задач, где каждый пункт отслеживается. В Google Doc он превращается в мёртвый документ.
Промпт для генерации задач в формате трекера:
Преобразуй понедельный онбординг-план в набор задач для [Jira / Linear / Notion].
Требования:
1. Каждая задача — отдельный тикет
2. Поля: название, описание, assignee, due date (относительно даты выхода),
labels (onboarding, phase-1/2/3), acceptance criteria
3. Milestone-задачи для каждой фазы (критерии завершения)
4. Parent task для каждой недели (epic или group)
5. Зависимости между задачами где применимо
Формат: JSON-массив объектов, совместимый с API [выбранного трекера].
Пример сгенерированного тикета:
{
"title": "Неделя 1: Первый PR",
"description": "Исправить баг [ссылка] или добавить тест для [модуль]. Цель — пройти полный цикл: ветка → код → тесты → PR → ревью → мерж.",
"labels": ["onboarding", "phase-1", "week-1"],
"due_date": "+5d",
"assignee": "new_hire",
"acceptance_criteria": [
"PR создан и прошёл CI",
"Минимум один approving review",
"PR замержен в main"
]
}
Встречи 1:1: промпт для повестки и вопросов
Регулярные 1:1 между руководителем и новым сотрудником без структуры превращаются в «ну, как дела?».
Сгенерируй повестку для 1:1 встречи на [неделя N] онбординга.
Контекст:
- Фаза: [1/2/3]
- Задачи текущей недели: [список]
- Известные сложности: [если есть]
- Обратная связь от ментора: [если есть]
Структура повестки:
1. Check-in (5 мин): общее состояние, блокеры
2. Прогресс (10 мин): что сделано, что не получилось, почему
3. Обратная связь (5 мин): что идёт хорошо, что скорректировать
4. План (5 мин): задачи следующей недели, ожидания
5. Вопросы (5 мин): открытые вопросы с обеих сторон
Для каждого пункта предложи 2–3 конкретных вопроса, привязанных к текущей неделе.
Промпт генерирует повестку за 30 секунд. Без AI подготовка к каждому 1:1 занимает 10–15 минут (просмотр задач, формулировка вопросов, структурирование). За 12 недель онбординга это 2–3 часа только на подготовку к встречам.
Метрики: как измерить качество онбординга
Онбординг без метрик — формальность. Промпт для генерации системы метрик:
Предложи метрики для оценки качества 90-дневного онбординга.
Категории:
1. Скорость выхода на продуктивность (time-to-productivity)
2. Качество работы (код, документация, решения)
3. Интеграция в команду (коммуникация, процессы)
4. Удовлетворённость (сотрудника и команды)
Для каждой метрики укажи:
- Что измеряем
- Как измеряем (источник данных)
- Целевое значение по фазам
- Red flag (когда нужна интервенция)
Ключевые метрики по фазам:
| Метрика | Фаза 1 | Фаза 2 | Фаза 3 |
|---|---|---|---|
| PR/неделю | 1–2 | 3–4 | 4–5 |
| Время до первого ревью | < 3 дней | < 1 дня | < 4 часов |
| Замечания на PR (среднее) | 5+ (норма) | 2–3 | 0–1 |
| Задачи без эскалации | 50% | 80% | 95% |
| Оценка ментора (1–5) | 3+ | 4+ | 4+ |
Red flags, требующие интервенции: нулевые PR за неделю, отсутствие вопросов к ментору (замкнутость, а не самостоятельность), повторяющиеся одинаковые замечания на код-ревью, негативная обратная связь от 2+ коллег.
Итоговый чеклист: внедрение 90-дневного плана
Генерация плана — 20% работы. Остальные 80% — внедрение и поддержка.
Перед запуском:
- Сгенерировать базовый план (мета-промпт из раздела выше)
- Адаптировать под конкретную роль и уровень
- Загрузить задачи в трекер
- Назначить ментора, согласовать его загрузку (5–8 часов/неделю в Фазе 1)
- Подготовить доступы и окружение (чеклист Недели 0)
В процессе:
- Еженедельные 1:1 с генерированной повесткой
- Оценка метрик по фазам
- Корректировка плана при отклонениях (генерация альтернативных задач через LLM)
- Сбор обратной связи от ментора после каждой фазы
После завершения:
- Финальная оценка по критериям Фазы 3
- Ретроспектива онбординг-процесса: что сработало, что улучшить
- Обновление шаблона плана на основе ретроспективы
- Передача результатов в базу знаний для следующих наймов
Один раз сгенерированный план для Senior Backend Engineer адаптируется под Middle-позицию за 15 минут (убрать задачи уровня ownership, усилить менторское сопровождение). Адаптация под другую роль через мета-промпт занимает 30–40 минут с ручной доработкой. Пять позиций за квартал — 3 часа вместо 80.
Нужна помощь с онбордингом? Я помогаю стартапам внедрять AI-решения и строить продукты — belov.works.
FAQ
Как поступить с новым сотрудником, выполнившим задачи Фазы 1, но явно не достигшим нужной глубины компетенций?
Критерии завершения фазы — это не временна́я метка, а ворота принятия решений. Если сотрудник выполнил чеклист (3+ PR замержено, умеет деплоить в staging, прошёл архитектурный воркшоп), но ментор фиксирует поверхностное понимание, назначьте «расширенную Фазу 1» ещё на две недели с целевым планом обучения, сгенерированным через LLM. Ключевое условие: это должен быть структурированный разговор с письменными критериями, а не размытое «нужно больше времени». И менеджер, и сотрудник должны чётко согласовать, что именно означает «готов к Фазе 2», до начала продления.
Должен ли онбординг-план отличаться для удалённых и офисных сотрудников?
Структура остаётся той же, но задачи Недели 1 меняются. Удалённый онбординг требует явных норм асинхронной коммуникации в плане (какие каналы для каких вопросов, ожидаемое время ответа, культура включённого видео) и более частых 1:1 в Фазе 1 — ежедневные 15-минутные звонки вместо еженедельных. «15-минутный 1:1 с каждым участником команды» в Неделе 1 становится запланированным видеозвонком. В Неделю 0 добавьте блок «удалённые инструменты»: проверьте настройку видеосвязи, доступ к асинхронным инструментам и чёткую документацию о работе команды в разных часовых поясах.
Какова реалистичная нагрузка на ментора, и как не допустить, чтобы она съедала его собственную продуктивность?
В Фазе 1 ментор тратит 5–8 часов в неделю — в основном на парное программирование, архитектурные обзоры и PR-ревью. Это реальные затраты, а не оценка. Защитите продуктивность ментора, ограничив его одним онбордируемым одновременно и явно снизив его спринт-обязательства на 20–30% в Фазе 1. В Фазе 2 нагрузка падает до 2–4 часов в неделю, к Фазе 3 — менее 2 часов. Закладывайте это в спринт-планирование с первой недели, а не воспринимайте как «дополнительную» работу, которая не учитывается в velocity команды.