Процесс эскалации багов, когда каждая проблема доходит до основателя

Почему баги оказываются на столе у основателя

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

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

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

В маленьких командах критичность тоже быстро искажается. Без простых правил severity почти всё начинает выглядеть срочным. Сбой входа для всех пользователей и опечатка на одной странице настроек получают одинаковый эмоциональный вес. Когда каждая проблема звучит как пожар, основателя втягивают во все из них.

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

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

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

Назначьте понятного владельца на каждом этапе

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

Спокойствие приходит, когда у каждого шага есть один конкретный человек. Одно имя на каждый шаг. Без размытых формулировок вроде «кто-нибудь возьмёт», без догадок и без общей ответственности.

Хорошо работает простое разделение:

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

Владелец triage может меняться по кругу. В небольшом стартапе это может быть CTO, инженерный лидер или senior engineer. Его задача не в том, чтобы чинить каждый баг. Его задача — быстро проверять, группировать и передавать каждый новый отчёт нужному человеку.

Решение по влиянию на клиента тоже должно быть у конкретной роли. Инженеры знают код, но не всегда знают, какой аккаунт сейчас под риском, какой контракт важнее сегодня или есть ли временный обходной путь. Во многих командах это решает CTO, product lead или support lead. Выберите одну роль и придерживайтесь её.

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

За коммуникацию с основателем тоже должен отвечать один человек. Часто это CTO. В очень маленькой компании это может быть operations lead или chief of staff. Заранее зафиксируйте, когда этот человек отправляет апдейты и что именно запускает новое сообщение. Если основатель слышит о каждом пустяковом баге, правило уже не работает.

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

Используйте правила критичности, которые легко применять

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

Четыре уровня

Используйте четыре уровня и привяжите каждый к влиянию на бизнес:

• Severity 1: продукт недоступен, не работают основные платежи, утекли данные или есть риск для безопасности клиентов. Реакция нужна немедленно.
• Severity 2: важная функция сломана у многих пользователей, серьёзный клиент заблокирован или деньги теряются, но компания всё ещё может работать. Реакция начинается в течение 1 часа.
• Severity 3: баг мешает одному сценарию, затрагивает небольшую группу или имеет понятный обходной путь. Реакция может подождать до конца рабочего дня.
• Severity 4: косметические проблемы, ошибки в тексте и малозначимые крайние случаи. Их можно отнести в обычное планирование.

Лучше всего это работает, когда каждый уровень отвечает на три простых вопроса. Сколько клиентов это затрагивает? Останавливает ли это выручку или снижает её? Затрагивает ли это безопасность, приватность или потерю данных? Сбой входа для всех пользователей — это 1. Сломанный экспорт для одного внутреннего администратора обычно — 3. Баг, который показывает одному клиенту данные другого клиента, — это 1, даже если жалоба только одна.

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

Храните эту страницу там, где команда уже работает, а не в забытом справочнике. Добавьте её в шаблон трекера, в support playbook и в заметки по incident channel, чтобы люди могли пользоваться ей под давлением.

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

Постройте более спокойный путь для апдейтов

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

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

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

Короткой статусной заметки достаточно:

• Текущее влияние
• Новые факты с момента последнего апдейта
• Следующее действие и ожидаемое время проверки
• Владелец следующего шага

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

Представьте баг в signup во вторник утром. В инженерном чате уже летят логи, скриншоты и результаты проверок. Апдейт для основателя остаётся чистым: «Новые регистрации не проходят примерно у 15% пользователей. Исправлением занимается Миа. Команда нашла проблему в payment callback. Следующий апдейт в 11:30». Это занимает секунды и не затягивает основателя в детали.

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

Как действовать при новом баге

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

Начните с одного правила: соберите достаточно деталей, чтобы действовать, прежде чем обсуждение станет слишком громким. Зафиксируйте, что произошло, кто сообщил, когда это увидели и как это воспроизвести. Добавьте скриншоты или короткую запись экрана, если баг виден визуально. Если в отчёте написано только «checkout сломан», команда потратит следующие 30 минут на базовые вопросы.

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

Обычно работает такой короткий triage-flow:

1. Чётко зафиксируйте отчёт: шаги, скриншоты, устройство или браузер и время обнаружения.
2. Проверьте, могут ли пользователи всё ещё выполнить действие, даже если есть временный обходной путь.
3. Назначьте критичность заранее, чтобы команда не тратила час на спор о чувствах.
4. Назначьте одного владельца и одного запасного. Один человек ведёт исправление. Второй может подключиться, если владелец застрянет или уйдёт офлайн.
5. Решите, кому нужен апдейт прямо сейчас. Support может понадобиться формулировка для клиентов. Основателю сообщение нужно только если баг влияет на выручку, на многих пользователей или на публичное доверие.

