Тема дня: Проверка фич и статистика.

Довольно частый вопрос: «Как вы проверяете фичу»? Мне кажется, что прежде всего надо проверять не каждую фичу, а продукт в целом.
Статистика по продукту должна собираться автоматически и отображаться в легком для интерпретации виде. Зашёл на дашборд, посмотрел, всё понял. У меня есть дашборд с воронкой, дашборд с ретеншном, дашборд про деньги и т.п. А еще есть дашборд про быстродействие.
Старики говорят: «За двумя метриками погонишься — ни одну не улучшишь». Невозможно улучшать все продуктовые метрики одновременно. Лучше сосредоточиться на чем-то одном. Как минимум, в течение 2-3 месяцев. Например улучшать количество первых платежей. Или увеличивать средний чек.
О какой продуктовой метрике может идти речь, если у нас рефакторинг и мы меняем стек? У моей команды как раз такой период. При этом у нас критерий успеха — количество первых платежей. Наша цель — их не уронить нашим рефакторингом. Очень хорошая цель!
Не важно, какие BI системы вы используете. Главное, чтобы вам нравилось. Мы, например, собираем данные через OWOX, а продуктовые дашборды конструируем в Tableau. Для сбора технических данных и дашбордов активно использовали Splunk. Сейчас для техники что-то другое.
О продактах и аналитиках. Наши аналитики супер умные ребята и девчата. Мне до них далеко во всем, что касается SQL, алгоритмов и статистики. Но им нужно подробно ставить задание, что именно мне нужно. Польза аналитического дашборда во многом зависит от квалификации заказчика.
Какую статистику собирать и как ее отображать? Все придумано до нас. Но в обилии информации легко потеряться. Мне повезло работать с опытными людьми — могу подсматривать. Если у вас нет таких коллег, пригласите специалиста в ресторан и пока жарят стейк, откройте ноутбук.

• • •

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
Итак, ответим на частый вопрос: «Как вы проверяете фичу»? Ответ: «Головой». К сожалению мне не известен универсальный алгоритм для проверки эффективности фичи. Все фичи разные, и анализировать их надо по-разному.
Технически я проверяю фичи через 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}
Read 11 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!