Июль 2019: элегантная головоломка, нулевая гипотеза, недостатки публичных баг-трекеров и серый growth hack от ЖЖ

Продолжаю читать очередную книгу про вероятности. Там описана занятная ошибка в трактовании данных. Описываю с небольшими изменениями для простоты.

Допустим в городе произошло преступление. Свидетели рассказали, что преступники:

Спустя пару дней в городе ловят пару — они в желтой машине, женщина блондинка и с “хвостом”, мужчина бородат, в машине также сидит собака.

Обвинение говорит, что этих примет достаточно.

То есть вероятность, что все это совпадет вместе: ¹⁄₆₀₀ ₀₀₀ или 0.00016667% (считаем, что события более-менее независимы, поэтому вероятности перемножаем). Казалось бы, очень низкая вероятность — очевидно, это те самые ребята, ведь вероятность того, что все просто совпало так мала.

Но на самом деле эта вероятность означает другое. Она означает, что если мы выберем случайную пару — вероятность, что она будет совпадать с описанным — ¹⁄₆₀₀ ₀₀₀ Если в городе живет 3 миллиона человек, то таких пар будет где-то 5 (плюс-минус). Значит вероятность, что это именно та самая пара — ¹⁄₅ или 20% То есть уже не так убедительно. Очевидно, что подобное совпадение сильный сигнал, что это они — но это не может быть единственной уликой.

§§§
Прочитал отличную книгу “An Elegant Puzzle: Systems of Engineering Management”: https://www.amazon.com/Elegant-Puzzle-Systems-Engineering-Management-ebook/dp/B07QYCHJ7V/

Она про инженерный менеджмент, но затрагивает также развитие продукта, культуру компании и кучу разных других штук.

Когда я сделаю свой список лучших книг для менеджеров, эта книга туда точно попадет. В ней совсем нет воды, долгих историй и размазывания одной идеи на 300 страниц. Только конкретные четкие размышления, списки и шаги по самы разным областям (“делайте так”, “не делайте так — я сделал и было больно”). Видно, что автор прочувствовал все на своей шкуре и решил выразить весь свой опыт в одной книге. После каждой страницы хочется остановится и подумать. Это сильно отличает эту книгу от кучи других про “управление”, которые размазывают общие слова и видно, что автор в реальной жизни мало сталкивался с реальными проблемами команды.

Некоторые штуки в книге важны только для крупных организаций, некоторые только для US. Также автор не пытается сильно убедить тебя в своей точке зрения. Он описывает почему он считает, что что-то правильно, но не пытается долго убеждать в этом.
В целом — очень хорошо. Плотность информации очень большая. Мне нравится такой стиль написания книг, если бы я написал книгу — я бы написал ее именно так.

Ниже записи интересных мне мыслей из книги.

Команды

Стратегии

Стратегия это список конкретных действий, которые решают конкретную проблему в условиях определенных ограничений. Хорошая стратегия состоит из диагноза, принципов и действий.

Абсолютно ОК иметь несколько стратегий — по одной на каждую проблему.

Виденье

Если стратегии описывают шаги и компромиссы для решения проблемы, то виденье описывает идеальное будущее в котором эти компромиссы не нужны. Хорошее виденье помогает команде думать шире, за пределами текущего локального максимума и всех направляет на общие цели.

Хорошее виденье состоит из следующих частей.

Хорошее виденье требует нескольких итераций и тестирования на людях. 1-2 раза в год виденье надо обновлять.

Продуктовый подход

Четыре стадии выбора над чем работать:

Цели и метрики

Просто метрика-число — плохая цель. У хороших целей есть четыре числа.

Есть два типа целей: когда надо достичь чего-то нового или когда надо сохранить какой-то текущий показатель. Имеет смысл ставить парные цели обеих типов для балансировки.

Метрика — отличный способ внедрения новых заметных изменений во всей организации. Для этого сначала определяшь нужную метрику, смотришь как каждый отдел на нее влияет, делаешь ее публичной (в том числе сравнивая отделы между собой), добавляешь побуждений (дэшборды, письма если метрика сильно изменилась) и — если есть возможность — задаешь некий уровень ниже которого нельзя опускать ее. Раз в какой-то период делать ревью по ситуации.

