Январь 2018: правильные A/B тесты, мудацкий дизайн, секс с дельфинами под LSD и важность озадаченности

Я уже упоминал фундаментальную ошибку атрибуции — когда кто-то другой делают что-то плохое, мы объясняем это их встроенными качествами (“он плохой человек”), а когда мы сами — внешними обстоятельствами, ситуацией (“он не такой, просто день был плохой”, “его вывели”)

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

Связано это с тем, что:

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

Кстати забавная цитата из этого исследования про сравнения себя с другими:

Somewhat ironically, being a peripheral member of an extremely socially active entourage may leave a person feeling worse off about her social life than being an average member of a less socially active group of friends.

§§§
В местной локальной Фейсбук группе случился небольшой скандал. У нас в городе открылся новый пафосный ресторан “авторской кухни”. Туда сходил шеф-повар другого нашего локального (хорошего) ресторана и написал справедливо разгромный отзыв.

Что интересно, потом в комментарии пришли ребята, которые стали говорить, что это неправильно. Что должна быть “корпоративная этика”, “приличия”, “не выносить сор из избы” — то есть негативный фидбэк должен был дан исключительно приватно.

Я это вспомнил в связи с другой новостью. Прошедший 2017 год был самым безопасным для гражданской авиации. И было 0 (ноль) крушений у массовых коммерческих рейсов.

А если посмотреть на количество успешно перевезенных пассажиров на одну смерть от полетов, то там тоже все очень хорошо. Где-то с начала 90-х годов все начало сильно улучшаться.

Это очень круто. Конечно это связано с улучшением техники: самолеты, оборудование, вспомогательные системы — все сильно улучшилось.

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

Поэтому авиа-индустрия постоянно улучшается: технически, улучшают процессы, даже такие вещи как коммуникация между пилотами. Все это приводит к повышению безопасности.

А культура сохранения лица, когда все боятся говорить о своих проблемах, когда они обсуждаются только “среди своих”, ничего не улучшает.

Так что важно, когда:

Про это хорошо написано в отличной книге “Принцип “черного ящика” Мэтью Сайеда. Очень рекоммендую ее.

§§§
Еще про:

О проблемах принято говорить вслух и никто этого не боится. Для этого за проблемы не должны наказывать, информация о плохих новостях должна привествоваться.

Главная проблема тут в cамом себе же в первую очередь. Критику мы не любим. Когда нас критикуют, первая реакция — защититься или атаковать в ответ. А не разобраться, что к чему и “пост-мортемы” проводить.

Особенно если мы не чувствуем себя в безопасности: надо сохранить лицо, очень важно мнение окружающих (а оно нам важно — что бы мы себе не говорили!), боимся, что критика повлечет за собой смену какого-то статуса (социального, рабочего, etc.)

Я в себе стараюсь это явно отслеживать. Можно все эти правильные вещи знать, но первые свои внутренние реакции на критику все равно будут неправильными. Я стараюсь отлавливать их и явно себя переключать на рациональные вещи: “ОК, это полезная вещь, как она может нам пригодится?” (получается не всегда)

Ну и обратный подход: если надо кому-то дать негативный фидбэк, надо убедиться, что он чувствует себя в безопасности.

§§§
Сформулировал важную для себя мысль про A/B тесты.

Есть два разных подхода к A/B тестам: для оптимизации существующей концепции/продукта или для создания новой.

Обычно A/B тесты выглядят так. Мы формулируем гипотезу, почему какое-то изменение улучшит нашу штуку. Запускаем тест, смотрим. Сработало — отлично, внедряем. Не сработало — формулируем новую гипотезу.

Пример: “если добавить фотографии существующих клиентов на сайт — люди будут лучше регистрироваться”.

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

Проблема в том, что этот подход не поможет найти новые и более лучшие концепции. Потому что все наши гипотезы УЖЕ лежат в рамках существующей концепции (старого продукта).

Чтобы находить новое, A/B тест и его гипотеза должны быть совсем другими, вне существующего фрейма. Такие гипотезы расширяют поиск “максимумов” и позволяет найти что-то совершенное новое, что качественно лучше старого.

Чтобы определить, подходит ли гипотеза под поиск нового, можно ответить на следующие вопросы.

1. Догадываемся ли мы о результате теста?
Удивит ли нас его какой-то один конкретный результат, а другой не удивит? Если да — гипотеза в рамках существующей концепции, “оптимизаторская”.

2. Дает ли нам важную информацию и выигрыш и проигрыш теста?
A/B тест и гипотеза тестируют новую концепцию/продукт, если любой результат теста — негативный или позитивный дает нам важную и полезную информацию о мире, продукте, наших пользователях. Полезную, это значит на основе этой информации мы можем строить новые гипотезы для новых концепций.

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

