Долгих дней и приятных ночей! Я Наталия Курченкова, IT Project Manager с 10+ лет опыта. Сегодня разберем историю, знакомую многим техническим руководителям. В команде есть разработчик. Код пишет качественно, к нему сложно придраться по технической части. Однако в критические моменты, когда от каждого зависит успех общего дела, он исчезает.
Введение
Пример 1: Сорванный релиз
День релиза. Чтобы успеть, билды должны попасть в тестирование рано утром. Разработчик появляется только к полудню. Команда заблокирована, ждет именно его часть работы. Тестирование, требующее пяти часов, начинается с опозданием. Релиз сорван.
Разработчик был в курсе сроков, понимал важность момента. Тимлид чувствует разочарование: на этого человека нельзя положиться, когда нужно поднажать. Возникает сомнение: "Все поняли важность, а он — нет. Может, я недостаточно объяснил?" Хотя с другими членами команды подобных проблем не возникает.
Пример 2: Исчезновение при аварии
Вечером, около семи, потребовалось срочное вмешательство для решения критической проблемы. Разработчика попросили подключиться. Он подтвердил согласие. После этого связаться с ним стало невозможно. На связь он вышел только в восемь, сообщив, что ушел в спортзал.
Тимлид был вынужден лично доделывать его работу. Срывы сроков не прошли бесследно — на ревью тимлид получил негативную оценку. И здесь тимлид находит оправдание для разработчика:
"Человек имеет право на личное время, упрекать его нельзя".
Корень проблемы
Правильный вопрос, который должен задать себе руководитель:
"Почему в моей системе управления стало возможным такое поведение одного сотрудника без немедленных и адекватных последствий? Почему я, как лидер, допустил ситуацию, когда один человек может безнаказанно блокировать работу всей команды и срывать релизы?"
Решение: От слов — к управленческой воле и действиям
Исправить ситуацию возможно только через четкие, системные и, что важно, последовательно применяемые управленческие шаги.
1. Четко определить и формализовать понятие "Критическая ситуация / Режим мобилизации".
Это не должно быть абстракцией или объяснением по случаю. Это конкретные, прописанные сценарии:
- Финальные дни перед релизом (особенно релизный день).
- Обработка аварийных инцидентов в продуктивной среде.
- Срочные исправления блокирующих багов.
Для этих периодов должны быть прописаны и согласованы со всей командой (лучше письменно, как часть правил работы или дополнение к трудовому договору) четкие ожидания:
- Гибкий график работы.
- Гарантированная доступность.
- Безусловный приоритет срочных задач.
Объяснять важность релизного дня утром релизного дня — уже поздно. Эти правила должны быть частью ДНК команды, ее культуры. Каждый новый член команды должен быть с ними ознакомлен под подпись.
2. Установить ясные, измеримые и неизбежные последствия за нарушение договоренностей.
Управление без последствий — это иллюзия управления. Последствия — это не "упреки" или эмоции. Это инструмент:
- Фиксация каждого инцидента в истории эффективности сотрудника (Performance Review).
- Поэтапное применение мер: устное предупреждение (с фиксацией разговора), затем официальное письменное предупреждение.
- Прямое влияние на материальную мотивацию (например, потеря бонуса или премии за квартал, в котором произошел срыв критического срока).
- Для систематических нарушений — формализованный план по улучшению эффективности (PIP) как последнее предупреждение или основание для расставания.
Без последовательного применения справедливых последствий любые правила теряют смысл.
3. Прекратить практику "спасения" и выполнения чужой работы.
Когда разработчик исчезает в критический момент, а тимлид берет и доделывает его задачу — это худшее из возможных решений. Оно поощряет безответственность и разрушает командную дисциплину.
Правильные действия:
- Четко зафиксировать факт блокировки команды и срыва сроков по вине конкретного сотрудника.
- Провести обязательный разбор полетов с этим сотрудником сразу после инцидента, основываясь исключительно на фактах и нарушении установленных правил.
- Искать системные решения для снижения рисков "точки отказа": кросс-тренинг других разработчиков на критическом функционале, дублирование знаний, если ресурсы позволяют.
Но ключевое — ни в коем случае не выполнять работу за безответственного сотрудника.
4. Отказаться от необоснованного чувства вины.
Если подавляющее большинство команды понимает важность совместной работы в критических точках и действует ответственно, а один человек системно игнорирует правила, проблема не в недостатке объяснений со стороны лида. Проблема может крыться в:
- Фундаментальном непонимании сотрудником базовых принципов командной работы и ответственности.
- Сознательном пренебрежении установленными правилами.
И то, и другое является предметом для кадровых решений, а не для самоуничижения руководителя.
Заключение
Управление командой — это искусство устанавливать четкие границы. Ваша задача как лидера — не быть "хорошим" для одного, а создавать систему, работающую для всех.
Право на личное время не отменяет профессиональной ответственности.
Начните управлять — перестаньте оправдывать.
#УправлениеКомандами #СрывРелиза #Разработка #ITМенеджмент #Лидерство