careersoft-skillscommunicationincident-management

Bad news стейкхолдерам — как QA сообщать релизные проблемы

В QA-карьере есть soft-skill, который отличает junior от senior радикально, и при этом ему не учат ни на курсах, ни в книжках. Это умение донести плохую новость стейкхолдерам — релизный блокер, регрессию на проде, упавший staging, недостаточное покрытие — так, чтобы не сжечь доверие и не сорвать процесс.

Большинство QA либо тянут до последнего и сообщают, когда уже поздно («ну я думал, успеют пофиксить»), либо вываливают панику в общий канал («ВСЁ СЛОМАНО»). Оба варианта — карьерный ограничитель. Этот гайд — конкретные принципы и готовые шаблоны для пяти самых болезненных ситуаций.

1. Базовые принципы

No surprises rule.

Чем раньше стейкхолдер узнаёт о проблеме, тем больше у него опций. Узнать о блокере за 30 минут до launch — это бомба под доверие. Узнать за 2 дня — это рабочая ситуация. Правило: как только у тебя есть >50% уверенность, что проблема серьёзная — пиши. Не жди подтверждения 100%, ждать = опоздать.

Problem + options + recommendation, не только problem.

«У нас блокер на login flow» — плохо. «У нас блокер на login flow. Варианты: (1) откатить релиз на час, (2) выкатить с feature flag для теста на 5%, (3) задержать на день и пофиксить. Рекомендую (2), потому что блокер только у 3% пользователей с конкретным флоу» — хорошо. Стейкхолдер должен принять решение, а не разобраться в проблеме за тебя.

SBI framework для feedback и эскалации — Situation, Behavior, Impact. См. SBI Feedback Model от CCL. Применимо не только к 1-1, но и к репортам:

Situation: при регресс-тесте релиза 4.12 на staging. Behavior: при логине через Apple ID после 30 секунд приходит timeout вместо ошибки. Impact: пользователи Apple ID (по аналитике ~18%) не смогут войти после релиза. Поэтому…

Один источник правды.

Не пиши одно в Slack менеджеру, другое в email директору, третье в Jira-тикете. Делай один пост (Slack-thread или Jira-comment), и всех зовёшь туда. Иначе через час у разных людей разная информация о статусе.

2. Ситуация 1: блокер за день до релиза

Что НЕ делать:

  • Писать вечером в пятницу в общий канал «ребят, у нас тут проблема».
  • Тянуть до утра релиза в надежде что «может пофиксят».
  • Сообщать только тимлиду QA, ожидая что он эскалирует.

Шаблон сообщения:

[BLOCKER] Release 4.12 — Apple ID login fails

Situation: regression test for 4.12 на staging, build #2841. Behavior: Apple ID login → timeout после 30 сек вместо ошибки. Воспроизводится 100%. Impact: ~18% пользователей не смогут войти (по analytics breakdown). Steps to reproduce, logs, video — в тикете QA-1842.

Options: 1. Откатить release, пофиксить, перевыкатить (~2 дня). 2. Релизнуть с Apple ID disabled, hotfix позже (4-6 часов). 3. Релизнуть с feature flag, выкатить на 5% и мониторить.

Recommendation: (2), потому что login alternative (email) работает, а Apple ID можно вернуть в hotfix в течение суток. Жду решения от @release-manager к 14:00 — после этого решение принимаю сам.

Ключевые детали: тег BLOCKER в заголовке, факты до интерпретации, варианты с временными оценками, deadline на принятие решения (иначе тебя проигнорируют).

3. Ситуация 2: регрессия на проде после релиза

Что НЕ делать:

  • «ВСЁ СЛОМАНО» в общий канал без контекста.
  • Молча начать расследование, ожидая что «сейчас разберусь и потом скажу».
  • Обвинять разработчика в коммите.

Шаблон:

[INCIDENT] Production — checkout fails for some users

Symptom: с 10:42 UTC checkout возвращает 500 для пользователей с купонами. Аффект ~12% checkout-сессий по Datadog. Triage: похоже на release 4.12 deployed at 10:38 UTC. Совпадение по времени, не подтверждено. ETA на root cause: 30 минут. Mitigation in progress: @backend-team смотрит логи, @qa проверяет staging.

Updates каждые 15 минут в этот thread. Следующий update в 11:00 UTC.

Дальше следуй incident-process команды. См. Atlassian Incident Management Handbook как референс, и PagerDuty Incident Commander training для роли incident commander.

Принципы incident-comms:

  • Symptom первым (что сломано для пользователя), не root cause (его пока не знаешь).
  • ETA и обещанные апдейты — каждые 15 минут даже если новостей нет («still investigating, no new info»).
  • Не называй виноватого до постмортема. Сейчас цель — остановить ущерб, не найти виноватого.

4. Ситуация 3: staging упал, не можем тестировать

Не такая громкая, как блокер, но дорогая, если затянуть.

Шаблон:

[BLOCKED] QA staging environment — DB unavailable

Since 09:15 UTC staging DB не отвечает (connection timeout). Blocked tests: regression suite for release 4.13 (45 кейсов). Tried: restart pods, check disk, talked to @devops — выяснилось что в проде поменяли DB password, на стейдже не обновили. ETA на recovery: 1 час (от @devops).

Impact on release: если recovery занимает >2 часа, релиз 4.13 (планирован на завтра) под риском. Сообщу к 11:00 UTC.

Ключевое — connect environment-проблемы с релизным риском. Девопс может не знать, что без стейджа стоит регресс.

