Qetzal-1UP channel

@qetzal_1up Нравится 0

Product management, дизайн, стартапы, мозг и поведение, книги, познавательные видео и иногда другие рандомные штуки — https://qetz.al/
Есть вопросы? Пишите @qetzal
Гео и язык канала
Россия, Русский


Написать автору
Гео канала
Россия
Язык канала
Русский
Категория
Бизнес и стартапы
Добавлен в индекс
17.05.2017 01:11
Последнее обновление
27.05.2019 02:17
реклама
Telegram Analytics
Самые свежие новости сервиса TGStat. Подписаться →
Searchee Bot
Каталог из 270 000 Telegram-каналов с поиском внутри бота.
@TGStat_Bot
Бот для получения статистики каналов не выходя из Telegram
3 039
подписчиков
~1.5k
охват 1 публикации
~1.1k
дневной охват
~6
постов / нед.
47.9%
ERR %
1.24
индекс цитирования
Репосты и упоминания канала
6 упоминаний канала
2 упоминаний публикаций
14 репостов
Ponchik News
itateam
April Fool
itateam
Numbers Station Omega
lil words make magic
DIY : Customer Service 🦄
DIY : Customer Service 🦄
DIY : Customer Service 🦄
DIY : Customer Service 🦄
lil words make magic
Креативность 101
Лапы-хуяпы
40D
Ponchik News
No Flame No Game
Белостоцкий
Белостоцкий
Белостоцкий
Каналы, которые цитирует @qetzal_1up
Products | People | Process
prometa.pro книжки
prometa.pro книжки
prometa.pro книжки
No Flame No Game
Последние публикации
Удалённые
С упоминаниями
Репосты
Qetzal-1UP channel 20 May, 18:18
У Теодора Рузвельта есть сильная цитата:

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

Эта мысль повторяется и у Нассима Талеба, который вводит понятие "skin in the game" ("шкура на кону" в русском переводе). Главная идея у него: мнение/убеждение не надо принимать во внимание, если высказывающий это мнение/убеждение не несет рисков из-за возможной ошибочности этого мнения. Ассиметрия рисков от мнения/решения — плохо.

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

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

Большая открытость к фидбэку несет в себе парадокс (я уже писал про это недавно) — мнение есть у всех, мнения противоречат друг другу и твоим целям. Легко зависнуть в выборе или принимать во внимание людей, которые не разбираются в том, о чем говорят. Штука выше помогает этот парадокс решить.
Читать полностью
Qetzal-1UP channel 20 May, 17:55
Intercom апселлит новые фичи на экране добавления нового пользователя в систему. Интересный подход.
Attached file
Qetzal-1UP channel 13 May, 17:14
P.S. Читатель Igor Yashkov прислал (спасибо большое!) еще интересных ссылок, которые открывают еще одну интересную штуку.

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

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

Люди пытаются обойти эту проблему, используя другие подходы к расчетам, без p-value (то что все используют c p-value называют frequentist hypothesis testing).

Один из подходов это Bayesian A/B Testing. Очень подробно про него пишет VWO: https://cdn2.hubspot.net/hubfs/310840/VWO_SmartStats_technical_whitepaper.pdf При каждом свидетельстве (есть конверсии или нет) мы обновляем вероятности гипотезы. При таком подходе мы можем и остановить тест в любой момент и держать его запущенным так долго как хотим. VWO говорит, что это заметно ускоряет тесты. Это сильно уменьшает процент ошибок, правда говорят не убирает их совсем.

Или вот еще один другой подход(frequentist approaches to sequential testing): http://elem.com/~btilly/ab-testing-multiple-looks/part1-rigorous.html

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

(в ссылках выше много математики — я сходу не понял все штуки, потребуется сесть и обдумать)
Читать полностью
Qetzal-1UP channel 13 May, 10:53
То есть,
— Эти симуляции показывают, что если мы запускаем эксперимент не на выборке с заранее определенным размером, а просто останавливаем его как только получили значимые результаты, то мы будем получать ошибки. Если гипотезы сильно отличаются — в 10% случаев мы выберем худшее решение. Если не сильно — в 29% случаев (каждый третий!). Если гипотезы не отличаются — в 91.5% случаев, в девяти из десяти экспериментов мы убедим себя ("там же статистическая значимость!") в том, чего нет и будем это делать в полной уверенности, что это приносит пользу (а не приносит)

