Архив недели
Понедельник
Привет! На этой неделе с вами Исмаил Хамитов. Около 2-х лет назад я осознал, что на самом деле не хочу быть разработчиком, хотя и развивался в этом около 6 лет, и, преследуя продакт-менеджмент, попал в аналитику Яндекс.Браузера.
О чем планирую порассказывать:
ПН: про переход из разработки в продуктовую сферу, почему и когда важен бэкграунд инженера, личный опыт менеджмента
ВТ: как не поддаваться потоку человеческих искажений в аналитике и почему не стоит бояться быть "неудобным"
СР: про ловушки в АБ-сравнениях и интерпретациях данных
ЧТ: почему метрик нужно много и как жить в мире разнонаправленных изменений
ПТ: качественные и количественные исследования - когда нужны и как дополняют друг друга
СБ: роли в команде и взаимодействие между ними, как я вижу идеального менеджера/продакта/разработчика/QA
ВС: "стресс, переживания, неопределённость, всё горит" - эмоциональное здоровье и как удаётся не сходить с ума в этих джунглях.
Я осознал свою страсть к технологиям лет 9 назад, с появлением своего личного Android-телефона.
Понял: "я сам хочу создавать квутые пвогваммы!"
Долгое время был уверен: "программы делают программисты"
И пошел практиковаться программированию. В олимпиадах.
Всё ведь логично?🤔
Безусловно, разработка - ключевой процесс создания продукта (no offence, zero-code enthusiasts)
Но если упрощать, то во главе стоит 2 вопроса: ЧТО мы строим, и КАК мы строим
И процесс поиска ответов на эти вопросы настолько разный, что не может вместиться в одну профессию.
На прошлом месте был коллега Android-разработчик, который помог понять, почему я не на своём месте.
Его страстью было глубокое погружение в технологии, грамотное (!) их применение, улучшение процессов в команде, создание общеполезной ценности.
Смотря на его горящие глаза, я узнавал это ощущение, когда, простите за выражение, тебя раз**бывает от того, чем ты занимаешься.
А незадолго до этого я как раз очень нехило раз**бался от Podlodka Podcast #16 с небезызвестной Анной Булдаковой
soundcloud.com/podlodka/podlo…
Почему-то мне кажется, что у каждого есть моменты таких ярких эмоций от какой-либо деятельности.
А как часто вы сами испытываете их в своей деятельности?
Наверное, у всех был момент "просветления", когда тебе открываются все эти data driven подходы, кастдевы, Спроси Маму, воронки, когнитивные искажения, кто-продакт-а-кто-проджект, юиксы, джобстубидан, 42 фреймворка и 667 аббривеатур метрик
Эх, романтика
Вдохновения было море, а понимания, как залететь в новую сферу для реальной практики - не было.
Такие программы как ШМЯ, конечно, круто открывают дорогу молодым продактам - я даже туда прошёл, но не смог поехать из-за военных сборов
После неудачной попытки залететь в продакты через ШМЯ, я решил сделать это через "прокси-профессию" - продуктового аналитика
И этот путь оказался настолько удачным выбором, что я уже и не уверен, хочу ли быть продактом 💁🏼♂️
Формально, аналитика - это работа продуктового менеджера.
Потому что аналитика - это поиск ответов на вопросы из всей имеющейся информации (не только в данных, а вообще вокруг).
А ответы на вопросы продактам нужны постоянно.
Что удобно - для базовой аналитики нужны формальные навыки: теорвер и матстат до уровня проверки гипотез, подкованность в кручении-верчении данных SQL-ем/питончиком
Возможностей освоить технические аспекты - масса.
Выделить могу:
- 4 курс по анализу данных от МФТИ и Яндекса на Курсэре: coursera.org/learn/stats-fo…
- курс по основам статистики на Стэпике: stepik.org/course/76/promo
- если не хватает алгоритмов: intuit.ru/studies/course…
В целом, замечаю такую тенденцию - чем больше в обучении практики, тем больше от него пользы в будущем.
Без практики - изучено и забылось.
Вообще во многом аналитика - это решение головоломок.
И очень круто про подход к этим продуктовым головоломкам рассказывает Дима Тимко, ex. руководитель Браузера: youtu.be/u68RqMLmab0
(да, это ссылка на лекцию ШМЯ, простите)
Я надеюсь удалось передать атмосферу своей истории попадания в профессию.
Если где-то узнали себя - ментальный high five 🙏
Вторник
Всегда верил, что менеджер чуть ли не обязан понимать, чем же занимаются те, кого он менеджерит.
Как иначе управлять чем-то без понимания, как это создается?
В таком суждении легко быть строгим к менеджерам.
Но где же проходит граница необходимых компетенций?
Была одновременно грустная и смешная ситуация, когда знакомый рассказал про идею своего, пусть и не очень оригинального, стартапа, сервиса-агрегатора.
Ему нужно мобильное приложение.
После вопроса: "тут парень сказал за 90К сделает, это нормальная цена?" - было смешно
А ситуация в целом грустная.
Конечно, для воплощения продукта в жизнь совсем не обязательно быть подкованным инженером.
Но нужно хотя бы уметь разговаривать с инженерами, высокоуровнево понимать процессы работы, отличать плохую инженерию от хорошей.
Например, не обязательно уметь выстраивать гит-флоу, CI/CD систему, релизный цикл (это всё-таки инженерные задачи), но нужно уметь их осознавать и ориентироваться в этих процессах.
Кроме того, сам продукт состоит из множества взаимодействующих компонент.
И если я постараюсь укладываться кратко - считаю, что менеджеру стоит уметь ориентироваться именно в высокоуровневой архитектуре продукта/процессов, и не бояться погружаться в их детали, если это необходимо.
На деле архитектура - довольно просто выражается визуально в виде блоков и описания взаимодействия между этими самыми важными блоками.
Например, квадратик "клиент", квадратик "сервер", и стрелочка между ними - простейшая "архитектура" (бесполезная правда)
А вот так Android описывает архитектуру своей ОС: developer.android.com/guide/platform
Такие схемки с квадратиками на разных уровнях и связями между ними можно нарисовать для любого продукта.
А если, например, требуется менеджерить создание продукта двумя разными командами - ух, голове точно нужно быть готовой представлять не только взаимодействие между этими командами, но и взаимодействие мини-продуктов, создаваемых этими командами.
@produnderhood В разработке, если приходится работать с менеджером с техническим бэкграундом - это обычно очень приятно. Исключение - микроменеджер с техническим бэкграундом. Этот заколебет навязыванием своих устаревших знаний и подходов к разработке.
В точку!
А микроменеджмент каждого шага члена команды действительно обычно даёт только лишний стресс (обоим сторонам)
И через доверие ответственности, с отношением не как к просто исполнителю - люди быстро растут и помогают растить продукт, над которым работают twitter.com/_jeck/status/1…
Хочу ещё рассказать о ментальной ловушке, которую проявил в процессе изучения звукоинженерии.
Большинство людей верит, что можно накинуть на голос некий волшебный плагин, и вокал зазвучит как у Трэвиса Скотта
Я сам верил, что такие "секретные рецепты" есть
На деле оказалось, что качественный звук достигается только кропотливой работой на КАЖДОМ этапе процесса, а этих этапов - куча.
(Даже для постановки бэк-вокалов бывают отдельные профессионалы).
А волшебных плагинов - нет
(Так же, как и волшебных фреймворков менеджмента)
При этом некомпетентность в одном из этапов рискует загубить конечное звучание совсем.
Выходит, что качество конечного результата = качество самого плохого этапа процесса.
Хм, а это правило работает для любого продукта!
По-моему, Илья Красинский, говорил фразу: "точки кратного роста лежат в области наименьшей компетенции команды" (дословность не гарантирую).
Важно, что суть применима в каждой сфере нашей жизни.
Каждая слабость - это возможность стать сильнее.
Очень успокаивает.
Развивая продукт или фичу очень легко эмоционально привязываться к ним и верить в их успешность и потенциал.
Из-за этого очень просто поддаться когнитивным искажениям и давать этой привязанности влиять на решения - ведь вложено столько эмоциональных сил, и не одного человека.
Попав в команду аналитики Я.Браузера я удивился, как коллеги могут отвечать менеджерам на их заказы посмотреть на эксперимент, что-то посчитать, построить дэшбордик, ...
А зачем тебе это число нужно?
Почему решили, что нужно именно это посчитать?
Вот эти графики на дэшборде ты как планируешь использовать?
Окей, предположим посчитал, получилось 3%, что будем делать?
Какая вилка решений?
Такие вопросы раньше казались даже, хм, нетактичными...
Такие вопросы очень легко воспринимать негативно, особенно если об ответах на них не подумали заранее.
Но цель одна - выделить важное, и отсечь лишнее.
И это нормально не хотеть делать ту работу, в полезности которой ты не уверен и тебя не убедили.
Пожалуй, лучшее, что помогло отрезвить голову и размять из того, что читал - это цепочки Элизера Юдковски (lesswrong.ru/Как_успешно_ме…) - они сильно более ёмкие и информативные, чем ГПиМРМ
Четверг
АБ-тесты на первый взгляд - очень простой инструмент принятия решений.
Раздал пользователям варианты, собрал данные, посчитал стат. значимость, есть рост - успех, нет роста - "блииин, гипотеза не подтвердилась, давайте проверять другой вариант".
Ага, как же 😂
По неопытности можно попасть в массу ловушек.
Постараюсь описать основные, прочувствованные на опыте
(дисклеймер: тут будет мало научности, и много попыток объяснить своими словами, как понимаю сам)
Основной ловушкой, куда вечно пытается затащить нас наш мозг - желание всё упрощать до плохого/хорошего, черного/белого, роста/падения метрик или их отсутствия. Такая бинарность мышления.
Но стат тесты, на самом деле, не выдают бинарную величину "отличие есть" / "отличия нет"
А знаете/помните ли вы сходу, что такое p-value?
От определений из учебников, да и той же википедии, в первое время вытекают глаза.
Упрощая - это вероятность случайно получить такое (как в скормленных стат тесту выборках) или более сильное отклонение метрики тогда, когда на самом деле отличия нет.
А если ещё сильнее упрощать, p-value - это "вероятность случайности отклонения"
И обычно решают так: "если вероятность случайности меньше 5% - я буду считать изменение реальным".
(5% тут - это уровень значимости, и выбирать 1-5% - это такая, обычная практика)
Но если "принимать решение как только получили стат значимое отклонение"...
...поскольку с 5%-вероятностью значимость - это просто случайность, а не улучшенный или ухудшенный продукт
...то в 5% случаев ты будешь ошибаться (точнее - допускать ошибку 1-ого рода)
Время идёт, АБ-тест крутится, данные собираются.
Сложно удержаться и не дожидаясь нужного объема данных подглядеть, как же там идут дела с нашими метриками.
И опа - там ещё не так много данных, а отклонение уже статзначимо! Круто! Похоже изменение настолько сильное, что...
даже на этом объеме данных мы его прочувствовали!
Давайте представим, что тест идёт 7 дней, и мы каждый день считаем значимость (p-value).
Получаются такие графики p-value по дням:
(картинку стырил тут: varianceexplained.org/r/bayesian-ab-…)
Для действительно значимых изменений p-value со временем скатывается к нулю.
Если изменение не настоящее - линия в итоге уйдёт ввысь.
Но можно заметить, что незначимые отклонения (серые линии) заскакивали за границу значимости
Может так совпасть, что вы подглядели результаты АБ-теста как раз в тот день, когда p-value заскочил за границу значимости, вы видите изменения - и принимаете на их основе решение. Вот так пранк.
У этой проблемы даже название оригинальное - Проблема подглядывания
(искать пример графика оказалось оч смешно)
Значит ли это, что подглядывать нельзя совсем?
Нет, можно - вдруг там где-то отклонения на десятки процентов?
Но не стоит принимать решения или инициировать расследования по подглянутому отклонению на пару процентов с p-value в районе 0.03-0.04
Вряд ли вы следите только за одной метрикой на весь продукт при проведении АБ-теста.
А когда метрик много - все вышеописанные эффекты случайности начинают распространятся на каждую из метрик в отдельности!
Если вы наблюдаете метрик ~20, а выбранный уровень значимости - 5%, то ожидаемое количество "случайных статзначимых отклонений" - по одной метрике на каждый тест.
И это если метрики независимы между собой!
А многие метрики продукта обычно зависимы
Например, случайно в эксперимент попала аудитория с меньшей возвращаемостью в продукт и БАЦ - это случайное отклонение возвращаемости вслед за собой просадило (так же случайно) остальные ключевые метрики.
Эта проблема возникает при "множественной проверке гипотез" - можно читать в эту сторону.
И, конечно, не стоит забывать про физический смысл, стоящий за отклонениями, и складывать происходящее в цельную историю.
Если отклонилась метрика, отклонение которой не ожидалось от эксперимента - нельзя просто принять это на веру. Надо расследовать и объяснять.
Пятница
Не раз читал: "нужно выделять небольшое число самых важных метрик, ведь если следить за кучей - они будут постоянно разъезжаться в разные стороны и не понятно, что происходит и как принять решение"
Эта постановка вызывает ложное ощущение ненужности наблюдения "лишних" метрик
Выделять разные уровни важности метрик действительно важно.
Но не стоит бояться ситуаций, когда "не понятно, что происходит" - они неизбежно проявятся
А вот возможность погрузиться в другие метрики - лишь поможет расследовать проблемы
Например, несколько месяцев назад я стал замечать растущий поток экспериментов, а в большинстве из них есть свои проблемы - некоторые ключевые метрики падают, пользовательские сценарии в продукте страдают.
Для расследования проблем регулярно требовалось "копать руками"
А любое ручное расследование проблемы аналитиком - это время, ресурсы (+ рутина, если подходы к расследованиям повторяются)
Это привело к превращению многих ручных исследований в готовые метрики
Метрик становится всё больше и больше.
Стало ли от этого сложнее принимать решения?
Вовсе нет!
Это лишь позволило быстрее собирать знания в тех ситуациях, когда дополнительные знания нужны.
А если не нужны и в ключевой метрике всё хорошо, ну, и не нужно смотреть детальнее - в этом месте всё хорошо.
Суббота
Высокоуровнево - основная сложность создания любого продукта в том, чтобы в правильные моменты времени делать грамотные действия и выстраивать их в слаженный процесс.
Узнавая про методы исследований просто осознать их ценность, но не просто - правильные моменты применения
Поэтому хочется порассуждать, когда и какие исследования помогают достигать полезных целей.
А в первую очередь - о касдевах и юиксах (customer development, user experience исследованиях, u know)
Которые на первый взгляд кажутся панацеей и необходимостью везде-везде-везде
Фрёмвёрк Jobs to be done наводит на хорошую абстракцию, с которой интересно работать - работа.
Но продукт не просто делает какую-то "работу на пользователя", он "помогает пользователю сделать некоторую работу достигнув цели"
И считаю, что качественные исследования предназначены как раз для выделения сути этой работы, сценариев и целевых действий в ней.
Яркий пример - профессиональные инструменты. Для создания IDE просто необходимо погружаться в то, КАК люди пишут код и какие проблемы есть на пути.
А числа и статистика помогут понять какие из сценариев действительно важны и нужны.
Давайте попробуем посмотреть на это на примере приложения для медитаций.
Качественные исследования помогут понять, как люди медитируют, какие медитации бывают, как они ложаться в распорядок дня разных людей, какая этика специфична этому занятию (в данном случае мы обязаны нести доброту через коммуникацию с пользователем).
А количественные - сколько людей какой медитацией занимаются, как удовлетворены их запросы текущими продуктами на рынке, насколько сильны конкуренты, каковы их показатели.
Когда нужные сценарии выделены и известны (как, на самом деле, во многих продуктах и даже новых идеях стартуперов) - наступает время дизайна на таком, микро-уровне, когда сценарии прорабатываются.
И тут снова одинаково важны оба типа исследований.
А тут Качественные исследования помогают, на мой взгляд, ответить на 2 основных вопроса:
- удалось ли нам донести до пользователя ценность (понимает ли он, зачем новая фича)
- какие эмоции при этом испытывает (не раздражается ли он, комфортно ли ему в процессе использования)
При этом цели такого этапа дизайна выражаются метриками - конверсия сценария, возвращаемость к сценарию, распределение мощностей сценариев между собой, ...
И поэтому особенно полезны статистические данные по текущему функционалу, в который или рядом с которым вносим изменения.
Например, базовый инструмент такой аналитики - карта текущего распределения мощностей экрана/экранов продукта, т.е. буквально - куда и сколько раз уходят с этого экрана/сценария.
Потому что изменения, особенно визуально заметные, как раз меняют трафик на карте продукта.
Аналитический подход в UX-дизайне безумно важен, так как данные помогают выделить потенциально самые рабочие гипотезы, и проверять именно их.
А бездумная проверка кучи гипотез подряд - лишь трата времени и раздутие ненужной энтропии.
Примерно в таких абстракциях подхожу к задачам на "поисследовать".
Никаких хитростей, конечно не открыл, но ведь и на деле рабочими оказываются не только хитрые, но при этом простые и взвешенные действия!
Воскресенье
Работа над продуктами в технологичных сферах несёт в себе массу неопределенности на всех этапах: продакт не знает точно, в какую сторону должен расти продукт, аналитика регулярно требуют разобраться и объяснить произошедшеее (падение, продуктовый факап), ...
Разработчик на ходу разбирается с новыми технологиями и фреймворками, а QA - так вообще преследуем маньяками, которые могут выпрыгнуть на него в любой момент и крикнуть перед лицом "ФАКАААПП!"
Неопределенностей - масса
Потребность в быстроте процессов - высокая
Столкновение с новыми типами задач - регулярное
Как же тут не стрессовать и не выгорать?
Перейдя из разработки в продуктовую команду задачи стали менее массивные, но их в целом стало множество, связанных с разными проектами и людьми, с которыми ещё и общаться надо
Триггеров стало сильно больше
И ситуаций, когда ты чувствуешь себя раздраженным, опустошенным, начинаешь видеть во всём негативное - тоже больше
Я не знаю наверняка, как с этим бороться, тут у каждого свой путь
Но попробую поделиться тем, какие мысли помогают мне справляться с этим и оставаться бодрым
"Горящих" дел сильно меньше, чем может казаться в голове
И эту боль я ощущаю острее всего - когда есть ощущение "столько всего горит, я все не успею!"
Выдохнуть и подумать "а если я профакаплю вот это - на самом деле же ничего страшного не произойдет" - очень полезно
Срочных дел, за которые действительно надо переживать - не так много, и переживания и адреналин лучше оставить на них
Пинги от менеджеров не стоят эмоций, совсем.
Если человек достаёт вас излишне - это только его проблема, и скорее всего он сам сильно переживает за сроки, поэтому и достаёт вас.
Фидбек помогает бороться с синдромом самозванца
Пожалуйста, прислушайтесь к этому, если руководите командой.
Слышать конструктивную похвалу и критику важно не только для правильной самооценки, но и для роста.
Давай фидбек - это позволит расти быстрее каждому
Каждому не поможешь
Замечал за собой, что боясь разочаровать других часто пытался слишком ответственно подходить к ad-hoc вопросам от других, просьбам помочь.
Помогать - отлично.
Но это может уводить от реально важных дел, где я нужен, а помочь коллеге может и другой.
По-моему, Илья Красинский, говорил фразу: "точки кратного роста лежат в области наименьшей компетенции команды" (дословность не гарантирую). Важно, что суть применима в каждой сфере нашей жизни. Каждая слабость - это возможность стать сильнее. Очень успокаивает.
Всем спасибо за эту неделю, кто читал!
Надеюсь, был полезен
Если кто-то захочет связаться: t.me/ismkhamitov
Ссылки на треды этой недели:
Мой путь из разработки в аналитику:
twitter.com/produnderhood/…
Волшебный продуктовый фреймворк:
twitter.com/produnderhood/…
Высокоуровнево - основная сложность создания любого продукта в том, чтобы в правильные моменты времени делать грамотные действия и выстраивать их в слаженный процесс. Узнавая про методы исследований просто осознать их ценность, но не просто - правильные моменты применения
Когнитивные искажения при создании продукта:
twitter.com/produnderhood/…
Про интерпретацию АБ тестов:
twitter.com/produnderhood/…
Почему нужно много метрик:
twitter.com/produnderhood/…
Про качественные и количественные исследования:
twitter.com/produnderhood/…
Работа над продуктами в технологичных сферах несёт в себе массу неопределенности на всех этапах: продакт не знает точно, в какую сторону должен расти продукт, аналитика регулярно требуют разобраться и объяснить произошедшеее (падение, продуктовый факап), ...
Про стресс и то, как я пытаюсь его переваривать:
twitter.com/produnderhood/…
![Ismail Khamitov [+2 MSK]](https://cdn4.telesco.pe/file/l0All59uCc91HoEI8lcmJWsCcudr_HKPk8_j9sg15LwIK7dYV23NVmEVMXs8qKIsqmvRCBWkwnuuFA6twQE7NDuu5Otg9RPexKDYdWuKLI_z3XwmnMC3hHxDp4k4kG-lBG06dz6h-O6jurDnaNoc6KcBdfcBoU7lTXiywpmkqgykF3-lehGKtaQ-iF1mIl9AspYUOcfDK-_55Pqg1ujSXtBD78FDVT5_Jnqo-erFk32WsCcBxsertWymF6aC35cZJSpugoDPuzEhXgDMbbsrvsDBna-_gXpFBVEyeZAc4qbwIX6MpEKNy_Vij8IgQLml74l25rrG-I8SMX5uInCEwg.jpg)
