Прод лёг перед релизом.
Ключевой разработчик написал: «Нужно поговорить».
Заказчик второй день не отвечает.
Команда снова не укладывается в оценку спринта.
И вот мы уже представляем сорванный запуск, потерянного клиента, развалившуюся команду и неприятный разговор с руководством.
Хотя прошло всего семь минут 😁
Мозг за это время успел создать в Jira эпик «Полная катастрофа», назначить его на нас, поставить максимальный приоритет и добавить дедлайн «вчера». Мы и сами такие же. Иногда путь от сообщения «Есть минутка?» до мысленного обновления резюме занимает меньше времени, чем загрузка корпоративного VPN.
В такие моменты тревогу легко перепутать с ответственностью. Кажется, что хороший руководитель обязан заранее предусмотреть каждый возможный провал, подготовить планы A, B, C и на всякий случай узнать, где сейчас нанимают людей с опытом спасения горящих проектов.
Но между тревогой и управлением рисками есть важное отличие:
управление рисками приводит к плану действий, а тревога — только к новым сценариям катастрофы
Особенно важно помнить об этом сейчас.
Рынок меняется, бюджеты пересматриваются, требования бизнеса растут, а решения всё чаще приходится принимать без полной информации, гарантий результата и кнопки «вернуть всё как было до последнего обновления».
В такой среде особенно ценятся руководители, которые не замирают перед неопределённостью, а умеют:
• брать ответственность за решения, а не ждать, пока кто-нибудь случайно примет их в соседнем чате;
• быстро адаптироваться к новым условиям, даже если условия обновились прямо во время созвона;
• отделять реальные риски от сценариев, которые мозг написал ночью без согласования с командой;
• сохранять фокус команды, когда одновременно горят прод, дедлайн и три рабочих чата;
• действовать, не дожидаясь идеального плана, полной определённости и ретроградного Меркурия в правильной позиции.
Руководителю не всегда нужно сразу понимать, как спасти весь проект, компанию и IT-индустрию целиком.
Для начала достаточно определить ближайшую точку принятия решения:
• что мы уже знаем о проблеме;
• каких данных нам не хватает;
• какое решение нельзя откладывать;
• кто отвечает за следующий шаг;
• когда мы снова оцениваем ситуацию, а не проверяем её каждые четыре минуты.
Если релиз задерживается, не нужно сразу переписывать продуктовую стратегию на год вперёд и готовить речь для совета директоров. Сначала стоит разобраться в причинах задержки, критичности блокеров и реальной дате готовности.
Если специалист написал: «Нужно поговорить», не обязательно заранее открывать вакансию, искать замену и распределять его задачи между оставшимися. Возможно, ему действительно просто нужно поговорить. Такое тоже иногда случается.
Если заказчик недоволен, не стоит мысленно закрывать контракт раньше созвона и удалять проект из портфолио. Сначала нужно понять, где разошлись ожидания и что ещё можно исправить.
Одно из главных правил руководителя в IT:
не пытаться контролировать все возможные сценарии, а создавать ясность там, где её можно создать прямо сейчас
Сильный менеджмент сегодня — это не отсутствие сомнений и не способность предсказывать будущее.
Это умение принимать решения, перестраиваться и вести команду вперёд, даже когда правила меняются быстрее, чем обновляется документация. А документация, как известно, иногда не обновляется вообще.
Сейчас на наши программы для C-level и IT-руководителей действует скидка 30% по промокоду OTPUSK30
Среди них — программы для тимлидов, руководителей команд и технических директоров. Они помогут системнее работать с людьми, процессами, рисками и сложными управленческими решениями в условиях, когда готового ответа ещё нет, а задачу уже поставили в спринт и спросили, почему она не готова.