— Компании и консультанты, которые показывают выигрыш теста как только появился значимый результат (до теста на всей фиксированной выборке) — хитрят и обманывают. Они показывают много false positives, якобы успехов тестов. Особенно у начинающих, которые тестируют практически одинаковые гипотезы типа "зеленая кнопка против красной". Таким образом они создают фальшивое ощущения прогресса "ого, A/B тесты как круто работают — я тут заимплементил кучу гипотез и ща у меня все в гору пойдет".

TL;DR: Надо заранее выбирать размер выборки, останавливать тест когда он прошел и измерять значимость только в конце. Если тест не значимый — надо его перезапускать (а не продолжать). Если тест не значимый — возможно эффект изменений слишком мал для детектирования, надо увеличивать выборку.
Читать полностью
Qetzal-1UP channel 13 May, 10:53
Ситуация третья — гипотезы не отличаются по конверсии.
У контрольной версии конверсия 3%. И у тестовой — 3%.
(спойлер — тут начинается самое веселое)

— В 90% случаев после фиксированной выборки мы получили не статистически значимый результат (то есть "мы не смогли достоверно определить какая гипотеза конвертит лучше"). Это ожидаемый результат, так как разница в конверсии гипотез нет.
— В 5% случаев после фиксированной выборки мы получили статистически значимый и правильный результат.
— В 5% случаев после фиксированной выборки мы получили статистически значимый и неправильный результат (ожидаемо)

— В 78.6% случаев (!) статистическая значимость наступила раньше чем прошла вся фиксированная выборка. И результат был неправильным — мы подумали, что у какой-то версии преимущество (а они одинаковые).
— В 12.9% случаев статистическая значимость наступила позже чем прошла вся фиксированная выборка. И результат был неправильным — мы опять подумали, что у какой-то версии преимущество.
— В 8.5% случаев статистическая значимость так и не наступила, как долго мы тест не держали запущенным (в симуляции тест автоматически завершался, если было больше миллиона посетителей)

Вывод: если версии не отличаются по конверсии, мы будем получать не статистически значимые результаты в большинстве случаев (в нашем случае 90% случаев). В 5% случаев мы получим значимые и неправильные результаты — процент таких ошибок ограничен сверху нашим "p-value", мы можем его снижать (увеличивая выборку), но он не будет больше.

Если отличий в гипотезах нет и мы или завершаем тест раньше (до окончания фиксированной выборки) как только получили первый значимый результат или держим тест запущенным пока не получим значимый результат — мы получим значимые и неверные данные (что какая-то гипотеза отличается) в 91.5% случаев. 9 из 10 неверных ответов. Wow.
Читать полностью
Qetzal-1UP channel 13 May, 10:51
Ситуация вторая — гипотезы отличаются по конверсии, но не сильно.
У контрольной версии конверсия 3%. У тестовой - 2.8%.

— В 75.2% случаев после фиксированной выборки мы получили не статистически значимый результат (то есть мы не смогли достоверно определить какая гипотеза конвертит лучше). Это ожидаемый результат, так как разница в конверсии гипотез меньше, чем 20%, заложенная в расчете рекомендованной выборки (26000 посетителей).
— В 24.4% случаев после фиксированной выборки мы получили статистически значимый и правильный результат.
— В 0.4% случаев после фиксированной выборки мы получили статистически значимый и неправильный результат (редкое событие)

— В 54.8% случаев статистическая значимость наступила раньше чем прошла вся фиксированная выборка. Результат был правильным (мы определили, что тестовая версия хуже конвертит). То есть тут мы могли завершить тест раньше чем прошла вся фиксированная выборка и были бы правы.
— В 15.8% случаев статистическая значимость наступила позже чем прошла вся фиксированная выборка. Результат был правильным (мы определили, что тестовая версия хуже конвертит). То есть тут мы могли подержать тест чуть подольше и получить конкретный результат несмотря на то, что фиксированная выборка ничего не показала.
— В 29.1% случаев статистическая значимость наступила раньше чем прошла вся фиксированная выборка. Но результат был неправильным, мы бы ошибочно посчитали, что контрольная версия конвертит хуже, хотя это не так (это ведь тестовая конвертит хуже).

Вывод: если версии не сильно отличаются по конверсии (но отличаются), то при недостаточно большой фиксированной выборке мы будем получать не статистически значимые результаты (в нашем случае 75% случаев). Значимые и правильные результаты были получены только в четверти случаев по результатам фиксированной выборки. Это ожидаемый результат — если нет уверенно в сильной разнице гипотез надо делать выборку больше.

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

