Killswitch
Проектируете процессы: полезный механизм и хак «в случае чего, как мы будем отключать это нахрен». Подход и рецепт интереснее, чем кажется (есть над чем подумать).
Тоже Р — рецепты.
Сама идея простая, как обычно. Вот мы берем, и хотим накатить на процессы какую-то хрень. Инновацию. Мы придумали как сделать уже существующее более лучше, и счас пойдём всё улучшать. Все порадуются, радость в массы, деньги в кассы.
Разумеется, всё может пойти не так. Потому что жизнь, как обычно, круче наших представлений о ней.
Шансов, что всё пойдет по звезде и встанет раком (по любой малозначимой причине) — в избытке. Если вы их не знаете, это совсем не значит, что их нет.
Поэтому хорошей практикой, рецептом и вообще хорошим тоном будет предусмотреть не только «план Б» и остальные, но еще и аварийный выключатель: что делать, если всё пошло совсем не так, как ожидалось. Такой подход принято именовать killswitch, в смысле «основной рубильник», аварийный выключатель.
Надо понимать, что все опции, включая killswitch — это тоже процесс, интегрированный внутрь вашей системы. Любой отказ, откат, возврат к заводским настройкам и превентивные меры, включая мониторинг и damage control — это тоже часть нормального поведения, пускай и не по оптимистичному сценарию. Если подойти с таких позиций, то становится очевидно, что и тут необходимы процессы, инструкции и общий modus operandi. Никаких авралов, паники и бегания кругами быть не должно.
Суть задачи следующая: вам нужно ко всему своему креативу дописать проверки и ход решения, которые в заданное время и по заданным условиям проверят, а не хуйню ли вы тут морозите
- сбор данных: если наблюдаются видимые проблемы, кто о них должен узнать? Куда это говорить, кому? Как это встроено в документооборот, как оценивается количественно
- как происходит оценка качественно: что мы меряем, какие метрики, что должно улучшиться, что должно ухудшиться или, наоборот, ухудшиться не должно
- есть ли критичные показатели, которые мы не можем провалить от слова совсем? что происходит, если так? есть ли запасные пути и ручные процессы?
- кто принимает решение? кто оценивает? Кто может сказать «так, всё, нахуй с пляжа, не летит», а чей голос тут только совещательный?
- какие временнЫе рамки эксперимента? заданы ли они календарным сроком, или заданы количественно (нам нужно минимум 10 кейсов), или есть более сложные метрики типа денег и каунтеров по rate или времени?
- является ли эксперимент курируемым, знает ли окружающая среда «вот есть наше более-лучшее, вот старый предсказуемый путь»? Как происходит выбор и переход от одного к другому?
- является ли killswitch детерминированным, есть ли условия для исполнителя «вот тут используй А, если не летит, используй Б»?
- является ли killswitch квантованным, можно ли принять решение «вот тут работаем так, вот тут иначе?» Кто принимает это решение?
- ограничен ли эксперимент количественно? Допустим, вы выкатываете идею на филиал, аудиторию, суб-продукт, географию. Есть ли что-то, что требуется учесть, или обработать? Что говорить тем, кто в эксперимент не вошел?
- если всё пошло «не так», чего нам стоит откат? Что мы делаем в системе, что откатываем, кто это делает? Что мы говорим клиентам? Будет ли потеря данных? Кого мы можем трогать, а на ком обосраться дорого и сыкотно?
Предполагается, что вы не отжигаете эксперимент в чистом поле и, наверное, надеетесь на какой-то оптимистический результат. Окей, я не против. Всё изложенное выше — ценно не только само по себе, как прописанные механизмы, а еще и вопросы для самопроверки на этапе проектирования. Позволяют ваше «решение» умозрительно погнуть, и обложить ценными правилами на случай всяких сложных ситуаций и мало-прогнозируемых косяков. То есть, если по уму — подумать заранее, и обработать потенциальные риски.
Если эксперимент не очень удачный (целиком или в какой-то степени), принято писать postmortem с оценками и выводами. Чтобы не делать эту работу потом дважды. Про пост-мортемы я вроде не писал, надо будет заморочиться, они полезные. Самая важная часть — что пошло «так», что пошло «не так», где мы можем улучшить, что необходимо не забыть. Именно за этим оно пишется (один тупой карандаш заменяет сотню умных мозгов).