Допустим в городе произошло преступление. Свидетели рассказали, что преступники:
- Были в желтой машине
- Женщина и мужчина, у женщины волосы собраны в хвост, женщина блондинка
- У мужчины борода
- В машине была собака
Спустя пару дней в городе ловят пару — они в желтой машине, женщина блондинка и с “хвостом”, мужчина бородат, в машине также сидит собака.
Обвинение говорит, что этих примет достаточно.
- Вероятность желтой машины: ⅒
- Вероятность, что у женщины светлые волосы: ⅓
- Вероятность “хвоста”: ⅒
- Вероятность бороды у мужчины: ¼
- Вероятность собаки в машине: ¹⁄₅₀₀
То есть вероятность, что все это совпадет вместе: ¹⁄₆₀₀ ₀₀₀ или 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. Также автор не пытается сильно убедить тебя в своей точке зрения. Он описывает почему он считает, что что-то правильно, но не пытается долго убеждать в этом.
В целом — очень хорошо. Плотность информации очень большая. Мне нравится такой стиль написания книг, если бы я написал книгу — я бы написал ее именно так.
Ниже записи интересных мне мыслей из книги.
Команды
- Менеджеру должно репортать 6-8 человек. Если менеджеру репортает больше 9 человек — он больше тренер, а не менеджер — просто дает советы и подстраховывает, но не менеджит.
- Команды меньше 4 человек — не команды. Команды из 1-2 человек это всегда плохо. Смысл в том, что команда абстрагирует сложность людей, из которых она состоит. Команды из 1-2 человек это “дырявые абстракции”, управление ими не отличается от работы с конкретными людьми. Также они хрупкие, уход одного человека сильно нарушает равновесие.
- Если нужно создать новую команду, лучше вырастить текущую до 8-10 человек и разделить ее на две. Создавать пустые команды — нехорошо.
- У инженерной команды может быть четыре состояния: отставание (с каждой неделей бэклог больше чем был, критические штуки не делаются), топтание на месте (критические штуки делаются, но нет времени отдать технический долг), возврат технического долга (есть время его возвращать) и этап инноваций (технический долг низкий, есть время делать новые штуки). Команды хотят идти от первой стадии к последней. В больших компаниях разные команды могут быть на разных стадиях, лучше фокусироваться на одной команде сначала, а не вкладывать все усилия понемногу во все.
- Хорошая сработанная команда — залог высокой продуктивности. Если разобрать команду, даже сохранив частично ее членов, то это всегда потеря продуктивности. Командам надо много времени, чтобы сработаться. Это надо учитывать при росте команды или изменении ее состава.
Стратегии
Стратегия это список конкретных действий, которые решают конкретную проблему в условиях определенных ограничений. Хорошая стратегия состоит из диагноза, принципов и действий.
- Диагноз описывает саму проблему, вызов, который перед нами стоит. Текущую ситуацию и ее ограничения.
- Принципы: набор правил, которыми мы следуем, чтобы решить проблему. Хорошие принципы — некомфортные, заставляют чему-то сказать “нет”, часто являются компромиссами между противоречащими целями.
- Действия: появляются после применения принципов к диагнозу. Часто тяжелые абстрактные решения принимаются легко, но никогда не вытекают в конкретные действия. Поэтому действия должны быть конкретные. Такие, чтобы тоже было достаточно некомфортно им следовать (если проблема сложная).
Абсолютно ОК иметь несколько стратегий — по одной на каждую проблему.
Виденье
Если стратегии описывают шаги и компромиссы для решения проблемы, то виденье описывает идеальное будущее в котором эти компромиссы не нужны. Хорошее виденье помогает команде думать шире, за пределами текущего локального максимума и всех направляет на общие цели.
Хорошее виденье состоит из следующих частей.
- Главное утверждение. 1-2 вдохновляющих предложений, которые описывают всю суть документа. Это главная мысль, которую нужно повторять везде снова и снова.
- Ценность для пользователя. В чем будет наша ценность для пользователя? В чем будет его успех, который мы поможем ему достичь?
- Наши возможности. Что продукту нужно уметь делать, чтобы пользователи смогли получить эту ценность и достичь этого успеха?
- Ограничения. Какие у нас сейчас есть ограничения, но от которых мы избавимся в будущем? Какие у нас возникнут ограничения в будущем?
- Ссылки на остальные документы: метрики, таблицы, планы и т.д. Это все в дополнение, чтобы не усложнять основной документ.
- История: Когда все предыдущие штуки написаны, надо связать их суть в короткую историю. Вставить эту историю после главного утверждения.
Хорошее виденье требует нескольких итераций и тестирования на людях. 1-2 раза в год виденье надо обновлять.
Продуктовый подход
Четыре стадии выбора над чем работать:
- Обнаружение проблем. Боли пользователей (опросы и интервью), цели пользователей (куда они хотят придти?), сравнение с конкурентами и индустрией (чтобы понимать свои слабости и сильные стороны), сравнение поведения своих же когорт (чтобы посмотреть нет ли новых пользователей с другими нуждами), обнаружение своих competitive moats (какие есть и что это дает, какие можно построить, какие есть у конкурентов), что можно построить, что даст пользу сейчас, но также будет фундаментом больших хороших штук в будущем?
- Выбор проблемы. Что надо сделать прямо сейчас, чтобы выжить сегодня? Что надо сделать, чтобы смочь выжить в ближайшем будущем? Что надо сделать, чтобы победить? Посмотреть на различные временные рамки: что если у компании кончатся деньги через полгода, над чем тогда работать? А что если совершенно нет никакого внешнего давления — и результат можно было бы показать через два года? Или через пять? Посмотреть куда двигаются тренды индустрии. Посмотреть есть ли быстрые штуки с большим возвратом. Подумать, что можно сделать сейчас, чтобы выбор проблемы в будущем был проще?
- Валидация решения проблемы. Попробовать убрать риски и проверить решение перед его реализацией. Например: написать анонс запуска перед реализацией и посмотреть — полезно и круто ли звучит? Показать его некоторым реальным пользователям. Посмотреть как решают проблему другие и решают ли. Найти первых пользователей, которым показать прототип. Найти способ провести быстрый эксперимент или валидацию идеи.
- Реализация.
Цели и метрики
Просто метрика-число — плохая цель. У хороших целей есть четыре числа.
- Сама цель: чего хотим достичь
- Исходные данные: где мы сейчас
- Тренд: текущий рост этой метрики (например за прошлый период)
- Ограничение по времени — на какой период цель
Есть два типа целей: когда надо достичь чего-то нового или когда надо сохранить какой-то текущий показатель. Имеет смысл ставить парные цели обеих типов для балансировки.
Метрика — отличный способ внедрения новых заметных изменений во всей организации. Для этого сначала определяшь нужную метрику, смотришь как каждый отдел на нее влияет, делаешь ее публичной (в том числе сравнивая отделы между собой), добавляешь побуждений (дэшборды, письма если метрика сильно изменилась) и — если есть возможность — задаешь некий уровень ниже которого нельзя опускать ее. Раз в какой-то период делать ревью по ситуации.
Изменение структуры организации
- Лучшая реогранизация та, которая решает структурную/системную проблему (для улучшения коммуникации, более быстрых решений, лучшего фокуса и т.д.) и та, которая не состоялась.
- Не надо делать реогранизацию, чтобы просто избежать решения проблемы с менеджментом конкретных людей и/или из-за плохих отношений с конкретными людьми.
- Не надо делать реогранизацию, чтобы решить будущие проблемы, которые еще не настали. Мы не знаем какие именно у нас будут проблемы точно.
Как делать изменения в организации
Как сообщать об изменениях:
- Описать зачем мы их делаем
- Описать как затронет каждого
- Будут недовольные: проявить эмпатию и дать им возможность высказать свои волнения.
Также в сложных ситуациях стоит:
- Поговорить сначала лично с теми, кого затрагивает сильно
- Подготовить менеджеров и ключевых ребят к тому, чтобы они могли объяснить зачем эти изменения и рассказать детали
- После этого выслать письмо с деталями и быть готовым отвечать на вопросы
- Иногда общий личный сбор стоит провести, но не всегда — люди плохо обрабатывают сложные новости в больших группах.
- Увеличить количество skip level 1-1 после
Лучше внедрять изменения по одному, мониторя результат после каждого.
Управление и вовлечение менеджера
Есть разные уровни вовлечения менеджера в зависимости от задачи.
- Я это делаю. Я делаю эту штуку и отвечаю за нее целиком — ты смотришь и вовлекаешься по необходимости.
- Предпросмотр. Ты делаешь, но я хочу быть вовлечен часто и много. Мы скорее всего не согласны в чем-то, частая синхронизация поможет избежать выкидывания ненужной работы.
- Ревью. Покажите мне перед публикацией или запуском. Я хочу убедится, что все будет ОК перед запуском, но по большому счету у нас нет расхождений во мнениях.
- Давайте апдейты. Сообщайте время от времени как дела, чтобы я знал что к чему и как все движется. Не ждите никакого фидбэка от меня, чтобы продолжать работу.
- Без сюрпризов. Сообщайте только если что-то сильно изменилось в проекте/задаче или есть серьезные проблемы. Главная цель: не должно быть сюрпризов в моем понимании того, как движется проект/задача.
- Дайте мне знать, если нужна помощь. Если от меня требуется какая-то помощь от меня в решении проблемы — скажите мне. А так, нам не надо тратить время на обсуждение этой штуки.
Как говорить с журналистами
Три правила:
- Можно отвечать не на сам вопрос, а на тот вопрос, который бы вы хотели, чтобы вам задали. Не нужно принимать как должное фрейм вопроса. Сложные вопросы можно и нужно рефреймить в нужное нам направлении.
- Лучше рассказывать в позитивном ключе. Негативные истории потенциально более сильны, но и так же сильно опасны.
- Лучше свести мысли к трем пунктам и повторять их снова и снова.
Правила в организации
Главная мысль: надо улучшать правила, а не делать исключения. Хорошие правила в компании это маленькие стратегии, они тоже имею цели, ограничения и действия. Они также не делают счастливыми всех-всех и не подходят всем. Если не получается написать ограничение/хорошее правило, возможно есть какая-то невысказанная цель, которую надо найти и проговорить.
Хорошие правила ограничивают. Если правило не ограничивает или очень мало ограничивает, не нужно эту штуку делать правилом. Достаточно описать рекоммендацию “у нас принято делать так”. Это позволит избежать траты времени на требование их выполнения, разбор нарушений и решение корневых случаев.
Хорошие правила и ограничения требуют постоянной поддержки. Они будут ограничивать какие-то возможности. Они будут иногда неоптимальны в каких-то кейсах — это надо принять и следить за правилом несмотря ни на что.
Исключения в правилах подрывают их силу и создают ощущение несправедливости. Вместо исключений надо делать так:
- Собирать запросы на исключения
- Время от времени (раз в какой-то период или когда много накопилось) ревьювать правила и ограничения, принимая во внимание эти новые обстоятельства
- Или изменить правило/ограничения или оставить их без изменений (подтвердив, что они были правильные)
То есть запросы на исключения тут работают как информация для обновления правил и не обрабатываются отдельно.
При внедрении нового правила или подхода имеет смысл сразу установить время, когда к этому правилу вернутся для его ревью. Но важно не спешить изменять его сразу после первого фидбэка — лучше дать время изменению проявится и вернутся к нему в назначенное время.
Разное
- Надо уметь говорить “нет” своему руководству и объяснить, почему предложенный путь ведет к проблеме или нежелателен. Два самых частых кейса: скорость (“почему эта штука делается так долго?”, “а давайте еще сделаем и вот это?”) и приоритеты (“а почему мы делаем это, а не то?”). Эти вещи надо уметь объяснять.
- Для продуктивности хорошо работает ограничение cлучайных отвлечений “мне просто спросить” в Слаке или лично, нотификации и тд: автоматизировать их, сделать бота, просить делать тикеты, направлять вопросы дежурному и тд. Хорошо также работает общий список кто за что отвечает и хорошая внутренняя документация (но это очень сложно)
- Системы как правило имеют какие-то cвойства, помогающие им самоисцеляться. Например перегруженная база данных замедлит работу сервиса, это заметит дежурный инженер и починит. Хорошие системы (не обязательно именно технические даже) имеют эффективные и явные системы самолечения.
- Хорошие правило менеджмента: у каждого должна быть зона ответcтвенности, за которую он отвечает. Награда и статус должны выдаваться за завершение качественной работы. Не проси делать то, что бы не сделал сам. Менеджемент он во многом про этику.
- Корень почти каждой внутренней проблемы: плохие или отсутствующие отношения.
- Люди важней процессов. С правильными людьми любой процесс подойдет. С неправильными людьми никакой процесс не заработает. Если процесс не работает, иногда дело не в процессе.
- Делать сложные вещи надо не откладывая: плохие отношения с кем-то, конфликт в команде и тд. Если их откладывать — они выстрелят сильно позднее и с ними все равно надо будет разбираться.
- Правильный фрейм принятия решения: что хорошо для компании? что хорошо для моей команды? что хорошо для меня? Именно в таком порядке.
- Есть два состояния: сильный рост и недостаток роста. Когда рост сильный, новые идеи не так важны — и так понятно, что делать, важно делать. Если роста сильного нет — наоборот, важны новые идеи.
- Правила хорошего спринта: команда знает 1) над чем работать 2) почему это важно 3) может определить когда работа закончена 4) знает над чем работать дальше 5) стейкхолдеры знают над чем работает команда 6) стейкхолдеры знают над чем будет работает команда 7) стейкхолдеры знают как повлиять на планы
Отличная книга. Советую всем, кто имеет отношение к управлению инженерными командами.
Я уже писал про контринтуитивную штуку о видео-звонках: надо смотреть не на собеседника, а на камеру.А тут 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 и даешь ему права на доступ к фотографиям, они начинают показываются медленно она за другой на экране. Это выглядит как будто все твои фотографии загружаются на сервера FaceApp. И сходство такое, что когда я это увидел, то так и подумал и сразу удалил приложение. На самом деле FaceApp ничего не загружает. Они просто сканируют твои фотографии на устройстве, ищут там фотографии с лицами и показывают только их (так как их фильтры работают только на лицах). Но это совершенно неочевидно. Какой-то чувак тоже так подумал, испугался, написал твит про это и в новостях начался шторм вида “FaceApp сливает все фотки”.
Вот как это выглядит в приложении. Причем даже вроде как раньше не было текста про Search Selfies.
Данные лучше хранит тот, кто может сильно потерять в случае их утечки или злоупотребления. Поэтому компания с русскими корнями/связями и основным рынком в US будет хранить ваши данные ЛУЧШЕ, чем например просто US компания. Потому что внимание и требования к таким компаниям сильно выше сейчас, последствия проблем тоже будут сильно больше. Это как у Талеба: Surgeons Should Not Look Like Surgeons. Если есть два хирурга с одинковым титулом, но один похож классического хирурга, а второй совсем нет — второй скорее всего будет более опытен и компетентен. Ведь ему в процессе своей карьеры приходилось преодолевать предубеждения, а продвинутся вперед он мог только доказывая что-то делом (а не видом или красивым разговором).
Кажется FaceApp обучал свои модели на красивых людях. Поэтому все старики у него тоже получаются симпатичные, таких хочется запостить в социальные сети → виральность приложения. Не просто “показать старика похожего на меня”, а “показать старика похожего на меня и настолько комплиментарного, чтобы я захотел со всеми им поделиться”. Интересна правдива эта теория или нет.
Я не знаю зачем они это сделали, но это выглядит как серый growth hack. Вот допустим у нас есть платформа в которой большое количество неактивных пользователей. Эти пользователи не получают маркетинговые рассылки: отписались, никогда не подписывались или давно их игнорируют/отправляют в спам. Поэтому платформа берет и рассылает “невинное” транзакционное письмо о чем-то вроде полезном: “вам пора обновить пароль”, “мы изменили наши terms of service” и так далее. На самом же деле письмо не несет пользы, но выполняет роль напоминалки: “эй-эй, мы существуем, вспомни про нас”. Платформа тыкает палочкой неактивного пользователя. Кто-то после этого станет зайдет и посмотрит, это увеличит MAU, а кто-то может и снова пользоваться начнет. Хитрый ход.
Задумался о том, что отличает продакт-менеджера разных уровней. Помимо прочего пришел к следующему различию.- Associate product manager получает (от кого-то еще) уже готовое решение сделать фичу и отвечает на вопрос КАК же ее сделать. Как она должна работать, как ее измерять, какими минимальными усилиями можно проверить гипотезу в основе этой фичи. Например приходит задание “нам нужно сделать восстановление пароля”, а associate product manager определяет как же это восстановление будет работать, как его сделать удобным, понятным, как узнать, что изменение было полезно.
- Product manager получает идею или проблему и отвечает на вопрос ЧТО надо сделать, чтобы решить проблему или получить максимум из идеи. Для этого нужно и сформулировать измеримо проблему или конкретные возможности в идее. И понять, какие конкретные изменения, фичи надо сделать, чтобы проблему решить или получить ценность из идее. И как понять, что мы на самом решили проблему и получили ценность. Например: “У нас проблема с onboarding пользователей. Надо это починить.”
- Senior product manager отвечает за целые направления или метрики высокого порядка. В рамках этого направления/метрики он/а формулирует проблемы или идеи, требующие работы.
Это субъективное различие. Человек, который senior product manager в каком-то продукте, вполне может быть associate product manager в другом продукте (если это совсем другая область) или организации (если там другая структура принятий решений).
В рамках такого подхода также можно определить и возможности роста.
- Associate product manager работает над фичей. Для роста должен научится работать в рамках идеи/проблемы и предлагать изменения сам.
- Product manager работает над идеями/проблемами. Для роста должен научится работать в рамках направления/метрики высокого уровня и предлагать идеи/проблемы сам.
- Senior product manager работает с широкими направлениями/метриками высокого уровня. Для роста должен научится работать в парадигме всего продукта, определяя сам направления/метрики, требующие внимания.