Предновогодний квест: как подготовить ИТ-проекты, чтобы отметить Новый год с семьей, а не с командой
Рабочий год подходит к концу. Все, как могут, подводят итоги старого года. Команды придумывают, как объединиться в онлайн-формате. А внутри команды кипит работа по подготовке проектов к новогодним праздникам.
Меня зовут Станислав Беленов, я в тестировании около 9 лет и сейчас расскажу, как мы вместе с командой готовили разные проекты к новогодним праздникам.
По своему опыту работы в разных командах могу сказать, что каждый проект заканчивался по-разному: некоторые пытались закрыть все цели MVP к моменту наступления следующего года, и тогда новогодние праздники ждешь очень трепетно. Есть опыт работы в команде, которой удавалось без паники правильно оценивать объемы работ и в предпраздничные дни уже можно было думать о новогодних делах.
Я расскажу о позитивном, на мой взгляд, и негативном, также на мой субъективный взгляд, подходах к разработке и тестированию в предновогоднюю пору.
3 способа подготовки проектов к новогодним праздникам
1. Замораживание кода за 2 недели до праздников
За 6 лет работы в финтехе на разных проектах процесс разработки приложений в новогодние праздники закладывался при квартальном планировании. Осознанно или нет, управленец проектом закладывал чуть больше времени на задачи, которые приходились в предпраздничные дни. Да и сами задачи имели важность меньше, чем обычные. Теперь по прошествии времени кажется, что это правильная стратегия.
Одной из наиболее добротных стратегий, субъективно мое мнение тестировщика, является запрет на поставки в боевые среды за 2 недели до праздников. Запрет на изменение боевого кода согласовывали между собой заказчик, менеджер и команда. Совместно выбиралась дата, после которой происходила заморозка кода. Бывали случаи, когда эту дату называл отдел безопасности, такую дату не могли сместить ни менеджеры, ни сами заказчики.
К плюсам этой стратегии можно отнести:
- Никаких лишних поставок и лишнего тестирования в этот период не происходит. Мне, как тестировщику, особенно приятно, что можно отпустить горящие продукты в следующий год и спокойно заниматься редактированием тест-планов, тест-кейсов.
- Заказчик (особенно если его останавливает служба безопасности) осознает все возможности по реализации функциональностей его продукта и чаще пересматривает свои желания на поставки, чтобы иметь к назначенной дате все необходимое.
- Душевный плюс от тестировщика — начинается тесная взаимосвязь со службой поддержки. Становится легче собирать фидбэк, потому что пользователей продуктом становится больше, и от нагрузки можно посмотреть на качество своей работы с разных сторон.
- Время, которое освобождается от горячих задач, каждый член команды может использовать для завершения своих квартальных или годовых целей. Правило 80/20 работает в других пропорциях (примерно 50/50), что несомненно радует любого члена команды.
- Психологическая польза - заметно, что команда уходит от точки выгорания, если таковая была, что лучше сказывается и на дальнейшей работе в новом году над проектом, который делали весь год. Также было замечено, что каждый член команды начинает шире смотреть не только на свою роль, но и на роли других участников.
Минусы заморозки разработки тоже имеются, и, бесспорно, их надо учитывать и осознанно подходить к рискам, которые могут возникать:
- В “замороженный” код попадают не полностью протестированные или описанные модули. Неправильное планирование и постоянная смена “хотелок” заказчика может привести к тому, что за ночь до заморозки надо будет протестировать 3 модуля, 2 из которых еще находятся в разработке, а аналитик успел описать только 1. Так, на конец года пользователь имеет ограниченный или некорректно работающий функционал.
- Если возникает критический дефект, то на его устранение тратится очень много времени. И, по факту, это не время разработчика, аналитика, тестировщика. Это время, которое занимает оформление всех бюрократических заявок с содержанием: “Ну, “катить” надо срочно все, а то все упало, и ничего не работает…”.
- Возникает много сценариев, которые были не учтены даже при возникновении идей. То ли праздники, то ли жажда мандаринов, но, если проанализировать статистику пользователей в фиче с двумя и более “экранами”, можно узнать, что разрабатываемый продукт используется гораздо шире, чем в него закладывали возможности. И отсюда возникают сценарии, которые могут показать стабильность работы приложения в “новогодних условиях”.
По моему мнению, реалистичная оценка работы команды + хорошее взаимодействие с заказчиком может в достаточной степени снизить риски и позволить команде в уходящем году спокойно завершать свой годовые цели, планы индивидуального развития или заниматься обязанностями, которые откладывал на конец года.
2. Непрерывная поставка
В противоположность вышесказанному разберем сценарий бесконечной разработки, отвлекаясь ровно на 7 дней новогодних праздников с возможностью выхода из новогодних каникул в случайное-необходимое время.
Непрерывная разработка продолжается вплоть до государственных праздников, намеченный план на спринт или квартал заканчивается ровно 31 декабря, за несколько часов до боя курантов.
Плюсы такой разработки:
- Фичи могут выходить вплоть до последних дней года и даже есть автоматические, которые открываются после сразу праздников. Что позволяет пользователям быть вовлеченными в работу продукта и не терять заинтересованность.
- Планирование времени позволяет сохранять баланс разработки, аналитики и тестирования. Вся команда вовлечена в продукт до конца реализации функциональности или вплоть до прихода Деда Мороза, что, конечно, дает большой потенциал для работы команды.
- Дефекты, которые могут быть обнаружены пользователем, или “внезапное” изменение дизайна (функциональности) продукта могут быть реализованы без большой вереницы согласований.
- Вся команда вместе встречает Новый год, пусть под гнетом новых фич и новых прилетающих дефектов, но вместе, в своем рабочем кругу.
Непрерывная разработка хоть и приносит новые фичи для заказчика и пользователей, но имеет ряд отрицательных качеств:
- Тестировщик из-за возросшей активности службы поддержки начинает сдвигать по времени тест-планы, что ведет к возможным пропускам критических дефектов. А чем больше находят дефектов пользователи, тем хуже подарок тебе принесет Дед Мороз.
- Напряжение, которое испытывает инфраструктура в предновогоднее время, плюс разработка и тестирование новых фич сильно нагружает мощности оборудования, что может привести к “зависанию” или отклонению функциональности продукта от его назначения.
- Напряжение, которое испытывает связка заказчик-менеджер-команда, возрастает. Пусть такая связка продуктивна, но к выгоранию последние 2 недели уходящего года могут привести быстрее, чем 3 месяца работы до этого.
- Новый год начинаешь отмечать со своей командой, а хотелось бы быть с семьей.
Пропуская цикл разработки продукта взамен желанию “выкатиться точно 31 декабря и никак иначе”, можно столкнуться с большим негативным опытом пользователей, который, несомненно, оставит плохой осадок и на команде, и на продукте.
3. Гибридная разработка
Гибридная разработка, основанная на индивидуальных подходах к продукту, может стать вполне полезным решением для команд:
- Правильная приоритизация фич. Когда все крупные и значимые фичи, на момент предпраздничных дней разработаны, протестированы и имеют запланированные даты релизов. На “стрессовые” для инфраструктуры дни уходят небольшие задачи, которые не ломают работу основ продукта.
- Четкое понимание заказчика и менеджеров сроков взаимодействия с командой, со службой безопасности и другими компетенциями для внесения изменений в уже работающий код.
- Возможность команды работать над фичами или бэклогом без напряжения, потому что все уверены, что не будет внезапных новых “пожеланий”, что дает возможность размеренно достигать поставленных целей.
- Перенести позитивный опыт пользователей в новый наступающий год.
- Выход из праздников не с “горячей” головой, а с равномерным входом в работу. Чтобы успеть соскучиться по команде, с которой будешь работать еще год!
Для каждого продукта своя уникальная стратегия. Надеюсь, статья была полезна. Всех с наступающим Новым годом!