Но вот уже в 29% случаев (каждый третий!) такой подход приводит к ошибке и неправильному выбору. Мы останавливаем тест ранье и получаем значимые результаты, что контрольная версия конвертит хуже (что не так)
Читать полностью
Qetzal-1UP channel 13 May, 10:50
Ситуация первая — гипотезы сильно отличаются по конверсии.
У контрольной версии конверсия 3%. У тестовой - 2.15%.

— В 99.6% случаев после фиксированной выборки мы получили правильный и статистически значимый результат.
— В 0.03% случаев после фиксированной выборки мы получили не статистически значимый результат.

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

— В 13% случаев статистическая значимость наступила раньше чем прошла вся фиксированная выборка. Но результат был неправильным, мы бы ошибочно посчитали, что контрольная версия конвертит хуже, хотя это не так (это тестовая заметно конветит хуже).

Вывод: Фиксированная выборка показала значимый и правильный результат в 99.6% случаев (ожидаемо).

Если мы завершаем тест раньше, как только получили значимость и версии сильно отличаются по конверсии, то в ~87% случаев можно это сделать и получить верный результат. Это может сэкономить время. Но в 13% случаев такой подход приводит к ошибке и неправильному выбору — даже при такой большой разнице в конверсиях.
Читать полностью
Qetzal-1UP channel 13 May, 10:49
Десять тысяч A/B тестов
(Большой текст. Будет интересен тем, кто знает, что такое A/B тесты и статистическая значимость)

A/B тесты полезная штука для валидации гипотез, но не такая простая как кажется — легко ошибиться. Если о статистической значимости и p-значениях большинство знает, то вот о более хитрых возможностях ошибиться — нет.

Одна из проблем: repeated significance testing error (повторные ошибки тестирования значимости). Умные люди пишут (русский перевод), что выборка должна быть фиксированной (например "в тесте поучаствует 1000 посетителей"), после этого тест нужно завершить и подсчитать результаты.

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

Эта мысль контринтуитивна для меня. Я знаю, что про это пишут люди, которые понимают в статистике больше чем я (я понимаю так себе). Но я не мог понять до конца и осознать по настоящему почему оно работает так. Мысли об этом меня преследовали и воскресной ночью я понял — надо сделать модель и просимулировать все это!

Я сделал модель, которая симулирует множество A/B тестов, сравнивая две гипотезы с разной конверсией. В каждой симуляции трафик случайным образом распределяется между двумя версиями. Каждый сымулированный посетитель случайным образом конверится, согласно конверсии у гипотезы. Мы собираем статистику и оцениваем ситуации с досрочным завершением теста, если появилась статистическая значимость; завершением с ограничением по выборке и когда тест идет бесконечно долго, пока не появится статистическая значимость в одном из вариантов.

Сам код можно найти на Гитхабе. Также я там подробнее описал подход к симуляции. Если вы увидели ошибку в коде или же расчетах — пожалуйста, расскажите мне (@qetzal) — я буду очень благодарен (я не настоящий программист и статистик)

Ниже я расскажу про результаты (много чисел). Я просимулировал три ситуации:
1) две гипотезы сильно отличаются по конверсии,
2) отличаются немного и
3) не отличаются совсем.

В каждой ситуации мы смотрим и на результат после фиксированной выборки (26000 посетитилей, то рекомендованное число для 3% baseline конверсии, обнаружения разницы в 20% и 95% стат. значимости). Каждая ситуация была просимулирована 10,000 раз — проценты ниже отображают ситуации от всех симуляций.
Читать полностью
Qetzal-1UP channel 12 May, 20:26
II. Near/far transformation.
> TL;DR: our brain has two sets of heuristics to quickly parse complex streams of information. Manually tricking it to shift into a different mode can make seemingly intractable problems trivial.

Переключать себя между двумя режимами: ближний (личное, детали, эмоции, внимание) и дальний (асбтрактное, объективное, взгляд сверху, отстранненность).