Изменение структуры организации

Как делать изменения в организации

Как сообщать об изменениях:

Также в сложных ситуациях стоит:

Лучше внедрять изменения по одному, мониторя результат после каждого.

Управление и вовлечение менеджера

Есть разные уровни вовлечения менеджера в зависимости от задачи.

Как говорить с журналистами

Три правила:

Правила в организации

Главная мысль: надо улучшать правила, а не делать исключения. Хорошие правила в компании это маленькие стратегии, они тоже имею цели, ограничения и действия. Они также не делают счастливыми всех-всех и не подходят всем. Если не получается написать ограничение/хорошее правило, возможно есть какая-то невысказанная цель, которую надо найти и проговорить.

Хорошие правила ограничивают. Если правило не ограничивает или очень мало ограничивает, не нужно эту штуку делать правилом. Достаточно описать рекоммендацию “у нас принято делать так”. Это позволит избежать траты времени на требование их выполнения, разбор нарушений и решение корневых случаев.

Хорошие правила и ограничения требуют постоянной поддержки. Они будут ограничивать какие-то возможности. Они будут иногда неоптимальны в каких-то кейсах — это надо принять и следить за правилом несмотря ни на что.

Исключения в правилах подрывают их силу и создают ощущение несправедливости. Вместо исключений надо делать так:

То есть запросы на исключения тут работают как информация для обновления правил и не обрабатываются отдельно.

При внедрении нового правила или подхода имеет смысл сразу установить время, когда к этому правилу вернутся для его ревью. Но важно не спешить изменять его сразу после первого фидбэка — лучше дать время изменению проявится и вернутся к нему в назначенное время.

Разное

Отличная книга. Советую всем, кто имеет отношение к управлению инженерными командами.

§§§
Я уже писал про контринтуитивную штуку о видео-звонках: надо смотреть не на собеседника, а на камеру.

А тут Apple сделала крутую штуку в FaceTime в iOS 13: автоматическое исправление направления взгляда. Используется ARKit и 3D-модель лица, ну как в масках.

Смотришь на экран, но для собеседника выглядит как будто ты смотришь в камеру. То есть собеседники будут смотреть друг на друга и в то же время глаза в глаза, что не сделаешь при обычном видео-звонке. Звучит как что-то не очень большое, но может сильно улучшить приятные ощущения от разговора через Facetime (и дать еще один стимул использовать iPhone: “через айфоны видео-звонки как-то душевнее”).

Пример с видео в этом твите.

§§§
Когнитивные искажения (cognitive biases) становятся общим знанием. В каждой второй научпоп лекции про псевдонауку будут рассказывать про них: как мы плохо думаем, как мы ошибаемся. Мне кажется такое отношение к когнитивным искажениям — неправильное.

Когнитивным искажения это замечательный рабочий инструмент, который привел нас туда, где мы есть. Мы умеем принимать быстрые решения, основываясь на паттернах, быстрых эвристиках, эмоциях (которые сами по себе — эвристики). Вместо долгих размышлений или вовсе отсутствия решения, это дает возможность что-то решить — быстро. И достаточно правильно, чтобы выжить. “Медведь не съел, гены передали дальше”.

Не каждый инструмент подходит для всего. Допускаю, что мир изменился быстрее, чем наши встроенные эвристики успели адаптироваться. Ну надо знать о своих ограничениях и особенностях, делая на них поправку. Но это не делает их чем-то плохим, чего надо стыдится. Наоборот, именно эти эвристики и позволили нам занять вершину пищевой цепи.

Кстати знание о когнитивных искажениях само по себе мало влияет на способность их избегать. Наши собственные эвристики очень часто в “слепом пятне” и воспринимаются нами рациональней, чем на самом деле являются. Наоборот, чем больше человек знает про эти “искажения”, тем больше он начинает думать, что он-то мол знает и защищен, что делает его часто более подверженным этим эвристикам.

