Как мы закрыли форму, которой было 15 лет, и не уронили конверсию

Что я взял на себя как PM

• Управление проектом

  формирование проекта миграции и еженедельные обновления во внутренней системе управления проектами;

• Коммуникация

  настройку каналов коммуникации между участниками;

• Отчётность

  отчётность перед руководителями и другими стейкхолдерами;

• Координация команд

  координацию движения к результату и работу с межкомандными блокировками.

Неопределённость и план

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

Чтобы снизить этот риск, я составил карту стейкхолдеров, зон ответственности и принятия решений. Для каждого типа вопроса я зафиксировал:

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

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

Затем мы провели несколько встреч с командами биллинга, определили основные этапы и оценили требуемые ресурсы.

Где проект начинал буксовать

Главной сложностью были зависимости между командами. Закрыть старую форму можно было только после модернизации платёжных сценариев внутри продуктов.

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

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

Принятие решений

Чтобы удержать сроки, мы определили минимальный объём работ, необходимый для полного закрытия старой формы. Дополнительные проблемы оценивали по риску для пользователей, объёму трафика и стоимости исправления.

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

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

Контроль сроков и рисков

Общую дорожную карту вели в Monday вместе с проектами остальных команд биллинга. Руководители видели зависимости, текущий статус и связанные с этапами артефакты.

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

• Раз в неделю – встречи с разработчиками и Product Owner’ами: прогресс, блокировки и следующие шаги;
• Раз в месяц – отчёт перед всеми командами биллинга;
• Раз в квартал – общая презентация для стейкхолдеров.

Основными получателями оперативной отчётности были Head of Product и CPO.

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

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

Что получилось

Старую платёжную форму закрыли, а обязательные сценарии перенесли в новую. Она стала поддерживать основные типы покупок, дополнительные и индивидуальные предложения, триалы с промокодами и обновление платёжных данных. Новую форму также встроили в виджеты апгрейда и докупки внутри продуктов.

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

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

Первая попытка проверить новую форму через эксперимент не дала надёжного результата: данные разных метрик противоречили друг другу. После проверки аналитики эксперимент перезапустили.

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

Статистики по обновлённому MRR после того, как мы закрыли дыру с перезаписью подписок, у меня уже не было. Поэтому я не могу сказать, насколько успешно это сработало. Но сути это не меняло: форму нужно было перенести – и мы это сделали.

Что я понял о себе и роли PM

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

Мне было сложно начинать задачи с высокой неопределённостью, и я замечал, что из-за страха откладываю первые шаги. Особенно трудно было говорить о том, что срок может измениться и потребуется повторная оценка. Я понял, что задача PM – поднимать такую неопределённость достаточно рано, даже когда готового решения ещё нет.

Ещё я понял, что PM не обязан самостоятельно устранять каждую блокировку. Его задача – сделать проблему видимой, собрать нужных людей и создать условия, в которых решение может появиться. В одном из таких случаев разработчик из другой команды сам предложил помощь и снял межкомандную блокировку.