> A way to make a difficult problem simple is to reframe a far mode problem in near mode. Simple example. Far mode: how do I pick a VC? Near mode: can I stand working with Bill for ten years? You've outsourced a hard problem to your gut for an immediate answer!
...
> Another similar trick: convert a continuous space into discrete units. Paul Graham did this in his Life is Short essay. How many Christmases do you have with your children? Waitbutwhy did it with Your Life in Weeks calendar.
...
> Another example of far->near mode. Here are WhatsApp founders describing the very complex question of online advertising: "no one wakes up excited to see more advertising; no one goes to sleep thinking about the ads they’ll see tomorrow".
...
> We tend to think of ourselves in near mode (great detail) and of others in far mode (abstractly). Flipping the two can make us seem dramatically more attentive. And when you hear internet advice that "nobody thinks about you that much", what it really means is that when they do think about you, they think about you in far mode. Of course there is the opposite trick too -- trick yourself to shift from near mode to far mode to get some objectivity.
...
> Describing current events in far mode can make one seem more profound by giving people some objectivity. Shifting your mind into far mode can help you make objective political decisions (especially if you're highly attached to your current reality, which we usually are). "So if you’re considering the worthiness of a particular statue [...] Pretend you’re from some very distant foreign country and view the dispute through that more objective lens."
...
> A far mode trick that can help make decisions -- imagine multiple futures and pick between them. [...] And a near mode version of this -- imagine you're *already* in a counterfactual future, and decide whether you'd want to come back.

Весь твиттер тред: https://twitter.com/spakhm/status/1126164200533790721
Читать полностью
Qetzal-1UP channel 12 May, 20:25
Slava Akhmechet (был продактом в Stripe, построил RethingDB) постит в Твиттере описания стратегий, которые помогают решать сложные проблемы. За несколько лет наблюдений за кучей проблем и кейсов он обнаружил, что их решения сводятся к ~20 стратегиям. Пока он запостил две.

I. Radical quantification
> TL;DR: transform an arbitrarily complex problem into a trivial one by picking just *one* quantifiable dimension to worry about.

Свести проблему к одному главному число и думать только о нем.

> Here is a trivial example: Net Promoter Score. You take an extremely complex problem of product/service satisfaction and distill it to one number -- "would you recommend this to others?"
...
> Consider a problem: how much did real wages grow from 1800-1992? The problem is extremely complex because it requires properly computing inflation in presence of rapid technological change and incomplete economic data. Is there a way to solve it with radical quantification?
> Here is a solution by William Nordhaus (Nobel Prize in economics in 2018). Reduce the problem to a single dimension -- how many hours did the average person have to work to produce a lumen of light? This isn't easy to compute, but it makes an impossible problem tractable.
...
> You can project nearly every dimension into another one - money. That lets you compare seemingly incomparable things.
...
> One of the coolest things about radical quantification is that you don't even have to pick a dimension you can observe because the technique is extremely susceptible to using proxy metrics. You just have to be really creative about picking the unit.

Весь твиттер тред: https://twitter.com/spakhm/status/1125851568312426496
Читать полностью
Qetzal-1UP channel 7 May, 15:03
Если спросить продакта про data-driven (ок-ок, data-informed) подход, то конечно он скажет, что это правильно и надо все считать. На практике же перейти от подхода "делаем, что сердечко попросит" к "смотрим на числа, а потом делаем" сложно (и не всегда нужно).

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

Переход должен быть осмысленный. Поэтому если сейчас вы совсем не смотрите на данные при выборе фич, но хотите начать — может подойти вот такой вот путь.

— Шаг 1: считаем данные после выпуска.
Ничего не меняем в выборе фич. Выбираем как и раньше. Но после того, как каждое новое изменение выпущено, cчитаем его метрики использования: как часто использовали эту фичу, как именно (базовые штуки).

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

— Шаг 2: делаем предсказания перед началом разработки и считаем данные после выпуска.
Ничего не меняем в выборе фич. Выбираем как и раньше. Но теперь после выбора фичи делаем предсказание про ее использование, например "как много народу ее будет использовать?". Предсказание записываем. После выпуска собираем аналитику (мы это научились уже делать в шаге 1) и сравниваем.

Этот шаг заставляет нас научится делать базовую оценку ДО выпуска фичи и сравнивать потом предсказание с реальным результатом, давая обратную связь. Это учит делать лучшие предсказания и учит, что наши предсказания часто ошибочны.

— Шаг 3: делаем предсказания перед началом разработки, они влияют на выбор.
У нас уже есть backlog изменений. Делаем предсказания (по сути строим модель или прикидываем будущее использование) про каждое изменение. Предсказания с максимальным результатом имеют сильное влияние на наш выбор, что делать.

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

Важное замечание: я (пока) противник использования подхода, когда для выбора "что делать" используются только расчеты: ввел в кучу колонок данные и оно сказало, что делать. На мой взгляд такой подход не дает выйти из локального максимума, заставляет игнорировать области, влияние которых сложновычислимо (дизайн и скорость, например), не учитывают стратегические вещи и так или иначе не убирают субъективный выбор человека (баллы же он там сам проставляет). Поэтому я за подход "данные помогают принять решение что делать", когда они влияют на выбор и помогают избавится от ошибок решений, но не задают выбор сами.
Читать полностью
Qetzal-1UP channel 7 May, 12:41
— Что мотивирует продакта. Самое важное причем это impact, delighting users и autonomy.
Qetzal-1UP channel 7 May, 12:40
— Must have и should have скиллы у продактов. Автор говорит, что 1) must have силлы обязательны 2) хороший продакт имеет все из must have и половину из should have 3) крутой продакт имеет все и из must have и should have.
Qetzal-1UP channel 7 May, 12:40
Хорошее видео про поиск и найм продакт-менеджеров: "Find, Vet and Close the Best Product Managers": https://www.youtube.com/watch?v=MoQk-iHJjEE
Текстовая версия https://firstround.com/review/find-vet-and-close-the-best-product-managers-heres-how/