§§§
Я видел несколько разных попыток завести публичный баг-трекер или публичную “базу идей с голосованием” для коммерческого софта. Долговременно это не срабатывает и приводит к недовольным пользователям.

Решение что мы делаем и что мы не делаем — сложные. Они не сводятся к “у кого больше голосов — то и делаем”. Какие-то изменения очень сложные или дорогие — их лучше отложить. Какие-то штуки никто не просит, но это наша ставка на будущее — чтобы привлечь новые сегменты. Какие-то штуки не подходят нашему виденью продукта и мы их просто не будем делать. Или наоборот — это легкие штуки с большим влиянием, их надо взять и сделать. Или попросил партнер. А иногда и есть конфликт интересов между пользователями и создателями — пользователи редко будут с радостью голосовать за более лучшую монетизацию или новые ограничения.

Публичные места заставляют объяснять и защищать свои решения. Это сложно и не всегда уместно. “У фичи A больше всего голосов, а вы ее уже годы не делаете!”. “Баг N вам запостили два года назад, а он еще не решен!”

Также, в случае “базы идей” (по опыту с несколькими из них), даже если вы делаете популярные запросы, происходит интересный эффект. Запросов ВСЕГДА больше чем вы можете сделать, все основные хотелки запостят вам в первые год-два жизни продукта, сделанные идеи скрываются со страницы. Это приводит к эффекту того, что для новых пользователей эта “база идей” выглядит очень страшно: одни нерешенные старые идеи. Ощущение “продукт не развивается”.

Так что может это и работает в первые год-два жизни компании/продукта, но потом — нет, публичность баг-трекере или базы идей начинает мешать и от нее надо избавляться.

P.S. Хорошие мысли на тему моего поста о публичных баг-трекерах и базах идей в канале “Products | People | Process”: https://tgstat.ru/channel/@program_man/119

Ребята в конторе увидели пост Евгения Казначеева про то, что публичный багтракеры/копилки идей не работают и попросили прокомментировать. Я несколько таких штук эсклуатировал сам, про несколько общался со “смежниками”, и в еще нескольких участвовал как пользователь или свидетель (MS Outlook, World of Tanks), и выходит так, что для ответа надо определить что такое “работает”.

Есть практическая ситуация - ежедневно поступают разносортные хотелки пачками. Несколько штук в день, порядка тысяч в год. Отслеживать руками их трудно и больно. Простейший “груминг” на предмет объединения дупликатов, инкремента счетчика голосов и поддержания приоритетов занимал другоценные часы. А стоит его запустить и беклог становится невозможно далее обслуживать и на моей памяти несколько таких накопленных беклогов в 500+ единиц пришлось просто закопать за отсутствием времени на все это перечитывать и сортировать.

И вот эту ситуацию “голосовалка” решает очень хорошо - с практически нулевыми затратами времени система типа Uservoice создает довольно качественный и упорядоченный список хотелок. Это настолько надежно, что у нас был длительный период организационно сломанной процедуры присмотра за порядком на Uservoice, и оно все равно работало. Где-то содержание замусорилось, где-то протухло, но система продолжала производить довольно упорядоченный список при уже однозначно нулевых затратах. Это то, что РАБОТАЕТ.

Также РАБОТАЕТ возможность проводить custdev или иное взаимодействие. Авторы хотелок очень заинтересованные в вопросе люди и очень хорошо откликаются на предложения поговорить, заполнить опросник и т.п.

