Escaping the Build Trap, глава 22: Безопасность и обучение

Главная мысль: команды пробуют новое, только если ошибаться безопасно. Но ошибка без обучения — не успех. Лучше ошибаться рано, мало и дёшево.

Зачем нужна безопасность

Даже без наград за output команды могут бояться экспериментов. Причина — культура.
Marquetly успела, потому что CEO и лидеры не вмешивались, пока команды экспериментировали.
Status quo безопасен. Но он мешает инновациям.

С приходом Lean Startup многие стали праздновать провалы. Автор с этим не согласна.

В 2011 году Netflix попробовал выделить DVD-бизнес в отдельную компанию Qwikster.
Клиенты злились, отменяли подписки. Пресса писала, что Netflix конец.
Netflix быстро откатил изменение. CEO извинился и сказал: это не ядро стратегии.
Компания не стала бояться экспериментов. Позже она начала снимать свои сериалы. Это был большой эксперимент.

Вывод автора: Netflix мог сначала проверить Qwikster малым тестом. Но реакция компании показала: здесь безопасно пробовать.

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

Тип провала	Как выглядит	Цена
Быстрый и тихий	Ранний тест на малой группе	Низкая, можно восстановиться
Громкий	Запуск на всех без проверки	Высокая, как Qwikster
Медленный	Фичи без измерения годами	Самая высокая

PM должен снижать риск. Его вопрос: «Как проверить, что это правильный продукт, до больших вложений?»

Лидер даёт свободу, но задаёт рамки.

Бюджет: например, не больше $100,000 на эксперимент. Потом вернуться с данными.
Сегменты: сначала Alpha и Beta на малой представительной группе. Потом расширять.
Так меньше публичности, и откат проще.

Первый эксперимент страшен всем. Совет PM: обсудите границы с начальником. Объясните влияние, риски и экономию.

Компания: e-commerce с селебрити-продавцами. Идея CEO: Twitter-лента селебрити на главной странице.
За два дня сделали простой тест на малой группе пользователей.
Через неделю: продажи не выросли.
Попробовали письма фанатам. Продажи выросли в три раза.
Автор посчитала: компания сэкономила $250,000 по сравнению с полной реализацией первой идеи.

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

Что делать:

Термин	Значение
Safety	Уверенность, что за неудачный эксперимент не накажут
Learning	Знание, которое команда получила из эксперимента
Fail slowly	Годами держать фичи без измерения эффекта
Boundaries	Рамки эксперимента: бюджет, группа пользователей
De-risk	Снизить риск ранней проверкой

Медленный провал часто виден только в данных. Покажите PM фичи без использования за последний год. Это вклад data-команды в обучение.
Для экспериментов нужна инфраструктура: флаг группы в событиях, таблица назначений в эксперименты, стандартная модель метрик по группам.
Помогите задать границы: заранее посчитайте, сколько пользователей нужно в тестовой группе, чтобы получить реальные данные.
Применяйте идею к своим изменениям. Новую модель или пайплайн запустите сначала для части данных или одной команды. Потом расширяйте.
После неудачного теста фиксируйте вывод. Таблица «гипотеза — результат — решение» сохраняет обучение.