[Управление проектами, Growth Hacking, Управление продуктом, Карьера в IT-индустрии] Как мы в компании умудрились провести 200+ экспериментов в год и зачем это было нужно

Автор Сообщение
news_bot ®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

Создавать темы news_bot ® написал(а)
02-Апр-2021 11:32

За более чем 8-летний опыт работы в продакт-сфере я работала на разных позициях: маркетологом, аналитиком, продакт-менеджером. Меня зовут Анастасия Бурдыко и я уже около года занимаю должность продакт-лида в Growth ветке Parimatch Tech. Совместными усилиями всей команды мы провели 200+ экспериментов, протестировали новый функционал, улучшили продукт и бизнес-результат. И по-прежнему продолжаем активно расти и развиваться. Так почему это столь важно? Перед тем как внедрять новые фичи и улучшать продукт, я считаю, что необходимо здраво оценить вероятный уровень эффективности. Это делается во избежание пустых время- и финансовых затрат. На кого ориентирована данная статья? Владельцы, генеральные директора и продакт менеджеры, желающие сэкономить месяцы разработки и сотни тысяч долларов на проверке своих гипотез, определенно почерпнут для себя что-то полезное. Благодаря экспериментам все можно сделать максимально дешево и быстро. Такой подход к работе стал повседневностью в моей команде. Интересно? Значит, поехали дальше?