Делайте обновления короткими. «Мы воспроизвели проблему, checkout всё ещё работает для большинства пользователей, один инженер занимается исправлением, следующий апдейт через 30 минут» — этого достаточно. Такой формат быстро снижает напряжение.

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

Простой пример

В 9:07 в пятницу утром support получает три сообщения об одной и той же проблеме: клиенты могут добавлять товары в корзину, но у некоторых платежи не проходят на checkout. Выручка под угрозой, так что это нельзя оставлять в общем бэклоге до обеда.

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

К 9:12 triage-ответственный проверяет влияние, подтверждает, что реальные пользователи не могут завершить оплату, и ставит Severity 1. Эта метка запускает понятное действие: немедленно вызвать дежурного инженера, остановить задачи с более низким приоритетом и держать обсуждение в одном канале инцидента.

Основателю не нужен поток технических деталей. В 9:15 он получает короткий апдейт: «Сбои на checkout затрагивают часть платящих пользователей. Поставили Sev 1. Инженер изучает логи платежей и последние деплои. Следующий апдейт через 20 минут». В сообщении есть влияние, владелец и время. Оно не просит основателя управлять исправлением.

Инженер начинает с самых быстрых проверок. Он сравнивает ошибки до и после последнего релиза, тестирует платёжный сценарий в безопасных условиях production и смотрит логи сервиса платежей. В 9:28 он находит причину: изменение в валидации отклоняет часть billing address.

В 9:34 инженер откатывает это изменение и просит support перепроверить одного затронутого клиента. Платёж снова проходит. Triage-ответственный обновляет статус инцидента, сообщает основателю, что исправление уже в работе, и делится единственной цифрой, которая волнует всех: success rate на checkout вернулся к норме.

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

Ошибки, которые удерживают команды в панике

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

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

Ещё одна проблема возникает, когда несколько человек одновременно ставят критичность. Support говорит, что это critical, инженер называет проблему мелкой, а product отвечает, что «зависит от ситуации». Это тратит время и запускает споры. Правила severity работают только тогда, когда одна роль делает первый вывод, а один человек может его пересмотреть, если появляются новые факты.

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

Полезный апдейт по инциденту отвечает на несколько простых вопросов:

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

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

Тишина — ещё один триггер. Если основателю приходится самому просить об апдейте, команда уже отстаёт. Спокойная команда отправляет короткие обновления по понятному ритму, даже если сообщение звучит так: влияние ограничено, владелец — Anna, патч тестируется, следующий апдейт через 20 минут.

Быстрая проверка вашего текущего процесса

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

Используйте это как быструю проверку:

• За первый triage сейчас отвечает один человек, и вся команда знает, кто это.
• Правила severity лежат в одном очевидном месте, и новый сотрудник может быстро их найти.
• У каждого открытого бага есть один владелец и следующий шаг, который он сделает.
• Основатель получает апдейты по расписанию или по понятным триггерам, а не при каждом маленьком повороте.
• Команда разбирает любой серьёзный инцидент в течение недели и записывает, что нужно изменить.

Эти проверки выглядят простыми, но они ловят большую часть стартап-хаоса. Когда triage-владение размыто, баги прыгают между support, engineering и product, пока не вмешается основатель. Когда правила severity трудно найти, каждый баг кажется срочным. Когда у тикетов нет следующего шага, люди думают, что их уже кто-то другой ведёт.

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

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

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

Что делать дальше

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

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

Чаще всего команды спотыкаются об одни и те же вещи:

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

Сначала исправьте именно это. Дайте одному человеку чёткую ответственность, держите обновления в одном месте и сделайте одного человека ответственным за коммуникацию с основателем во время инцидентов. Основатель должен подключаться для trade-off, обещаний клиентам и бизнес-рисков. Ему не нужно гоняться за статусом, сортировать скриншоты или выяснять, кто уже работает над проблемой.

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

После каждого инцидента задавайте три прямых вопроса. Что замедлило исправление? Что создало дублирующие сообщения? Что втянуло основателя в работу, которую команда могла бы закрыть сама? Обновляйте страницу сразу после этого разбора, пока детали ещё свежие.

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

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