Теперь об обратной стороне:

  • НЕ РАБОТАЕТ ожидание, что пользователь перестанет что-то хотеть от того, что оно не пользуется популярностью. Он все равно хочет. А вы все равно в его глазах плохие, что этого не делаете. Во всех голосовалках, где я участвовал, была такая картина. Частные симптомы - пользователь начинает аппелировать к возрасту запроса (“уже два года не делаете”) вместо популярности, к абсолютной величине числа запросов (“уже 50 голосов”) вместо относительной (в топ попадасть надо 250+), к переходу в другой канал (просят на форуме, потому что в голосовалке все равно не делают).
  • НЕ РАБОТАЕТ ожидание, что аудитория будет признавать голоса как легитимный источник и это как-то улучшит ваш publicity. В самом лучшем случае вы можете получить какую-то обоснованность в глазах других пользователей за неделание этой конкретной хотелки, НО во-первых пользователи и не будут массово смотреть какие-то чужие непопулярные хотелки, а во-вторых авторы непопулярных хотелок будут сочувствовать друг другу в своем горе.
  • НЕ РАБОТАЕТ ожидание, что аудитория будет сообщать качественную обратную связь. Все знают разницу между проблемой пользователя и решением, которое он просит. Огромная разница. Но не возможно хотеть проблему, поэтому будут приходить с готовыми решениями и просить их. Впрочем, поскольку работает взаимодействие, то можно уточнять. К примеру, есть в активе “security” фича, где все возмущенно кричали про наше недопустимое отношение к безопасности, а далее оказалось, что ее наличие банально позволяет получить скидку по ряду услуг у других вендоров и никакой безопасности никто и не ожидает.
  • НЕ РАБОТАЕТ ожидание про то, что делая эти хотелки продукт станет успешнее. Есть частный случай, когда уже есть хороший product-market fit, потенциальная аудитория большая, текущими клиентами представлена релевантна, будешь делать хорошо для них - будут новые пользователи. Но так не всегда и в общем случае будущие клиенты (prospects) могут хотеть совсем не того, чего хотят текущие. Но не-клиенты никогда не придут в вашу голосовалку.

Поэтому при запуске такой системы надо понимать цели - ЛЮБВИ И СЧАСТЬЯ НЕ БУДЕТ, а упорядоченный список острых хотелок будет. Ровно в нем и цель

С большинством тезисов я согласен и тоже испытал (мы использовали несколько лет Uservoice, который потом закрыли). .

Хочу прокомментировать вот эту штуку:

создает довольно качественный и упорядоченный список хотелок

Полезно иметь какое-то место, куда сваливаются все хотелки. Чтобы можно было там поискать например. Но вот качественный и упорядоченный список ВСЕХ хотелок точно не нужен каждому. Помнить все-все не нужно. Какие-то вещи можно и нужно уметь забывать. Про самые важные вещи вы все равно не забудете — про них все равно напомнят так или иначе.

§§§
Еще немного про A/B тесты. Чтобы уложить в голове базовые понятия о статистической значимости и мощности, надо понять как вообще работают A/B тесты.

Нулевая гипотеза
Допустим у нас есть два события и мы хотим понять, есть ли между ними связь (улучшили страницу → увеличилась конверсия, стали давать лекарство → люди больше выздоравливают и так далее)

Мы принимаем по умолчанию предположение, что эти события никак не связаны. Это предположение и есть нулевая гипотеза, обычно обозначается как H₀.

Наша задача, как экспериментаторов, не доказать связь каких-то событий, а доказать, что нулевая гипотеза (которая говорит, что они не связаны) не верна. Например сказать, что исходя из наблюдаемых данных опыта нулевая гипотеза очень маловероятна и поэтому мы ее отвергаем. Если нулевая гипотеза отвергнута, то значит связь между событиями есть.

Это тонкое, но важное различие: опровергать то, что связи нет, а не искать аргументы почему связь событий есть (последнее не всегда является достаточными доказательствами связи).

Смысл A/B теста как раз показать, что нулевая гипотеза очень маловероятна на наблюдаемых данных, значит она скорее всего неверна, есть связь событий и (допустим) изменение страницы действительн приводит к увеличению конверсии.

Статистическая значимость
У каждого эксперимента есть уровень cтатистической значимости (α). Это вероятность отклонить (признать неверной) нулевую гипотезу, если все же она верна. Другими словами это вероятность получить результат, что события связаны , хотя на самом деле связи нет.

Такие ошибки называют еще ошибками первого рода, false positive, “ложная тревога”.

