Что будешь делать если главный разработчик хочет уйти перед началом проекта?

План действий при угрозе ухода ключевого разработчика перед стартом проекта

В ситуации, когда главный разработчик (Tech Lead/Architect) хочет уйти накануне старта проекта, требуется немедленная, но взвешенная реакция. Основа моих действий — минимизация рисков для проекта при уважении личного решения сотрудника. Вот пошаговый план, который я реализую как руководитель проекта.

1. Немедленная индивидуальная беседа (Эскалация и анализ)

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

• Ключевые вопросы:

    *   Причины ухода (конфликт, условия, новый вызов, личные обстоятельства).
    *   Сроки (планируемая дата ухода, есть ли возможность отсрочки).
    *   Его видение **степени критичности** его роли на старте.
    *   Его рекомендации по потенциальным преемникам внутри команды.

# Пример структурирования информации из беседы для анализа
risk_assessment = {
    "reason": "professional_growth",  # или conflict, personal_issues, compensation
    "notice_period_days": 30,
    "is_knowledge_critical": True,
    "internal_replacement_suggested": ["Senior_Dev_A", "Senior_Dev_B"],
    "project_phase_impact": "initiation_and_planning"
}

2. Оценка воздействия на проект и эскалация

На основе полученной информации я провожу срочную оценку:

• Технические риски: Утрата архитектурного видения, знаний о выбранном стеке, понимания "подводных камней".
• Командные риски: Потеря лидера, падение морального духа, неопределенность.
• Риски по срокам и бюджету: Возможные задержки в планировании, пересмотр технического задания.

Я немедленно информирую спонсора проекта (Sponsor) и руководителя отдела разработки (Head of Development). Прозрачность на этом этапе критична. Вместе мы обсуждаем варианты:

• Удержание: Возможно ли предложить решение (изменение роли, бонус за запуск, четкий карьерный план)? Это оправдано только если причина решаема.
• Поиск замены: Внутренний или внешний.
• Корректировка плана: Сдвиг сроков старта, пересмотр зон ответственности.

3. Активная фаза управления риском: План на 72 часа

В зависимости от решения стейкхолдеров, я запускаю один или несколько сценариев параллельно.

Сценарий А: Передача знаний (Knowledge Transfer)

Если разработчик согласен на сотрудничество в переходный период, я создаю интенсивный план передачи знаний (KT Plan).

## План KT для главного разработчика (пример)
**Цель:** Документировать ключевые решения и подготовить преемника.
**Срок:** 3 недели.
**Артефакты:**
*   Архитектурное решение (ADR) с обоснованием выбора технологий.
*   Диаграмма высокоуровневой архитектуры (C4 Context & Container).
*   Риски и допущения, выявленные на пре-сейле.
*   Контакты ключевых технических контактов (заказчик, вендоры).
**Формат:** Ежедневные стендапы + 3 воркшопа по ключевым модулям.
**Ответственный за прием KT:** [Имя преемника].

Сценарий Б: Срочный поиск замены

• Внутренний поиск: Совместно с тимлидами определяем сильного senior-разработчика с лидерским потенциалом. Рассматриваем вариант временного назначения с менторской поддержкой.
• Внешний поиск: Подключаем HR и кадровые агентства. Важно четко описать роль: "архитектор на этапе запуска". Рассматриваем контрактных специалистов (contractors) для быстрого закрытия вакансии.

Сценарий В: Адаптация плана проекта

Пересматриваю устав проекта (Project Charter) и дорожную карту (Roadmap). Возможно, этап планирования (Initiation & Planning) потребует больше времени. Я готовлю варианты для стейкхолдеров:

• Вариант 1: Сдвиг старта разработки на 2-4 недели для поиска и адаптации нового лида.
• Вариант 2: Старт с "облегченной" архитектурой и пересмотр через первый спринт с новым лидом.

4. Работа с командой и коммуникация

Важно сохранить доверие и мотивацию в команде.

• Провожу встречу с командой без излишних деталей, но с четким посылом: ситуация под контролем, план действий есть, их вклад ценен.
• Назначаю временного технического координатора (например, самого опытного разработчика), чтобы не было вакуума ответственности.
• Усиливаю свое вовлечение в технические обсуждения на первых порах.

5. Выводы и превентивные меры на будущее

После стабилизации ситуации я провожу разбор инцидента (Post-Mortem).

• Институциональные знания: Ускоряю внедрение практик документирования ключевых решений (ADR) и парного программирования.
• Кадровая политика: Рекомендую вырастить функцию Deputy Tech Lead в критичных проектах.
• Управление талантами: Инициирую регулярные one-to-one встречи руководителей с ключевыми специалистами для раннего выявления неудовлетворенности.

Итог: Моя главная задача — перевести эту проблему из категории кризиса (crisis) в категорию управляемого риска (managed risk). Через прозрачную коммуникацию, быструю оценку воздействия и фокусировку на сохранении знаний и стабильности команды можно преодолеть эту ситуацию с минимальными потерями для проекта. Ключ — действовать быстро, системно и сохранять человеческое отношение к уходящему специалисту, ведь профессиональные пути могут снова пересечься.