Конспекты докладов ProductSense Stories. Пролог. 9 июля 2020 года

Процессы разработки в Basecamp, эксперименты в дейтинге, триады в Atlassian и работа с бэклогом в Acronis — второй день конференции ProductSense Stories. Пролог.

Оглавление

 

Подход к организации работы

Ryan Singer, Basecamp

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

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

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

Поэтому мы решили отказаться от двухнедельных спринтов и вообще пересмотрели подход к созданию чего-то нового. Мы начинаем не с проектирования, а со сроков. Сколько времени мы готовы уделить фиче? Шесть недель? Отлично — тогда мы беремся за это. Но если за шесть недель мы не доделаем фичу, мы от нее откажемся. Это создает дополнительный стимул заканчивать все вовремя.

После этого команда приступает к проектированию, обсуждает дизайн. Концепт фичи объясняется достаточно легко — он и не слишком абстрактный, и не слишком конкретный. Должно быть много пространства для творчества. Методологии для создания такого концепта называются Breadboarding и Fat Market Sketching (подробнее — в четвертой главе книги Райана). Выбираем тот подход, который позволит уложиться в сроки. Все ненужное отсекаем.

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

 

Да помогут вам цифры: эксперименты в одной из крупнейших компаний в сфере знакомств

Suhas Vadyaraju, Badoo

MagicLab создал три продукта с пользовательской базой более 500 млн человек. Делать продукты для больших аудиторий сложно. У них есть свои особенности:

  • география;
  • демография;
  • культура;
  • образование.

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

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

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

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

 

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

Василий Рудоманов, Acronis

Раньше наш бэклог формировался заказчиками из разных отделов: продуктовая команда и директора, отдел продаж, отдел по работе с клиентами, R&D. Все было достаточно просто — каждой фиче в Jira выставляли приоритет от 1 до 5, а потом там же проводили голосование. Такая схема работала первые несколько лет, но когда в бэклоге стало более 50 эпиков мы поняли — надо что-то менять.

Мы разделили нагрузку следующим образом:

  • 25% на расширение бизнеса;
  • 45% на удовлетворение существующих клиентов;
  • 30% на технический долг и срочные задачи.

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

Мы используем специальную формулу Feature Score formula, чтобы получить оценку задачи.  У каждого критерия есть таблица с возможными числовыми значениями. Такая оценка позволяет сформировать бэклог для каждой категории и не превысить допустимую норму.

В конечном итоге у нас появляется хорошая дорожная карта.

 

Как продолжать движение и поддерживать ценность в глазах клиента, если вашему продукту уже 18 лет

Дмитрий Меликов, Atlassian

Первую версию Jira мы запустили в 2002 году в Сиднее. В том же году ЕС ввел в оборот евро, вышла вторая часть «Властелина колец» и все пересели на Windows XP. В общем, наш продукт — достаточно старый.

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

Представьте: вам нужно внести изменения в конструкцию самолета прямо в полете, когда пассажиры наслаждаются отдыхом в бизнес-классе. Как это сделать?

Во многих компаниях продуктовые команды быстро движутся вперед, оставляя за собой огромный слой технического и UX-долга. Все это постоянно копится и нет времени разбирать завалы — а потом уже проще переписать функции с нуля. А все потому, что менеджер продукта драйвит бизнес. Это правильно, но есть и другой путь.

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

Любые решения мы фиксируем в Confluence, нашей внутренней wiki. Это полезно — можно в любой момент вернуться и посмотреть, кто принял то или иное бизнесовое или техническое решение и какими критериями тогда руководствовались.

Еще хочу поделиться, как в свое время, работая в офисе, я очень удивился одной вещи — везде были расклеены стикеры. Какой-то хаос, бардак. Я думал — ну как такое возможно? А потом погрузился в процесс: мне дали стопку распечатанных фидбеков от пользователей, попросили отобрать самые важные, выписать на стикеры и повесить на доску.

Я сразу ощутил ценность этого процесса: вокруг творческая атмосфера, много людей, все знакомятся и глубоко погружаются в продукт. Так приходят неожиданные решения. Также мы практикуем групповые события с Atlassian Playbook: обсуждаем достижения и провалы, делимся опытом со всеми коллегами. А еще у нас классные мобильные столы. Офис становится гибким — просто взял стол и передвинул в любой кабинет.

В целом, бизнес-подход у компании изменился с громоздкого B2B на DIY («сделай сам»), когда решения об использовании наших продуктов идут снизу, а не сверху. И цикл принятия решений занимает не год, а примерно три месяца.

За подготовку материала благодарим Адмета Акхтера, Technical Product Manager в компании Froot.kz, автора блога «Expecto Productum!».