Ключевой разработчик планирует уход

Решение

1. Шаги в первые 24 часа

Немедленное действие — сохранение знаний

• Назначить критическую встречу с Александром в ближайшие 2-4 часа (при наличии возможности — лично, не по видео)
• Запросить от него доступ ко всем документам: design docs, архитектурные решения, deployment guide, known issues, roadmap
• Попросить создать quick onboarding guide: главные компоненты системы, critical paths, что может сломаться
• Записать детальное интервью (видео + транскрипт): ответы на вопросы про архитектуру, bottlenecks, техдолг
• Убедиться, что вся информация в источниках истины (Wiki, GitHub, Confluence), а не только в его голове

Информирование руководства

• Немедленно уведомить CTO/CEO: это critical risk для релиза
• Подготовить риск-матрицу: какие части системы зависят от Александра, какие проще передать
• Предложить несколько сценариев развития событий с timeline

Оценка текущей критичности

• Провести техническое совещание: какие части кода обязательны для релиза, какие можно отложить
• Понять, может ли оставшаяся команда закончить 80% работы без Александра (оставив 20% на потом)
• Определить критические знания: кто ещё в команде их имеет?

Сохранение в команде (если возможно)

• Предложить встречу с Александром: услышать его лично, выяснить, есть ли возможность его удержать
• НЕ давить и НЕ показывать панику — это может ускорить его уход
• Показать, что его вклад ценится, его знания нужны

2. Выяснение истинных причин ухода

Структурированное интервью (спокойный тон, без обвинений)

Вопросы про работу:

• Что его больше всего вдохновляет в текущем проекте? Что раздражает?
• Есть ли недоговорённости с руководством или командой?
• Достаточно ли ему ресурсов и инструментов для работы?

Вопросы про личное:

• Это решение принято давно или спонтанно?
• Есть ли предложение от другого работодателя или это инициатива?
• Каковы его карьерные планы на ближайший год?

Вопросы про мотивацию:

• Что бы его удержало? (бонус, более интересные задачи, возможность расти, свобода в технических решениях)
• Может ли он остаться хотя бы до конца проекта/релиза?

Слушание, а не защита:

• Принять причины как есть, не спорить
• Если человек уже решил — попытка удержать за счёт давления обычно не работает
• Если причина в деньгах — расчет может быть обсужден с финансовым директором
• Если причина в психологии — привлечь HR, обсудить условия

3. Варианты решения для руководства

Вариант 1: Удержать Александра

• Условие: если он открыт к переговорам
• Рычаги: бонус, повышение,更 интересные задачи, гибкий график, возможность расти до тех-лида
• Сроки: договориться о сроке, когда он сможет уйти (например, через 3 месяца после релиза)
• Риск: может быть мотивирован на другую работу, только время выиграем
• Стоимость: бюджет на бонус, возможно, переговоры с инвесторами

Вариант 2: Ускоренный Knowledge Transfer (KT)

• Если Александр уходит в любом случае, максимально отжать его знания
• План на 10 дней:
  • День 1-2: полная документация архитектуры
  • День 3-4: code walkthrough критических модулей с другими разработчиками
  • День 5-7: парное программирование на ключевых задачах
  • День 8-10: Q&A сессии, запись видео, создание чек-листов
• После ухода: видеозаписи, подробная wiki, возможность контакта для срочных вопросов (даже после ухода)
• Риск: KT может замедлить текущую разработку на 20-30%, зато знания сохранятся
• Стоимость: низкая

Вариант 3: Пересмотр scope релиза

• Если потеря Александра критична, обсудить с инвесторами возможность отложить часть функционала
• Минимальный releasable product за 2 недели без его участия
• Второй релиз через месяц, когда KT завершится
• Преимущество: релиз вовремя, но урезанный; инвестиции не теряются
• Недостаток: может не устроить стейкхолдеров

**Вариант 4: Быстрый наём

• Привлечь senior разработчика (фрилансер или контрактор) на 2-4 недели
• Его задача: работать в паре с оставшейся командой, подхватывать знания от Александра, вести релиз
• Стоимость: высокая (senior фрилансер стоит дорого)
• Риск: сложно найти в спешке, адаптация занимает время

Вариант 5: Гибридный подход (рекомендуется)

• Неделя 1: переговоры с Александром — попытка удержать или договориться о KT периоде
• Неделя 2: интенсивный KT + работа над releasable scope
• После релиза: переговоры о transition period (2-4 недели консультаций за деньги)
• Одновременно: запуск рекрутмента на замену

Ключевое правило

Первая ошибка многих PM — паниковать и показывать отчаяние. Это ускоряет уход и демотивирует команду. Вторая ошибка — игнорировать сигнал и надеяться на лучшее.

Правильный подход: спокойствие, оценка рисков, быстрые действия, диалог с человеком и руководством. Александр — не врaг, это ценный член команды, и даже его уход можно превратить в возможность для обучения остальной команды.