Итого, резюмирую.

  1. Есть два вида A/B тестов: для оптимизации существующих штук/концепций/продуктов и для создании новых
  2. Они не лучше и не хуже друг друга — у каждого свое применение. Оба инструмента хороши для своих задач.
  3. Тесты для “оптимизаций” сильно помогут улучшить существующую концепцию (найти “локальный максимум”), но не помогут найти новую. Будет ошибкой пробовать “оптимизаторские” тесты, когда мы создаем новый продукт или нужно что-то совершенно новое.
  4. Тест на новую концепцию должен как правило быть таким:
    • мы не можем предположить результат, и выигрыш и и проигрыш нас удивят одинаково.
    • и выигрыш и проигрыш принесут полезную и важную информацию для формирования новых “не оптимизаторских” гипотез.

§§§
Забавный сабреддит “Asshole design”. “Мудацкий дизайн”. Когда не просто сделали плохо, а плохо сделали специально: поленились, пожадничали или хотят обмануть.

Например.

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

§§§
Почему дельфины умные: https://www.theguardian.com/science/2003/jul/03/research.science

Интересно представить, что бы изменилось в обществе и мире, если бы оказалось (и это было бы научно доказано), что дельфины разумны (но мы этого не понимали, так как они не построили технологическую цивилизацию — зачем она им?).

Какая была бы реакция и что бы изменилось у всех.

Кстати вспомнил историю, что в прошлом с дельфинами проводили вообще интересные эксперименты. Одни чуваки хотели научить их говорить, поэтому взяли лабораторию, залили водой этаж и поселили там одного дельфина по имени Питер с девушкой. Идея была, что девушка(Маргарет Ловатт) будет проводить с ним все свое время (то есть она спала там же — в воде с дельфином) и научит его английскому, как мама ребенка.

В результате дельфин начал заниматься сексом с Маргарет (ну почти), а другим дельфинам стали давать LSD. Потом проект закрыли, Питера-дельфина разлучили с Маргарет и он покончил с собой.

Ric O’Barry corroborates the use of this word. “Dolphins are not automatic air-breathers like we are,” he explains. “Every breath is a conscious effort. If life becomes too unbearable, the dolphins just take a breath and they sink to the bottom. They don’t take the next breath.” Andy Williamson puts Peter’s death down to a broken heart, brought on by a separation from Lovatt that he didn’t understand. “Margaret could rationalise it, but when she left, could Peter? Here’s the love of his life gone.”

Занимательная и грустная история: https://www.theguardian.com/environment/2014/jun/08/the-dolphin-who-loved-me

§§§
Матвей, мой коллега, написал пост про 5 самых крутых книг, которые он прочитал в 2017: https://www.facebook.com/makfruit/posts/1920487587991977

Даниэль Канеман. Думай медленно… Решай быстро (Daniel Kahneman. Thinking, Fast and Slow)

Все наши решения в несколько слоев окутаны когнитивными искажениями и систематическими ошибками. Источников для искажений сознания много, и это не про наркотики или пропаганду. Книга очень подробно разбирает, как работает мозг при принятии решений, и советует, как предупреждать ошибки в своих действиях и видеть их в чужих. Автор рассказывает про практики и инструменты для принятия более верных решений (например, premortem — очень интересный приём). Круто. Отличная книга для всех, вне зависимости от рода занятий.

Kathy Sierra. Badass. Making users awesome

За последние несколько лет это максимально эффективное, что я читал про создание продуктов и сервисов. У книги очень высокий КПД — отношение полезных идей/советов к объему текста. Вместо популярного для подобных тем подхода “У меня родилась мысль, и я сейчас её объясню за 350 страниц”, здесь автор как будто делает “elevator pitch”: ёмко и без лишней воды выдаёт идею, добавляет иллюстрацию, шутку, вывод — и поехали к следующей главе. Очень рекомендую всем, особенно тем, кто как-то причастен к созданию и продвижению продуктов/сервисов.

Отличный список там.

§§§
Допустим есть 21-и этажный дом. В этом доме есть лифт. Когда вы вызываете лифт, он едет с этажа на котором остановился в последний раз.

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

Как максимизировать это удовольствие для всех жителей дома? (оставим в сторону сложные схемы с “машинное изучение паттернов использования” и т.д.)

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

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

Может в 80% случаев ехать на первый этаж и останавливаться там, а в 20% ехать на случайный этаж из 20-и остальных? Шансы 1 к 99, что при вызове на своем этаже лифт сразу откроется — очень редко и поэтому очень приятно (возможно). Как правило всегда открывается сразу на первом этаже (в 80% случаев), чтобы быть ожидаемо. Небольшая негарантированность может добавить приятности.

