Репетиция инцидента перед запуском для стартапов и акселераторов

Почему неделя запуска идет наперекосяк

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

Большинство команд в последние дни перед запуском заняты функциями, исправлениями и финальной полировкой. Это кажется разумным, но оставляет слепое пятно: никто не практиковал, что делать, если что-то сломается. Репетиция кажется менее срочной, чем выпуск, поэтому ее откладывают.

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

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

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

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

Что должна покрывать одна репетиция

Полезная репетиция должна быть узкой. Выберите один сбой, который может случиться во время живого демо, звонка с продажами или активной подготовки к запуску, и пройдите этот сценарий до конца. Если команда пытается проверить пять катастроф сразу, никто почти ничему не учится.

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

Начните с одного правдоподобного сбоя

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

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

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

Остановитесь на четкой точке восстановления

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

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

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

Назначьте роли до старта таймера

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

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

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

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

За сообщения клиентам тоже должен отвечать отдельный человек, потому что технические специалисты часто слишком долго ждут первого уведомления. Короткое обновление лучше молчания. «Мы нашли проблему с оформлением заказа, остановили новые релизы, следующее обновление через 15 минут» — этого достаточно для старта. Формулировка не обязана быть идеальной. Просто кто-то должен взять ее на себя.

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

Для большинства команд такого разделения достаточно. Если команда совсем маленькая, один основатель может совмещать две роли, но не три. Дальше репетиция перестает проверять реакцию и начинает проверять удачу.

Проведите репетицию в реальном времени

Репетиция перед запуском работает лучше всего, когда она короткая и конкретная. Выберите один триггер, задайте время начала и пройдите первые 30–45 минут так, будто проблема реальна. Простого сценария достаточно: «10:00, пользователи не могут войти, а поддержка получает первую жалобу в 10:03».

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

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

Говорите в настоящем времени. Не спрашивайте: «Что вы обычно делаете?» Спрашивайте: «Что вы делаете прямо сейчас?» Попросите людей написать сообщение клиенту, открыть канал инцидента, назначить ответственного и выбрать следующую проверку. Реальное действие быстро выявляет слабые места.

Затем добавьте один-два поворота. Они должны быть правдоподобными. Логи могут перестать обновляться. Откат может не сработать. Человек, который может утвердить решение, может оказаться офлайн. Одного поворота часто достаточно. Двух — более чем достаточно.

Если в комнате есть внешний советник или fractional CTO, дайте этому человеку роль ведущего и таймкипера. Он сможет двигать сценарий вперед, не перехватывая реакцию на себя.

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

Пример: оформлениe заказа ломается за час до демо

В 9:00 основатель делает финальную проверку перед демо-днем. Первый тестовый заказ не проходит. Потом еще один. Страница оплаты открывается, но карты не проходят. Это неприятный сбой, потому что продукт выглядит исправным, пока деньги не перестают двигаться.

К 9:05 поддержка получает сразу три сердитых сообщения. Один клиент говорит, что попробовал дважды и сдался. Другой спрашивает, не списали ли с него деньги, не оформив заказ. Третий говорит, что вернется позже, а это обычно значит, что не вернется.

Вот где репетиция перестает быть теорией. Команде нужно быстро выбрать. Исправлять код оформления заказа, откатывать последнее изменение или временно остановить продажи и объяснить клиентам, что происходит?

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

Подойдет такой черновик:

«Сейчас у части заказов возникают ошибки оплаты. Команда уже работает над этим. Если платеж не прошел, пожалуйста, не повторяйте попытку более одного раза, пока мы не подтвердим исправление. Следующее обновление будет через 15 минут.»

Пока сообщение готово, команда сравнивает варианты. Быстрое исправление может быть самым быстрым, но под давлением оно добавляет новый риск. Откат часто безопаснее, если проблема началась сразу после релиза. Короткая пауза может быть правильным решением, если никто не уверен, не столкнутся ли клиенты с двойным списанием.

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

