Процессы разработки в Basecamp, эксперименты в дейтинге, триады в Atlassian и работа с бэклогом в Acronis — второй день конференции ProductSense Stories. Пролог.
Оглавление
- Подход к организации работы. Ryan Singer, Basecamp
- Да помогут вам цифры: эксперименты в одной из крупнейших компаний в сфере знакомств. Suhas Vadyaraju, Badoo
- Как расширить бизнес, удовлетворить клиентов и справиться с техническим долгом в одной дорожной карте? Василий Рудоманов, Acronis
- Как продолжать движение и поддерживать ценность в глазах клиента, если вашему продукту уже 18 лет. Дмитрий Меликов, Atlassian
Подход к организации работы
Ryan Singer, Basecamp
Годами мы вырабатывали свой подход к продуктовой разработке, и в какой-то момент мне предложили написать об этом книгу. Но для начала я решил пригласить людей и провести воркшоп. Так и началось распространение нашего подхода.
Мы заметили — основная проблема компаний в том, что они начинают придумывать фичу, проектируют ее, дизайнят, кодят и сразу переходят к следующей. Со временем команды становятся опытнее, появляется больше людей, но все процессы замедляются.
Традиционно менеджер приходит с готовым детализированным проектом, спрашивает, сколько времени понадобится на разработку, получает ответ и процесс запускается. Двухнедельные спринты теряют эффективность, потому что за две недели нельзя сделать ничего до конца.
Поэтому мы решили отказаться от двухнедельных спринтов и вообще пересмотрели подход к созданию чего-то нового. Мы начинаем не с проектирования, а со сроков. Сколько времени мы готовы уделить фиче? Шесть недель? Отлично — тогда мы беремся за это. Но если за шесть недель мы не доделаем фичу, мы от нее откажемся. Это создает дополнительный стимул заканчивать все вовремя.
После этого команда приступает к проектированию, обсуждает дизайн. Концепт фичи объясняется достаточно легко — он и не слишком абстрактный, и не слишком конкретный. Должно быть много пространства для творчества. Методологии для создания такого концепта называются Breadboarding и Fat Market Sketching (подробнее — в четвертой главе книги Райана). Выбираем тот подход, который позволит уложиться в сроки. Все ненужное отсекаем.
Получается, что менеджер продукта фокусируется не на людях, которые уже четко знают, что и когда им надо делать, а на более важных вещах — стратегии продукта и т.д. Обычно все остаются довольны результатом, потому что команде удается сделать нечто действительно стоящее, что оправдывает потраченные время и силы.
Мы пишем о менеджменте продуктов и развитии в телеграм-каналах make sense и Продуктовое мышление.
Да помогут вам цифры: эксперименты в одной из крупнейших компаний в сфере знакомств
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!».