Две штуки интересны даже тем, кто не нанимает себе продактов в команду.
Qetzal-1UP channel 1 May, 13:04
Очень интересные слайды про A/B эксперименты от чуваков из Bing: "Seven Rules of Thumb for Web Site Experimenters" https://exp-platform.com/Documents/2014-08-27ExperimentersRulesOfthumbKDD.pdf

Куча разных примеров. Особенно мне запомнились вот эти штуки.

— Twyman’s Law: Any figure that looks interesting or different is usually wrong.
Если статистика (или результаты эксперимента) выглядит необычно, удивляет, показывает какие-то невероятные результаты — скорее всего где-то ошибка и надо в первую очередь искать ее. Главная ошибка: сразу объяснять удивительный результат неверной причиной (например результатами эксперимента)

— Пример неправильного объяснения: цинга и витамин C. Цинга была серьезной проблемой в 16-18 веках у моряков. Доктор James Lind обратил внимание на отсутствие цинги у кораблей в Средиземном море. В 1747 году он провел экспериент и давал одним морякам лаймы, другим обычную еду. Чуваки, кто ели лаймы не заболели. Но Lind сделал неправильный вывод и объяснил успех неверной причиной. Позже в Англии он начал лечить пациентов с цингой концентрированнным лимонным соком. К сожалению в процессе его приготовления его подогревали, что разрушало витамин C. Поэтому у доктора не получилось повторить успешный результат и он разочаровался в своей теории (и стал лечить цингу кровопусканием)

— Второй пример: известная история от Гугла, когда они увеличили количество результатов на странице с 10 до 20, скорость загрузки страницы выросла на полсекунды, а revenue (заработок с рекламы) снизился на 20%. Это объясняли как "смотрите как скорость влияет". Чуваки из Бинга задумались — да, скорость влияет, но неужели 500ms влияет на 20% (!) revenue со страницы. Стали копать и повторили эксперимент. По их словам дело не в скорости, а в кол-ве рекламы на странице. На странице с 10 результатами — определенное количество рекламных объявлений. Когда количество результатов увеличивается, а количество объявлений остается тем же — это понижает их видимость (ну и соответственно клики и заработок). Они увеличили количество рекламы (еще больше замедлив страницу) и влияние на revenue исчезло.

— Часто эксперименты не улучшают engagment или abandonment rate, а всего лишь направляют клики/путь пользователя в другое место. Поэтому важно смотреть, не каннибаллизируют изменения просто существующий трафик, не улучшая картину в целом. Надо смотреть на улучшение общей метрики и если уж каннибализировать существующие клики, то направлять их на области, которые чем-то лучше чем существующие.
Перефразируя: легко оптимизировать локальные штуки (использование фичи, кликабельность элемента и тд) — сложно улучшать глобальные штуки (общие метрики, общий успех)
Читать полностью
Qetzal-1UP channel 30 Apr, 20:47
(весь тред на Реддите -- есть очень смешные штуки)
Qetzal-1UP channel 30 Apr, 20:47
В следующий раз, когда будете думать, что ваш проект идет сильно не так, вспомните про этот марафон на Олимпиаде 1904 года.

