Как проджект-менеджеру пережить стрессовый релиз

Не все релизы одинаково сложные — всё зависит от проекта. По шкале стресса, где 10 — это кошмар, регулярный релиз может соответствовать двойке. Но бывает, когда уровень стресса — 15: страшно проджект-менеджеру, страшно команде, страшно заказчику. Как пережить такой релиз рассказывают Надежда Абашева и Алексей Коростелев, проджект-менеджеры IT Test.

В этом году мы запустили сайт клиента в майские праздники — заказчик из США, где эти дни не выходные, попросил зарелизиться раньше, чем договаривались. Это был первый релиз перспективного крупного проекта, и мы на это пошли: с конца апреля команда работала в авральном режиме. Такое редко случается в IT Test, однако опыт оказался полезным, и мы хотим им поделиться. Вот, к чему нужно быть готовым проджект-менеджеру во время стрессового релиза.

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

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

Если проект требует переработок, мы договариваемся о компенсации — финансовой или дополнительными выходными. Но еще один важный момент — проджект-менеджер работает наравне со всеми.

Команда живет по принципу «Один за всех и все за одного» — если произошел форс-мажор, справляемся с ним все вместе. Это помогает сотрудникам чувствовать, что они не одни, и растит доверие к проджект-менеджеру.

Уровень стресса во время релиза зависит от степени неопределенности — успеем или не успеем, получится или не получится. Эту тревогу помогает снизить тщательная подготовка на первых этапах.

Может прозвучать очевидно, но проджект должен заранее запросить у заказчика все доступы и, если это релиз приложения, все материалы для сторов. Убедиться, что все члены команды знают о дате релиза и своей роли в нем, а если релиз запланирован на выходной — что все будут на связи.

Хорошая практика — составлять для себя список задач. Он может отличаться в зависимости от проекта, но в самом общем виде задачи проджект-менеджера перед релизом выглядят так.

1. Готовность нового функционала

• проверить, что версия, которая пойдет в релиз, тщательно протестирована, замечаний нет или они не критичны, принято решение о стабильности системы и релизе в таком состоянии.

2. Готовность прода к релизу

• убедиться, что всё готово для запуска нового функционала, все доступы получены и проверены;
• если речь про мобильные приложения, на его странице в сторе есть вся нужная информация.

3. Готовность команды

• все сотрудники знают о релизе, его дате и своей роли в нем;
• подготовлен конкретный план действий;
• если релиз запланирован на выходной, все будут на связи.

4. Готовность пользователей системы

• пользователей нужно предупредить о новом релизе, если система на момент развертывания будет недоступна для нормальной работы;
• подготовлены Release Notes — список обновлений в новой версии;
• заказчики знают о проведении работ, особенно если система на какое-то время станет недоступна.

Больше экспертных материалов о заказной разработке, дизайне и тестировании в Telegram-канале IT Test.