Рецепт: готовим проект к заморозке

В статье «Как заморозить проект но не отморозить команду» я рассказывала как МРу поддержать разработчиков и себя. Теперь я расскажу про наши действия по пунктам из плана, который я приводила в той же статье:

• Довести до релиза задачи, которые сейчас в разработке
• Перекопать бэклог и решить, что мы успеем сделать до того, как команда будет распределена на другие проекты
• Четко определить, что значит «продукт на поддержке»

Итак, чтобы подготовить продукт к заморозке, вам нужно:

Отрезать лишнее

Конечно же, в момент, когда команде стало известно о заморозке, у нас были задачи в работе. И конечно же, на разных стадиях готовности.

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

• нужное — доводим до релиза
• ненужное — не делаем, возвращаем задачу в бэклог
• по остаточному принципу — сделаем, если хватит времени

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

1. Сколько нужно времени, чтобы доделать задачу?

Мы пристально посмотрели на задачи в in progress, и поняли, что в новой реальности не сможем завершить их все. Часть задач решили убрать из плана работ.

Определяли их таким образом:

1. Если задача была частью эпика, на разработку которого требовалось ещё несколько месяцев — мы её убирали. И это был наиболее важный фактор.
2. Если по задаче не закончена аналитика или по ней не начали прорабатывать UI — убирали.

2. Эта задача будет полезной для пользователей/админов сервиса?

1. Если задача представляла собой инфраструктурные или бизнесовые улучшения, которые позволяли увеличить отказоустойчивость сервиса — оставляли.
2. Если задача снижала зависимость работы внедрения и техподдержки от команды разработки — оставляли.

3. Насколько задача дестабилизирует сервис?

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

4. А если «с горкой»?..

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

Так как у фронтендера и проектировщика не осталось приоритетных задач из списка in progress, мы решили взять в работу обновление интерфейса, и за месяц затащили в сервис необходимый минимум обновлений.

В бэклоге мы нашли несколько запросов на улучшение админки, и решили выполнить и их тоже. Это позволило админам сервиса (внедренцам, техподдержке и продавцам) пользоваться расширенным набором настроек организаций, который раньше был доступен только разработчикам. Благодаря этим доработкам бизнес-команда получила возможность настраивать контрагентов самостоятельно, не привлекая команду.

—

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

Так мы определили для себя срок перевода проекта на поддержку и даты для планирования будущих стажировок в новые команды.

Далее я озвучила в бизнес, что мы в течение месяца заморозим продукт.

Подготовить инструменты

Разобравшись с текущими задачами мы задумались об инструментах поддержки: документации и мониторинге. А ещё об освобождении ресурсов, которые скоро станут не востребованы. Далее по пунктам:

1. Документация

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

2. Мониторинг

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

3. Ресурсы

Без активного развития, проекту больше не требовались три тестовые среды, поэтому мы оставили один стейджинг (для демонстрации возможностей сервиса пользователям) и один тестовый сервер (для разработчиков).

4. Доступы

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

Сформировать границы

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

1. Сервис продолжает работать в том состоянии, в котором он остался на момент заморозки.
2. Правятся только критичные баги, влияющие на работоспособность системы.
3. Известные баги зафиксированы в YouTrack, и если они до сих пор не исправлены — на это были причины.
4. В разработку можно принести задачу на доработку сервиса в случае, если:

• она является следствием законодательных изменений (пример такой задачи — всем известная МЧД).
• количество запросов на выполнение задачи является достаточным основанием для того, чтобы продукт разморозить.

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

В заключение приложу оставшийся артефакт того времени: скрин доски в Miro, которая у нас получилась, когда мы с командой готовили список дел.