Итак, ответим на частый вопрос: «Как вы проверяете фичу»? Ответ: «Головой». К сожалению мне не известен универсальный алгоритм для проверки эффективности фичи. Все фичи разные, и анализировать их надо по-разному.
Технически я проверяю фичи через GA ивенты. На этапе прототипа, пишу задание разработчикам. В GA есть вложенные сущности: категории, экшны, лэйблы, вэлью. Если все действия в продукте обвешать правильно написанными ивентами, анализировать поведение пользователя будет легко.
К примеру, вот GA ивент при отправке поискового запроса (в фигурных скобках — переменные):

GA-Category: {report_name}:search

GA-Action: load:send-search-query

GA-Label: search-type: by-auto-suggestion; search-query:{search_query_text}
Такими GA ивентами мы обвешиваем все элементы интерфейса и все действия пользователя. Задание пишу я сам, потому что у меня нет выделенного «личного» аналитика, который бы знал, как именно работает продукт. Одно время писал UX, но ему было тяжеловато делать это правильно.
Когда фичу выкатили, я жду, пока накопятся ивенты. Потом иду в BigQuery, где у нас хранятся все данные, и делают SQL запрос, который мне нужен. Я очень плохо знаю SQL, но если ивенты отправляются правильно, то даже минимальных знаний достаточно.
Выше я приводил пример GA ивента для поиска. Я могу сгруппировать данные по Action и вывести список Label. И увижу, что именно ищут пользователи. С группировкой категория/экшн/лэйбл можно играться бесконечно и получать ответы на вопросы про любое действие пользователя.
В принципе, можно обойтись вообще без знания SQL. Статистику ивентов можно смотреть в интерфейсе Google Analytics. Главное правильно расставить эти ивенты. Иначе вложенность будет вас только запутывать, а не помогать.
Для меня анализ фичи — творческий процесс. Я делаю запросы, смотрю на статистику с разных сторон и делаю выводы. Эти выводы вместе с цифрами и SQL-запросами я сохраняю в текстовый документ в понятном для посторонних людей виде. Можно показать команде и всем желающим.
Текстовый документ с аналитикой по фичам я веду много лет. Он довольно большой :-) Зато когда меня спрашивают о фиче, которую мы запустили 3 года назад, я могу прислать готовые к чтению выводы и ссылки на исходные данные и SQL-запросы.
Наверное, я никому не помог в вопросе «Как проверить фичу». Возможно читатели знают более универсальные и менее творческие способы проверки. Поделитесь, пожалуйста!
Keep calm and do query.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Менеджер продукта

Менеджер продукта Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @produnderhood

25 Mar
Хорошей команду делают: профессионализм, проактивность, честность, постоянные изменения, человечность, юмор, безопасность. Разберем подробнее.
Профессионализм.
Разница в эффективности между хорошим и посредственным таксистом, пожалуй, 30%. Разница между хорошим и посредственным программистом — тысячи процентов. Хорошие разрабы сэкономят вам много времени и денег. Не все должны быть звездами, но костяк команды — должен.
Проактивность.
Современный стиль создания продукта — глубокая вовлеченность каждого в процессы. Разработчики должны понимать продуктовые задачи, дизайнеры — технические ограничения и т.п. Если человек пассивный и хочет «писать код в уголке», ему органически будет сложно работать.
Read 9 tweets
25 Mar
Тема дня: Плохая/хорошая команда.

Плохой команду делают: непрофессионализм, инфантилизм, апатичность, лень, неправильный фокус, ссоры, боязнь конфликтов. Что-то одно у кого-то одного — уже плохо. Ниже разберем подробнее. Беру из моего личного 20-летнего опыта.
Непрофессионализм.
Если разработчик плохо программирует, его не спасет то, что он отличный парень. Точнее, это еще хуже. Свой первый продукт я написал со старинным другом. После первых продаж оказалось, что код написан так плохо, что его уже не спасти. Продукт пришлось закрыть.
Инфантилизм.
Я работал со взрослыми парнями, у некоторых были жены и дети. Они часто пошло шутили над единственной девушкой в команде. Могли долго ржать над фамилией иностранного коллеги. Это была не грубость, а поведение школьников-старшеклассников. Здорово утомляет и раздражает
Read 8 tweets
24 Mar
Тема дня: Проверка фич и статистика.

Довольно частый вопрос: «Как вы проверяете фичу»? Мне кажется, что прежде всего надо проверять не каждую фичу, а продукт в целом.
Статистика по продукту должна собираться автоматически и отображаться в легком для интерпретации виде. Зашёл на дашборд, посмотрел, всё понял. У меня есть дашборд с воронкой, дашборд с ретеншном, дашборд про деньги и т.п. А еще есть дашборд про быстродействие.
Старики говорят: «За двумя метриками погонишься — ни одну не улучшишь». Невозможно улучшать все продуктовые метрики одновременно. Лучше сосредоточиться на чем-то одном. Как минимум, в течение 2-3 месяцев. Например улучшать количество первых платежей. Или увеличивать средний чек.
Read 7 tweets
23 Mar
ДЕМО — встреча в конце спринта, где мы показываем то, что сделали в спринте. Цель — получить фидбэк от всех заинтересованных лиц. Ну и конечно же похвастаться, какие мы молодцы.
Мы показываем фичи только на продакшене. Раньше многие команды выходили, показывали новую фичу на тестовом сервере и говорили «в понедельник выльем в прод». Проходило две недели, они опять выходил на демо, и оказывалось, что фича до сих пор не в продакшене.
Когда команд стало много, а стейкхолдеров еще больше, демо стало менее эффективным. На качественную обратную связь и вопросы не хватает времени. Поэтому сейчас для меня важнее написать в специальный чат о новой фиче.
Read 6 tweets
23 Mar
РЕТРО, ретроспектива — встреча раз в спринт, где команда может выяснить отношения и позитивно поконфликтовать. Есть много прикольных фреймворков, как проводить ретро. Но мы пользуемся самым простым: плюсы, минусы, голосование, обсуждение, решения.
Мы проводим ретро так. Каждый пишет на стикерах «плюсы» — что хорошего было в спринте. По очереди наклеивает на доску и поясняет на словах. Потом тоже самое с «минусами». Плюсы не обсуждаем. Минусы обсуждаем и принимаем практические решения.
Все минусы не успеть обсудить. Поэтому каждый отдает свой голос за три самых важных на его взгляд проблемы. Начинаем обсуждать проблем, которые набрали наибольшее количество голосов. Стараемся сформулировать конкретные шаги, как решить проблему. Эти решения выписываем на доску.
Read 6 tweets
23 Mar
СТЕНДАП (дэйли) — встреча на 15 минут, где каждый отвечает на вопросы: что делал, что собираюсь делать, какие есть проблемы. Проблемы не обсуждаются, а выносятся на парковку — реальную или виртуальную доску, где на стикерах записаны проблемы со стендапа.
Есть огромное желание начать обсуждать проблемы прямо на стендапе. Особенно, когда кажется, что решить их можно быстро. Не стоит этого делать, ведь у каждого выступающего есть всего полторы-две минуты. Лучше потратьте их на уточняющие вопросы.
Перейдя на удаленку, мы перестали видеться в офисе и решать мелкие вопросы между делом. Поэтому на парковке после стендапов скапливалось много проблем. Мы начинали их обсуждать после стендапа и делали это по часу. Стендап вроде 15 минут, а реально полтора часа.
Read 5 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!