5. Ситуация 4: тест-покрытие ниже допустимого

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

Шаблон:

[RISK] Release 4.12 — payments coverage gap

Tested: основные flows checkout, refund, IAP. Прошли. Not tested: edge cases с partial refund + currency conversion (новый feature). Test data не подготовлен, занимает 4-6 часов на setup.

Risk: regression в partial-refund flow с currency conversion. Affected ~3% transactions. Финансовый риск: возможные дубли refund.

Options: 1. Релизнуть как есть, добавить мониторинг на этот flow, готовиться к hotfix. 2. Задержать на день, добить тесты. 3. Релизнуть с feature flag, тестировать в проде на 1% trafic.

Мой sign-off на релиз — conditional на выбранную option. Жду решения от @product до конца дня.

Conditional sign-off — лучший инструмент QA для управляемого риска. Не «всё ок», не «не подписываю», а «подпишу при условии X».

6. Ситуация 5: нашли security-issue перед launch

Особый класс — нужна закрытая коммуникация, не публичный канал.

Шаблон (в DM или приватном канале, НЕ в общем):

[SECURITY] Pre-launch — auth token exposed in client logs

Found: при тестировании feature X auth token логируется в Crashlytics при определённом флоу (см. detailed steps в attached doc). Severity: high (по нашей классификации) — token виден в сторонней системе analytics. Affected users at risk: пока 0 (pre-launch).

Не пишу в общий канал, эскалирую напрямую @security-lead и @cto. Жду указаний по communication protocol.

Security-incident НИКОГДА не обсуждается в общих каналах до того, как security-team даст добро.

7. Каналы и их роли

  • Slack-thread — для большинства ситуаций, видно всем, версионируется.
  • Slack DM / закрытый канал — security, чувствительный fail коллеги, репутационный риск.
  • Митинг (audio/video) — когда нужно быстро принять решение с эскалацией, и в чате уходит >3 кругов. Митинг после, не вместо, чата.
  • Email / Jira-comment — для async-стейкхолдеров (внешний клиент, top-management). Slack для них — шум.
  • Документ (Confluence, Notion) — для постмортема и lessons learned, не для acute-коммуникации.

8. Эскалация — куда и когда

Лестница (стандартная для большинства команд):

  • QA lead → если не реагирует за 30 мин на острый блокер.
  • Release manager / product owner → если решение влияет на план релиза.
  • Engineering lead / staff engineer → если нужен ресурс на fix.
  • CTO / VP Engineering → если стоит вопрос «релизить или нет», и release manager не уверен.
  • Security lead → ВСЕГДА для security-issue (минуя обычную лестницу).

Эскалация не = «жалоба». Эскалация = «не получил ответа на нужном уровне, поднимаю выше». Делается публично («cc @vp-eng for visibility»), без обвинений.

9. Антипаттерны

  • Overpromise: «через 5 минут починим» при незнании root cause. Лучше: «диагностируем, апдейт через 15 минут».
  • Blame: «это разработчик не покрыл тестами». Команда тебе не простит. Blameless culture работает только если ты сам её соблюдаешь.
  • Minimize: «ну там у пары пользователей не работает». Если данных нет — скажи «affecting unknown number of users, investigating», не приуменьшай.
  • Vague urgency: «срочно нужно решение!!!». Что значит срочно? К 12:00? К концу дня? К завтра?
  • Кидать в чат и уходить: сообщил → жди ответа, или скажи «буду доступен с 14:00, до этого декрементирую ETA».
  • Hero mode: «я сам всё пофиксил» в обход процесса. Команда не учится, доверие к процессу падает.

10. Постмортем и lessons learned

Каждая bad-news ситуация после разрешения = blameless postmortem. См. Google SRE Book: Postmortem Culture как канонический референс.

Структура постмортема:

  • Timeline (что когда произошло) — факты, без интерпретации.
  • Root cause (включая contributing factors, не только финальное звено).
  • Impact (количественно — сколько пользователей, на сколько времени, какой денежный ущерб).
  • What went well (важно — что в обнаружении/реакции команды сработало).
  • What went wrong (что можно было сделать лучше — без обвинений).
  • Action items (конкретные TODOs с владельцем и дедлайном).

Антипаттерны постмортема:

  • «Виноват разработчик X».
  • «Action items: быть внимательнее». Не actionable.
  • Постмортем без owner и дедлайнов — это статья, не план.
  • Засекреченный постмортем — никто не учится.

11. Чек-лист QA: как сообщать плохие новости

  • Сообщил, как только уверенность >50%, не ждал 100%.
  • Заголовок tagged по типу: [BLOCKER], [INCIDENT], [BLOCKED], [RISK], [SECURITY].
  • Дал Situation → Behavior → Impact (по SBI) или Symptom → Triage → ETA (incident-формат).
  • Дал варианты с временными оценками, не только проблему.
  • Дал recommendation и deadline на принятие решения.
  • Один источник правды (Slack-thread), все апдейты туда.
  • Регулярные апдейты (каждые 15 минут для инцидента) даже если новостей нет.
  • Security-issue — в приватный канал, не в общий.
  • Эскалация — публично («cc @vp-eng»), без обвинений.
  • После разрешения — blameless postmortem с action items, owners, дедлайнами.

Soft-skill «сообщить плохую новость» — это инженерный навык. Учится. Шаблоны выше — отправная точка, адаптируй под команду. Главное правило: «no surprises» — ранний report с плохими новостями всегда лучше позднего с любыми. Доверие команды строится не на отсутствии проблем, а на предсказуемости реакции на проблемы.