Эксперименты и способы их запускаЧто ж, эксперименты — экономный, эффективный и простой способ проверки гипотез. Я абсолютно убеждена, прогресс невозможен, если он полагается только на одну лишь веру в идею. Во-первых, я считаю, вы должны получить хоть какое-то понимание, сработает ваша затея или нет, прежде чем переходить к ее масштабированию. Продуктовые компании время от времени начинают задумываться об эффективности новой функции, быстро переходя к ее внедрению, при этом, уделяя минимум времени проблеме и ее решению. Например, кто-то из руководства подсмотрел у конкурентов или других продуктов какую-то заманчивую функцию и захотел реализовать то же самое для своего бизнеса. Но нет понимания, какую именно ценность это решение принесет конкретному пользователю и принесет ли вообще что-нибудь. В этом случае мы не видим закрытия потребности, есть лишь желание что-то создать/ добавить. Однако, случается и так, что вы уже можете хоть примерно обрисовать проблему или нащупать потребность, но не можете определить эффективность функции, пока она не будет полностью актуализирована. Такое тоже случается. Но в большинстве случаев, вы всегда можете найти способ протестировать новшество перед его внедрением в производственную среду, не уничтожая свой бюджет и не нарушая дедлайны.Ошибка — всего лишь опыт. Если не тестировать новые гипотезы и не придумывать решения, качественный и быстрый рост просто не реален. Основоположная база экспериментов побуждает нас не только обнаруживать проблемы с продуктами, но и находить самые нестандартные решения. Поэтому, даже если во время эксперимента что-то пошло не так, не зацикливайтесь на своей «неудаче», сделайте полезные выводы и двигайтесь дальше. Но что же мешает компаниям проводить эксперименты? Основная проблема — нет времени на этот процесс. Вторая причина в том, что распорядок дня команды попросту не предусматривает такого рода деятельности.Многие думают, что проведение экспериментов в компании проходит следующим образом: «Смотри, у меня тут возникла мега-классная идея. Глянь, все ли работает». Это не имеет ничего общего с действительностью. Эксперимент предусматривает простой и оптимизированный процесс. Его основной принцип — четко определять цели, формировать гипотезы, тестировать их и сосредотачиваться на улучшении бизнес показателей, на которые вы хотите повлиять.
Каждый эксперимент состоит из четырех основных компонентов: гипотезы, действия, сбор данных и выводов. Мы выводим теорию, проверяем ее, внимательно изучаем полученный результат и приходим к определенному итогу.Наша командная работа построена таким образом, что мы совместно приходим к новым идеям. Для начала, определяем область роста продукта: проводим групповое занятие, рассматриваем нововведение со стороны пользователя и разбираем функционал продукта, имеющий непосредственное влияние на показатель, который мы хотим улучшить. Затем встречаемся с другими командами, демонстрируем, какие проблемы были обнаружены и какие решения мы можем предположить. Проводим коллективный мозговой штурм и вносим коррективы. После, расставляем приоритеты для всех гипотез в соответствии с критериями системы ICE — влияние, уверенность и простота реализации. При этом, следует помнить, что последнее условие основное. Если эксперимент ориентировочно потребует больше 5 дней, то growth-команды могут запросто отказаться от его реализации.  Разработчики — ключевой элемент, участвующий в проведении экспериментов. Это ребята, которые отвечают за техническую часть. Они не только активно генерируют идеи, но и играют важную роль в расстановке приоритетов и реализации фичи. До недавних пор, в ряду нашей команды были исключительно front-end-разработчики, так как мы тестили эксперименты только на фронте и передавали их core-командам для дальнейшей реализации. Сейчас у нас появился back-end специалист, поэтому теперь мы можем грамотно внедрять проверенные готовые решения непосредственно в продукт.  Практическая часть – как все работаетЧасто сотрудники не верят в эффективность эксперимента: они уверенны, что все и так работает замечательно, а затем искренне недоумевают из-за «неожиданных» результатов. Вот пример из жизни. Банальная ситуация, при регистрации на нашем сайте пользователь должен создать пароль, но при этом не было точных инструкций, какие символы нужно вводить. Когда мы попытались обсудить это с разработчиками, они сказали: «Ну что тут сложного? В углу страницы есть вопросительный знак, и любой может, нажав на него, прочитать уточнение, если что-то настолько не очевидно».Однако мы решили запустить эксперимент и создать более информативно-структурированное  разъяснение пароля, где объяснялось, какие символы необходимо использовать для завершения регистрации (одна маленькая буква, одна заглавная и одна цифра). Результат превзошел все ожидания! За 2 часа нам удалось достичь + 64% к показателю конверсии при регистрации.Другая история уже про экспериментирование с необходимостью повышения минимальной пользовательской ставки. Компания не была в восторге от этого эксперимента. Все думали, что такие действия приведут к негативным последствиям. Но мы рискнули и запустили эксперимент с небольшим количеством участников.И никаких негативных последствий не было обнаружено. Наш саппорт не закидывали звонками и тухлыми помидорами. Все было более чем наглядно: мы осознали глубину ошибочных предположений о реакции юзеров, и насколько такое узкое мышление может тормозить прогресс. Поэтому, очень важно набраться смелости, чтобы опробовать все эксперименты, даже самые рискованные. В случае с последними, лучший способ проверить, как все работает, — использовать небольшое количество пользователей.Следуя этому простому совету, мы перестаем быть теми, кто просиживает штаны в офисе, свято веря, что они уже давным-давно все знают. Мы признаемся, что не можем знать наверняка, как пользователи будут себя вести, и каждый раз, проверяя новые гипотезы, делаем выводы и улучшаем продукт на основе практического опыта.Почему неудачи часть успеха У некоторых компаний есть идеология, которую можно описать так: «Если ты совершаешь ошибку — ты некомпетентен». В нашей компании другие принципы. Мы легко можем смириться с неудачей, особенно во время экспериментов. Сделав несколько ошибок, мы точно узнаем, работает наша гипотеза или нет, и получим ли мы возможность показать еще более крутой результат. Таким образом создается культура реальных результатов вместо смелых предположений. Провальные эксперименты зачастую возникают, когда вы приступаете к работе с новыми функциями, с которыми ранее не имели дела. Например, одним из недавних экспериментов была попытка активации пассивной аудитории. Наша команда никогда с таким не сталкивалась, и, соответственно, у нас был нулевой опыт. Мы наивно полагали, что с помощью приложения сможем сразу же поймать необходимую аудиторию. Для решения этой задачи мы выгрузили всех «безжизненных» пользователей, разбили их на группы и запустили тест. Но оказалось, что установить эффективную связь было невозможно без привлечения их в продукт имейлами или смс, то есть без дополнительной коммуникации.
Было решено сосредоточиться на тех, кто в течении прошлого месяца посещал сайт менее двух раз в неделю. Они были предварительно выгружены из базы данных, и половина из них приняла участие в тестовой группе (где мы добавили новый функционал), а другая половина в контрольной, где его не было (классический аб тест). За время его проведения сайт посетило очень мало людей, которые должны были из предустановленного сегмента.  Основной вывод - это то, что пользователей, которые редко заходят, на сайте не словишь без дополнительного стимула на него зайти. К огромному счастью, мы никогда не сталкивались с неудачными экспериментами, после проведения которых наши показатели производительности падали. Под провальными экспериментами подразумеваются те, которые не принесшие в результате улучшения, в которые мы свято верили.Мы не теряем много денег на таких неудачах, поскольку цена ошибки покрывается стоимостью оперативной командной работы. Так как мы стараемся проводить небольшие и краткосрочные эксперименты, мы не тратим целое состояние на запуск определенной функциональности. Крупномасштабные эксперименты даже не отправляются в рабочий процесс. До тех пор, пока мы не будем уверены, что наша гипотеза сработает, мы отказываемся от пустых месяце-затрат разработки и выбрасывания бесконечных бюджетов на полный запуск новой функции. Поэтому, в таком ключе, провалы в экспериментах как экономят, так и приносят новые средства для компании.Важно не только учиться на ошибках, но и делиться своим негативным опытом с другими командами. Для чего? Зачастую люди не особо задумываются над тем, почему что-то работает именно так, и не сомневаются в правильности или неправильности определенных действий. Но когда мы делимся опытом неудачных экспериментов в компании, многие начинают признавать возможность существования проблемы, которая может крыться с частности и в зоне их ответственности. Благодаря этому, другие коллеги также могут сомневаться в своих повседневных процессах и более активно тестировать новые гипотезы.Маленькие хитрости для проведения экспериментовВ итоге, я собрала несколько правил, позволяющих превратить эксперименты в обычную корпоративную практику с удовлетворительными результатами:Выстраивайте четкие цели. Это, пожалуй, ключевой компонент. Цель — совокупность улучшения показателей и увеличения количества экспериментов. Сосредоточьтесь на главном. Необходимо понять, что верно рассчитанное время для определенной метрики имеет большое значение. Например, на работу над страницей регистрации мы выделяем три месяца, а следующий триместр посвящаем другой задаче. Многие сотрудники хотят как можно скорее протестировать личные гипотезы и заимплементить само-придуманные функции. Поэтому, считаю важным удерживать внимание команды на текущем проекте, при этом не забывать правильно поддерживать индивидуальную инициативность, говоря: «Это действительно потрясающая идея, но мы не можем ее сейчас реализовать. На данный момент, нашим приоритетом является другое направление.Помните о простоте. MVP в квадрате — девиз нашей команды. Термин MVP часто используется в контексте внедрения новых продуктов. Но это также относится и к экспериментам, поскольку чем быстрее вы получите отзывы пользователей, тем скорее сможете увеличить прибыль или существенно сэкономить.Если перед нами стоит довольно обширная гипотеза, проверка которой требует больших время-затрат, мы максимально ее упрощаем и запускаем эксперимент в несколько этапов. Например, для того, чтобы понять насколько сильно пользователям понравятся нововведения, мы можем имитировать их. Маленький процент нашей аудитории получает доступ к улучшенному интерфейсу с новыми функциями, с которыми они могут взаимодействовать до определенного этапа, после чего увидят сообщение: «Извините за неудобства, идет разработка». Благодаря этому, мы можем лучше понять и рассчитать, как пользователи реагируют на новые функции. Если они будут заинтересованы и активны, мы продолжим нашу работу, подключив серверную часть, в ином же случае — не будем зря тратить ресурсы.Нацельтесь на улучшение своих показателей. Когда люди участвуют в запуске инноваций, они, как правило, выполнив свою часть работы, скороспешно переключаются на другое задание, не утруждаясь проверить результат и отследить определенные показатели. Например, они обязуются запустить функции A, B и C через шесть месяцев. После того, как А была готова и запущена в продакшн, никто может и не заметить, что функция нерабочая. Такое происходит по причине того, что целью являются сами нововведения, а не улучшение метрик и конкретных бизнес-показателей. Если же все, наоборот, и результаты всегда имеют приоритет, то и разработка продукта воспринимается как ответственный и трудозатратный процесс, который требует постоянной переоценки того, на чем вам нужно сосредоточиться в данный момент. Значит, нацеливаясь на метрики, вы сможете выстроить правильный курс. Где живут гипотезы и почему так важно превратить их в рутинуЕсли принцип подбора гипотез выглядит так «На днях увидел классную фитчу, думаю, она может сработать и у нас», то никакого результата вам не видать. Очень важно определить, где заканчивается зона разработки продукта и что именно вы хотите усовершенствовать. Помимо аналитики конкурентов и метрик продукта, существуют и другие места и вдохновители для создания новых гипотез. Вот что лучше всего подходит для нас:Исследование пользователей — рутина. Например, ребята из нашей команды завели традицию по пятницам устраивать двухчасовые встречи с пользователями, для получения обратной связи. Подобного рода занятия довольно трудно перевести в рутину, но все же это вполне реально и действительно здорово работает. Ваши пользователи — настоящий ящик Пандоры для генерирования новых гипотез. За каждым нашим успешным экспериментом стоит вовремя полученная обратная связь.  Каждая идея имеет значение. Сотрудники компании — главные движущие силы экспериментов и творцы новых идей. Мотивируйте коллег подавать идеи по улучшению продукта, но помните, что игрой всегда управляете вы. Дайте четкое понимание, над какой областью продукта вы работаете в данный момент и какой у нее дедлайн, и используйте в работе только релевантные предложения. Давайте сделаем выводыЭксперименты дают компании уникальную возможность максимально быстро, эффективно и безболезненно протестировать идеи по улучшению продукта. Перед запуском новой важной функции, по моему опыту, лучше всего убедиться, что она вообще для кого-то актуальна. Более того, эксперимент, как часть рабочего процесса, допускает даже совершение ошибки, так как каждая неудача рассматривается как защитный барьер от бессмысленной траты крупных денежных средств компании. И разумеется, именно эксперименты демонстрируют реальный результат работы целой команды, совершенствуя все этапы разработки и внедрения гипотез. Так что, экспериментируйте и не забывайте делиться своим опытом в читателями. Надеюсь, вам было полезно узнать, как мы экспериментируем в Parimatch Tech, буду благодарна за любой фидбек в комментариях.
===========
Источник:
habr.com
===========

Похожие новости: Теги для поиска: #_upravlenie_proektami (Управление проектами), #_growth_hacking, #_upravlenie_produktom (Управление продуктом), #_karera_v_itindustrii (Карьера в IT-индустрии), #_vladelets_produkta (владелец продукта), #_mvp, #_proverka_gipotez (проверка гипотез), #_zapusk_novogo_produkta (запуск нового продукта), #_startap (стартап), #_blog_kompanii_parimatch_tech (
Блог компании Parimatch Tech
)
, #_upravlenie_proektami (
Управление проектами
)
, #_growth_hacking, #_upravlenie_produktom (
Управление продуктом
)
, #_karera_v_itindustrii (
Карьера в IT-индустрии
)
Профиль  ЛС 
Показать сообщения:     

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 13:43
Часовой пояс: UTC + 5