• GitHub
  • LinkedIn

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

Через эту форму проходило более 98% всех платежей сервиса.

Subscribing to Guru 1 month Recurring plan for
$199.95 monthly
Enter your billing information
Enter your billing address
Purchase Summary
Your accounthey@semrush.com
Account TypeGuru 1 month Recurring
Billingmonthly
Starting Date3 August, 2018
Price$1,499,62
GST ⓘ10% ($149,96)
Today’s Charge$199.95
Need Help? Call Us!
USToll-free
+1-855-814-4510
06:00 PM – 02:00 AM  (Moscow, Baghdad, Riyadh)
Monday through Saturday
UKToll-free
0-808-189-3160
11:00 AM – 07:00 PM  (Moscow, Baghdad, Riyadh)
Monday through Friday
You can also pay via PayPal. Click here to proceed.
* Marked fields are mandatory

Контекст

Компания трансформировала биллинговую систему, чтобы быстрее адаптировать её к новым бизнес-целям. Одной из частей этой трансформации стало закрытие старой формы оплаты.

Я взял на себя роль Project Manager этого проекта и очень благодарен коллегам за доверие. При этом я продолжал работать над проектом как Product Designer.

Цели

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

На старте

  • три команды разработки биллинга и одна команда за его пределами
  • два Product Owner’а
  • один Head of Product
  • один UX Writer
  • два дизайнера

* А ещё у нас был амбициозный проект и общее желание наконец закрыть старую форму!

Чего нам недоставало

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

С какой стороны прочитать этот кейс?

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

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

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

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

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

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

  • Отчётность

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дорожная карта проекта в Monday: этапы, статусы и зависимости

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

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

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

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

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

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

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

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

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

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

Финальный эксперимент
Попытка отправки формы58,89%→62,27%+3,38 п. п.
Успешная отправка57,04%→57,58%+0,54 п. п.
Конверсия в триал48,53%→48,48%−0,05 п. п.
Конверсия в покупку1,88%→2,15%+0,27 п. п.

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

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

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

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

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

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