Пожар на ИТ-проекте: как спасти проект за две недели

Рассказываем, как успеть до дедлайна, и делимся базовым алгоритмом действий.

О пожаре в Нотр-Дам-де-Пари слышали все: собор горел 9 часов, и казалось, что от этого символа Парижа ничего не останется. Ситуация вокруг его тушения вызвала самую противоречивую реакцию в сети и в прессе. Но на этом фоне пожарные продолжали действовать планомерно и профессионально, и им удалось сохранить каменную часть собора, каркас и две башни.

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

1. специальной подготовкой, наличием нормативов и алгоритма работы;

2. опытом организации спасательных работ.

То же самое можно сказать и об IT-пожаре, независимо от того, случился он на проекте с вашей внутренней командой или вам предстоит тушить его с командой вендора.

Пережив не один дедлайн, мы в компании Umbrella IT пришли к выводу о том, что для тушения пожаров на IT-проектах нужна не просто выделенная группа или отдельные разработчики, а специальная команда + специальные алгоритмы работы.

Остановимся на алгоритме подробнее. Мы выделили 4 основных шага.

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

Проверено опытом: первое общение антикризисного руководителя проекта со стейкхолдерами будет эффективнее, если оно пройдет в формате интервью по заранее подготовленному чек-листу. В перечне вопросов учитываются все данные по контексту проекта: с точки зрения бизнеса, процессов и технологии. То есть мы выясняем, кто основные стейкхолдеры и ЦА, чем обусловлены сроки; узнаем состав команды, какие инструменты используются на проекте; собираем информацию по инфраструктуре, используемым технологиям, системам деплоя/автотестирования.

Отдельное внимание уделяется возможным блокерам: как внешним (вендоры, партнеры), так и внутренним (бюджеты, безопасность) с учетом блокеров для подключения пожарной IT-команды (регламенты, инфраструктура). Такому первичному обсуждению мы, как правило, отводим 1-2 часа. Это немало в условиях срочности, но это время необходимо, чтобы перераспределить ресурсы и составить план действий.

После того, как определен основной объем задач, антикризисному руководителю необходимо сформировать пожарную команду, основываясь не только на технической квалификации специалистов, но и на софт скиллах. Это важный момент: пожарной команде необходимо будет быстро адаптироваться к процессам и работать с основной командой проекта в условиях, когда счет идет на часы. Все, что описано выше, должно происходить в течение первых 24 часов.

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

Когда известны задачи, поставленные перед пожарной командой, антикризисный руководитель проекта совместно с проектной командой должен отобрать критически важный функционал — не с точки зрения технологий, а с точки зрения бизнеса, и скорректировать приоритеты. Важно делать резервные копии кода, всех возможных окружений, инфраструктуры, а также параллельно подключать QA-команду для того, чтобы выделить и зафиксировать объем критических недоработок и багов и обозначить возможные риски. А дальше — работа над задачами

Проверено опытом: “Даже если команда знает, что и как нужно делать, мне все равно придется контролировать каждый их шаг и решение”, — если вы руководитель, то примерно такая мысль сейчас крутится у вас в голове. Регулярный контроль никто не отменял, но если у пожарной IT-команды есть собственный внутренний контроль со стороны задействованных в горящем проекте директоров, микроменеджмент для вас сводится к минимуму.

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

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

Проверено опытом: Основной алгоритм служит базой, которую необходимо кастомизировать под конкретную ситуацию. Допустим, что крупный проект разрабатывался 6 месяцев, до дедлайна осталось 2 недели, а готово только 60%. Сроки критичны, понятно, что функционала слишком много, и антикризисный руководитель проекта предлагает варианты обходных решений:

• упрощение функционала и его реализации
• приоритизация функционала
  
• использование готовых библиотек и модулей
  

Например, перед медиа-компанией Stylecaster стояла задача в сжатые сроки разработать лендинг с parallax-эффектами для рекламной кампании на Неделе моды в Нью Йорке. Для того, чтобы успеть до дедлайна и не потерять в качестве, на старте вместе с командой клиента приоритезировали задачи: отобрали максимальное количество страниц, которые были критичны для успеха рекламной кампании. Работали почти круглосуточно: для этого привлекли вторую смену с нашей стороны и были на связи 24 часа в сутки, чтобы можно было в любой момент оперативно подключить нужного специалиста (например, DevOps). Задача была выполнена в срок.

В другой ситуации на проекте для компании Iristel (Канадская телекоммуникационная компания, на рынке с 1999 года) возникла необходимость перевести CMS на французский язык, и при этом было критично уложиться в сроки запуска. Задача осложнялась тем, что существовавшая CMS не поддерживала многие опции, например, мультиязычность. Подключили c нашей стороны CTO для ревью архитектуры и кода. Аудит выявил ошибки, которые было сложно исправить. Вместе с заказчиком было принято решение внести критичные изменения в архитектуру, переписав CMS на фреймворке Symfony. Чтобы успеть к релизу, подключили пожарную команду разработчиков.

Еще в школе нас всех учили, что если случается пожар, нужно вызывать пожарных. И мы все помним этот важный номер телефона. Но по каким-то причинам, когда пожары случаются на работе, считается, что их можно потушить собственными силами.

Зачастую, когда проект горит, нет времени на то, чтобы вводить в курс дела новых людей и ждать, пока они адаптируются к работе. Отсюда и уверенность, что проще справиться самим, и вполне резонные вопросы: будут ли те, кто придут тушить со стороны, входить в контекст проблемы? Где гарантия, что они не сделают хуже? И не получится ли так, что они будут дольше разбираться в чем суть, чем тушить?

Нивелировать эти и другие риски можно, если вы заранее найдете таких людей, подпишете соглашение о неразглашении, обсудите условия совместной работы, передадите основные доступы, и тем самым существенно облегчите себе жизнь и увеличите вероятность того, что в критической ситуации не будут сорваны сроки. Таких команд у вас может быть в запасе несколько, и мы будем рады стать одной из них.

Вы сможете подключать такую пожарную команду не в последний момент, а когда только появились первые признаки “возгорания”: первые срывы сроков, первые переносы релизов, предстоящие продолжительные праздничные дни, сезон отпусков или период массовых больничных.

Автор: Вероника Годенкова, служба заботы о клиентах, Umbrella IT