Подготовьте сообщения для клиентов заранее

Когда что-то ломается прямо перед запуском, команды часто теряют время на формулировки. Это ошибка. Первое сообщение должно быть готово до сбоя, а не тогда, когда все спорят в чате.

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

Хорошее первое сообщение отвечает на четыре вопроса: что сломалось, кого это затрагивает, что пользователям делать сейчас и когда будет следующее обновление.

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

«Мы разбираемся с проблемой оформления заказа, которая затрагивает некоторых клиентов. Сейчас заказы могут не проходить. Пожалуйста, подождите 15 минут, прежде чем пробовать снова. Следующее обновление мы опубликуем в 10:30.»

Для пользователей этого достаточно. Партнерам обычно нужна другая версия. Им чаще важны объем, обходные варианты и то, что они должны сказать своим клиентам или внутренним командам.

«Мы видим ошибки оформления заказа в основном платежном потоке. Запасной поток через счет-фактуру по-прежнему работает. Пожалуйста, поставьте кампанию на этой странице на паузу до нашего обновления в 10:30.»

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

Отрабатывайте восстановление, а не только диагностику

Команды любят доказывать, что умеют находить ошибку. Но запуск наказывает те команды, которые не могут быстро восстановиться. Если ломается оформление заказа, пользователям не важно, нашла ли команда корень проблемы за 45 минут. Им важно, заработал ли сервис снова за 6.

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

Сначала отработайте откат на бумаге. Команда должна уметь точно сказать, какую версию нужно вернуть, у кого есть доступ, какой командой или кнопкой они воспользуются и как поймут, что все сработало. Если люди отвечают «разберемся по ходу», план еще не готов.

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

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

Затем проверьте точку решения. После 10 или 15 минут отладки команда продолжает копать или выбирает более безопасный путь? Этот выбор тоже требует практики. Многие команды слишком долго ждут, потому что считают откат провалом. Обычно это более спокойный вариант.

Одна полезная привычка советника особенно важна: до недели запуска записывать ожидаемое время восстановления для каждого запасного варианта. Это меняет разговор. Вместо вопроса «Сможем ли мы починить это на ходу?» команда спрашивает: «Какой путь вернет пользователей быстрее?» Именно это и защищает запуск.

Ошибки, которые делают репетицию бесполезной

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

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

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

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

Команды также пропускают сообщения клиентам, потому что проблема кажется слишком технической. Это серьезный промах.

Пользователям все равно, из-за чего проблема возникла — из-за ошибки кэша, плохого релиза или стороннего API. Им нужны три простых ответа: что сломано, в безопасности ли их данные и когда будет следующее обновление. Если никто не пишет такие сообщения во время упражнения, команда отработала только диагностику.

Репетиция ни к чему не ведет, если она заканчивается расплывчатой договоренностью. Запишите действия, назначьте на каждое одного ответственного и установите сроки.

«Нам нужно улучшить алерты» — этого мало. «Нина до пятницы пишет два шаблона сообщений о сбое для клиентов» — это ясно. «Сэм тестирует откат на staging в следующий вторник» — это ясно.

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

Короткий предзапускной чек-лист

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

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

• Запишите все роли в реагировании и назначьте для каждой запасного человека.
• Храните черновики сообщений для клиентов в одном общем месте.
• Прочитайте вслух шаги отката и восстановления.
• Сделайте один список контактов для команды, поставщиков, поддержки хостинга, платежных инструментов и сотрудников акселератора.
• Забронируйте 30 минут сразу после репетиции на разбор.

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

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

Что делать после репетиции

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

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

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

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

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

Если команде нужен внешний взгляд, fractional CTO может помочь проверить роли, сообщения для клиентов и пути восстановления до недели демо. Oleg Sotnikov на oleg.is делает такую работу со стартапами и небольшими командами, которым нужен практичный план реагирования до запуска.

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