Обычно в A/B тестах выбирают значение 5%. Это означает, что в ¹/₂₀ экспериментов, мы получаем такие маловероятные данные, что видим связь там, где ее совсем нет.

Чем больше статистическая значимость, тем меньше процент таких ошибок.

Если данные эксперимента показывают, что вероятность увидеть связь там, где ее нет для конкретного эксперимента (это называется p-значение, p-value) меньше чем наш заранее заданный параметр значимости, то этот эксперимент называют статистически значимым.

Статистическая мощность
У каждого эксперимента есть уровень cтатистической мощности (β). Это вероятность отклонить (признать неверной) нулевую гипотезу, если она на самом деле неверна. Другими словами это вероятность получить результат, что события связаны , когда они на самом деле связаны (1−β).

Чем больше статистическая мощность, тем чаще мы будем находить связь, когда она действительно есть. Если в A/B тесте мощность 80%, то в ¹⁶/₂₀ экспериментов мы обнаружим связь, если она действительно есть, а в ⁴/₂₀ не обнаружим (результат будет статистически не значим). Если 95% — ¹⁹/₂₀ и ¹/₂₀ соответственно. Тест может иметь и 100% мощность (мы всегда получим значимые результаты, если есть связь между событиями, но учитывая возможные false positive, то есть возможность увидеть связь даже если ее нет).

Такие ошибки необнаружения называют еще ошибками второго рода, false negative, “пропуск цели”. Больше мощность теста — меньше таких ошибок.

Чем больше мощность и меньше статистическая значимость, тем больше вероятность увидеть связь, если она действительно есть и не увидеть связь, если ее нет. Выборка должна быть большая (она еще зависит от минимально обнаруживаемого эффекта, но это отдельный разговор) и тест идет дольше.

Маленькая мощность — мы не видим связь, когда она существует. Большой уроверь значимости — мы видим связи там, где их никогда не было. Выборка в этом случае сильно меньше и тест идет быстрее.

Поиграться со значеними и их влиянием на размер выборки можно тут: https://www.evanmiller.org/ab-testing/sample-size.html

§§§
В Apple Maps есть иконки интересных мест (POI — point of interest). Там есть оказывается два примера локализации.

В Бразилии иконка бара не классический коктейльный стакан, а другой. У них есть популярный национальный коктейль, который подается именно в таком стакане с дольками лайма.

В арабских странах иконка больницы не крест, а полумесяц.

§§§
Приложение FaceApp (“посмотри как ты будешь выглядеть в старости”) стало резко популярным. В то же время вокруг него возник шум, что мол прайваси, воруют все фотографии (на самом деле нет), русские шпионы. В связи со всем этим три мысли.

Вот как это выглядит в приложении. Причем даже вроде как раньше не было текста про Search Selfies.

§§§
LiveJournal (была такая популярная платформа для блогов) прислал мне вот такое письмо для аккаунта, в который я не заходил уже 5 лет и не писал уже лет 10.

Я не знаю зачем они это сделали, но это выглядит как серый growth hack. Вот допустим у нас есть платформа в которой большое количество неактивных пользователей. Эти пользователи не получают маркетинговые рассылки: отписались, никогда не подписывались или давно их игнорируют/отправляют в спам. Поэтому платформа берет и рассылает “невинное” транзакционное письмо о чем-то вроде полезном: “вам пора обновить пароль”, “мы изменили наши terms of service” и так далее. На самом же деле письмо не несет пользы, но выполняет роль напоминалки: “эй-эй, мы существуем, вспомни про нас”. Платформа тыкает палочкой неактивного пользователя. Кто-то после этого станет зайдет и посмотрит, это увеличит MAU, а кто-то может и снова пользоваться начнет. Хитрый ход.

§§§
Задумался о том, что отличает продакт-менеджера разных уровней. Помимо прочего пришел к следующему различию.

Это субъективное различие. Человек, который senior product manager в каком-то продукте, вполне может быть associate product manager в другом продукте (если это совсем другая область) или организации (если там другая структура принятий решений).

В рамках такого подхода также можно определить и возможности роста.