🤔

§§§
Тут на Гаваях разослали всем оповещение, что летит ракета и “мы все умрем”. Опровержение прислали только через 40 минут. Эти 40 минут все люди были уверены, что им конец. Интересно, что там у них эти 40 минут происходило. Думаю еще мы про это узнаем и может даже снимут фильм.

А вот почему это произошло.

Around 8:05 a.m., the Hawaii emergency employee initiated the internal test, according to a timeline released by the state. From a drop-down menu on a computer program, he saw two options: “Test missile alert” and “Missile alert.” He was supposed to choose the former; as much of the world now knows, he chose the latter, an initiation of a real-life missile alert.

“In this case, the operator selected the wrong menu option,” HEMA spokesman Richard Rapoza told The Washington Post on Sunday.

Да, дизайн и интерфейсы важны (вся статья).

Ну и из личного опыта. Если в базе завести булевское(правда/ложь) поле, которое может содержать значения “t” и “f” (от true и false), то обязательно рано или поздно выстрелишь себе в колено.

(Добавлено позднее)
Я писал раньше про историю на Гаваях, когда по ошибке запустили настоящее оповещение о ракетной атаке, вместо тестового. Все тогда объясняли причину тем, что интерфейс был очень неудобен и позволял ошибиться.

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

Когда начался тест, то по телефону голос сказал ““exercise “exercise “exercise”, но потом был зачитан текст от реальной атаки с “this is not a drill”. Сотрудник не услышал первую часть (как он говорит) и послал реальное оповещение.

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

Подробнее можно почитать в статье и полном репорте об инциденте.

§§§
Отличное эссе про “хуже это лучше”: http://dreamsongs.com/RiseOfWorseIsBetter.html

Там рассказывается, что когда хочется сделать все правильно, то дизайнер (тут имеетcz ввиду дизайнер в общем смысле — создатель продукта, дизайнер API и так далее, например в тесте про дизайнера языков программирования) думает про правильные вещи: простоту, правильность, согласованность, полноту. (в тексте interface не означает именно графический интерфейс, а скорее интерфейс взаимодействия с API, например)

То есть хотят вот такую идеальную ситуацию:

Подход “хуже это лучше” немного отличается. Он вот такой:

Автор заявляет, что хоть этот подход и хуже, но позволяет продуктам чаще выживать и доказывает это на примерах.

The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing. … A wrong lesson is to take the parable literally and to conclude that C is the right vehicle for AI software. The 50% solution has to be basically right, and in this case it isn’t.

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

§§§
Интересное и короткое (меньше минуты) видео про восприятие скорости загрузки в зависимости от вида прогресс-бара.

§§§
Некоторое время назад пару людей в моей ленте расшарили эту картинку c посылом “смотрите, что техническая поддержка себе позволяет”.

Это интересно и вот почему.

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

Заметил замешательство или озадаченность → осознал и проговорил ее → начал понимать, что не так, съехал с шаблонных рельс.

Какова вероятность, что это ПЛОХОЙ саппорт и сервис вот так и пишет “нам очень жаль, мразь!”. Вероятность очень мала. Бывают неадекваты, но тогда бы и весь коммент был неадекватен. А общий нормальный коммент с абсолютно неадекватным приветствием странен и вызывает озадаченность.

Так что было так: у человека было в системе имя “Мразь”. В ответе невнимательный сотрудник поддержки не обратил внимание, в куче сервисов например в текст имя подставляется сразу. Потом клиент сменил имя — в системе оно сменилось, в тексте нет.

Получилось, что получилось. Это смешно и есть что улучшить, но те, кто показывает эту картинку как пример “о боже, ужасный саппорт” — поленились подумать.

Если история вызывает замешательство — или в нашей модели мира или в истории что-то не так.

§§§
Чуваки рассказывают, что скорее всего есть два типа самоконтроля: self-control and cognitive control. Умение отложить немедленное вознаграждение ради бОльшего в будущем и умение сфокусироваться на задаче, игнорируя отвлечения. Эти штуки работают по разному в мозгу и их можно развивать отдельно друг от друга: https://digest.bps.org.uk/2018/01/22/self-control-and-cognitive-control-are-not-the-same-thing/

§§§
(мысли вслух)

Понять причины конкретного действия ≠ оправдать конкретное действие.

У действий иногда нет причины, попытки строить историю/нарратив часто ошибочны.

Мир несправедлив и случаен. Кармы не существует.

↑ 👾 🚀
Твитнуть
Расшарить
Отправить