(Альтернативное название: "если ваш проект не выглядит как этот, даже не вздумайте приглашать меня на него")
Attached file
Qetzal-1UP channel 30 Apr, 20:09
Большой комментарий на Реддите про условия работы в Боинге: https://www.reddit.com/r/videos/comments/bdfqm4/the_real_reason_boeings_new_plane_crashed_twice/ekyyd9g/

Автор рассказывает всяческие ужасы про бюрократию и политику там. Но интересно там не это (правда ли это и насколько — открытый вопрос, каждый решает сам). Интересна там вот эта выдержка:

> Anyhow, James (or was it Jim? It's been a while.) was a grouchy old engineer they stuck me next to. He was close to retirement and clearly wasn't too stoked about losing half his cubicle to an unwanted programmer that showed up one day. James had a bunch of photos of an old 747 and structural diagrams pinned to his cubicle wall. One day, I asked what those were.

> They were pictures and failure analysis diagrams of JAL 123, the single worst single airplane disaster in history. 520 people died. It was because a couple of Boeing engineers fucked up. That 747SR had had a tailstrike incident on takeoff that damaged the rear pressure dome. A team of Boeing AOG (Airplane On the Ground) mechanics were flown out there to fix it. To oversimplify, they rushed and accidentally did the equivalent of 1+1=1 on one of their stress calculations. It was an error very similar to the infamous Hyatt Regency walkway collapse. 12,318 flights later, (well before what should have been at least 25-30,000 flight cycles that the crack inspection cycle would have assumed) the rear bullkhead ripped out mid flight and severed all hydraulic control lines. The plane lost all control and flew in a rollercoaster trajectory for 32 minutes before running into the side of a mountain. Many of the passengers had time to write goodbye letters to their loved ones. James had those photos and diagrams on his cubicle so that every day, he could look at them and remind himself of why his job was important and why he couldn't cut corners.

Вот эта вот способность видеть за работой (кодом, тикетами, тасками, изменениями) живых людей — очень важна. Спустя какое-то время начинаешь путать настоящую цель с ее проекциями. Теряешь эмпатию к людям, которые твоим продуктом пользуются. Это ведет к тому, что срезаешь углы, делаешь фигню, перестаешь вдохновляться своими делами, начинаешь делать штуки, которые важны для short-term метрик, а не для будущего.
Короче — ничего хорошего. Для тебя каждый пользователь становится одним из миллионов многих, простая строчка в таблице. А на самом деле это живой человек со своими чувствами, для которого твой продукт важен для достижения этого человека важных целей.

Важно про это время от времени себе напоминать.
Читать полностью
Qetzal-1UP channel 30 Apr, 00:26
Slack не показывает preview у Ютуб-видео с рикроллом (а у других видео показывает): https://twitter.com/SlackHQ/status/1120655978347868160 Ну то есть у них прям в коде хранится логика "если шарят именно это видео — не показывать preview, чтобы не портить шутку". Классная и забавная деталь.
Qetzal-1UP channel 29 Apr, 13:29
II. Технологические партнерства это штука обоюдоострая.
Тинькоф-банк сначала запустил брокера через БКС: это позволило им запустится, провалидировать спрос на услугу, понять что и как работает. Потом они сделали все у себя — БКС стал не нужен и они стали конкурентом (как я понимаю) БКС.

Есть и еще подобные примеры.

Например Mailchimp: они были супер-классным партнером для сторонних ecommerce ребят, которые хотят предлагать рассылки. Потом Mailchimp сделал конструктор landing страниц и добавил туда прием платежей. Я предполагаю, что они на горизонте 1-2 лет запустят свое собственное ecommerce решение. То есть Mailchimp вырос во многом за счет партнерств с другими решениями и станет им прям конкурентом (подход "троянский конь").

Или вот история от Mozilla про Гугл: https://threadreaderapp.com/thread/1116871231792455686.html (делайте поправку на bias ребят из Mozilla).

То есть если вы технологический партнер у других ребят, то надо про это подумать. Если вы не решаете хорошо (по мнению других ребят) задачу и она стратегически важна для них — вас могут заменить на in-house решение рано или поздно. Даже если вы решаете задачу достаточно хорошо — вас могут заменить только из-за желание бОльшего контроля над ключевой технологией. У других ребят ваше направление может не быть стратегическим сейчас, но может стать таким через пару лет. Короче, чтобы не заменили надо быть незаменимым (что бы это не означало: супер-продукт, компетенции, сложность повтора продукта, известность бренда и тд).
Читать полностью