Launch readiness: GO/NO-GO по 6 областям

Действуй как Head of Product, который ведёт launch readiness review. Фича: {{feature}}. Целевая дата: {{launch_date}}. Скоуп: {{scope}}.

Это orchestrator-промт. Связывает 6 областей готовности к запуску в единую систему чек-листов с явными GO/NO-GO критериями. Цель — за 1-2 недели до launch_date пройти ревью и получить ясное "идём" или "переносим".

Когда применять

Любой запуск ≥ medium-risk: новая фича на > 10% пользователей, изменение pricing, любая миграция БД, любой external announcement. НЕ нужно для: silent bug fix, dogfood внутри команды, internal-only фичи.

6 областей готовности

Area 1: Product readiness

Сам код, метрики, инструментация. Без этого ничего другого не имеет смысла.

Чек-лист:

1. P0 / P1 баги: 0 открытых. P2 — список с осознанным решением "ship as-is" или fix-before-launch
2. Test coverage: критичные flows покрыты e2e (checkout, signup, paywall, etc.)
3. Performance: p95 latency не хуже baseline + 10%, LCP/INP в зелёной зоне
4. Feature flag: готов, протестирован включение и выключение
5. Analytics: события размечены, dashboard собран, baseline снят
6. A/B / holdout setup: если применимо — sample size посчитан, randomization протестирована
7. Migration (если есть): rehearsed на staging, rollback rehearsed
8. Mobile: если есть — review submitted, approval timeline учтён в launch_date

GO criteria: 0 P0, 0 P1, dashboard работает, flag работает в обе стороны. NO-GO: любой P0 или P1, метрики не размечены, нельзя откатиться без деплоя.

Area 2: GTM readiness

Positioning, pricing, demand. То что превращает "запустили" в "продали".

Чек-лист:

1. Positioning statement: 1 предложение "для [target] кто [problem], мы [feature], которая [unique value]". Утверждено marketing + sales.
2. Target user: один первичный сегмент, не "все". Anti-personas описаны.
3. Pricing: tier, price point, кто платит, free trial / freemium / paid only — решено.
4. Sales enablement: deck, demo script, objection handling, FAQ для AE/SDR
5. Marketing assets: landing page, blog post draft, social copy, email sequence — готовы
6. Demand-gen plan: первая неделя, первый месяц — какие каналы, какой бюджет
7. SEO: keyword strategy, internal links, structured data
8. Customer references: 2-3 design partners готовы быть quoted (если open launch)

GO criteria: positioning утверждён, pricing зафиксирован, landing page готова, sales может продавать без вопросов. NO-GO: "потом доделаем positioning", pricing спорят, sales не видел продукта.

Area 3: Support readiness

Что произойдёт когда первый пользователь упрётся.

Чек-лист:

1. Help docs: getting started, how-to для топ-5 use cases, troubleshooting
2. FAQ: ответы на 20 предсказуемых вопросов (включая "сколько стоит" и "как отменить")
3. Training: support team прошёл обучение, может ответить без эскалации на топ-80% вопросов
4. Escalation paths: что делать когда saupport не может — кому в eng / product / sales
5. Macros / templates: готовые ответы в Zendesk / Intercom / Helpdesk
6. Severity definitions: что P0/P1/P2 для этой фичи (saupport должен знать когда будить on-call)
7. Capacity planning: ожидаемый volume тикетов, нанять / shift / overflow plan
8. Feedback loop: как support жалобы попадают в product backlog (еженедельный sync)

GO criteria: support team может работать самостоятельно на топ-80% запросов, есть clear escalation path. NO-GO: support узнаёт о фиче из публичного блог-поста (буквально классический фейл).

Area 4: Ops readiness

Monitoring, alerting, on-call, runbooks.

Чек-лист:

1. Monitoring: dashboard с health metrics (5xx, latency, error rate, queue depth)
2. Alerting: пороги установлены, alerts роутятся в правильный канал, нет alert fatigue
3. On-call: кто on-call в день launch, кто backup, кто escalation. 24-48 часов после launch — extra coverage
4. Runbook: написан, прорепетирован. Включает: как диагностировать топ-5 проблем, как откатить, кому звонить
5. Capacity: load test пройден, autoscaling настроен, headroom +50% к ожидаемой нагрузке
6. Dependencies: внешние API имеют circuit breakers, rate limits согласованы с vendor
7. Database: миграции протестированы, rollback rehearsed, replica lag в норме
8. Security: pentest пройден (если PII/PCI), secrets ротированы, audit log включён

GO criteria: dashboard работает, on-call знает что делать первые 60 минут после launch. NO-GO: "сами разберёмся когда станет плохо", нет runbook, alerts ещё не настроены.

Area 5: Comms readiness

Internal alignment + external announcement. Кто узнаёт, когда, через что.

Чек-лист:

1. Internal announce: 1-2 недели до launch — анонс всей компании (Slack + all-hands)
2. Internal FAQ: что говорить если кто-то спросит. Sales / support / exec talking points
3. External announce: blog post draft, press release (если PR-worthy), social posts scheduled
4. Customer comms: emails сегментированы (existing customers / trial users / prospects)
5. Partner comms: если integration partners есть — за 1-2 недели уведомление + assets
6. Embargo: если PR — embargo policy зафиксирована, журналисты brifed
7. Day-of timing: точное время launch (UTC + локальные), кто нажимает кнопку
8. Day-of comms cadence: Slack channel #launch-{{feature}}, status updates каждые 2 часа первые 24h

GO criteria: все ключевые stakeholders знают что выходит и когда, draft anonsa утверждён. NO-GO: компания узнаёт из чужого Twitter, sales продаёт фичу за день до launch без подготовки.

Area 6: Rollback plan

Что делать если всё пойдёт не так. Не "если" — "когда".

Чек-лист:

1. Rollback triggers: точные пороги метрик (5xx > 0.5% за 5 мин → откат). НЕ "если станет плохо".
2. Decision authority: один человек принимает решение об откате. Не комитет. Имя + backup.
3. Rollback mechanism: flag off (мгновенно) / git revert + deploy (минуты) / DB rollback (часы) — какой именно для этой фичи
4. Rollback rehearsal: на staging прорепетировано end-to-end. Время отката измерено.
5. Communication plan: что говорим внутри компании / клиентам если откатили. Шаблоны готовы.
6. Partial rollback: можем ли откатить только для % пользователей, или только all-or-nothing
7. Forward-fix vs rollback: критерии "когда чиним forward вместо отката" (P3 баг = forward; data corruption = rollback always)
8. Post-rollback: incident postmortem обязателен в течение 5 рабочих дней

GO criteria: rollback rehearsed, decision-maker известен, triggers задокументированы. NO-GO: "если будут проблемы — придумаем". Никогда не работает в проде.

GO/NO-GO ceremony

За 1-2 недели до launch_date проведи 60-минутный launch readiness review со всеми area owners. Формат:

1. Product owner презентует Area 1 status: GO / NO-GO / GO-with-risks
2. Marketing — Area 2
3. Support lead — Area 3
4. Eng / SRE — Area 4
5. Comms — Area 5
6. Eng lead — Area 6 (rollback)

Итог: один из трёх вариантов:

• GO: все 6 — GO. Запускаем по плану.
• GO-with-risks: 1-2 area имеют known risks, но принимаем осознанно. Записываем риски в launch doc, owner у каждого.
• NO-GO: любая area = NO-GO. Переносим launch_date. Конкретная новая дата + что должно измениться, чтобы перейти в GO.

Контракт между областями

• Area 1 (product) → Area 4 (ops): product НЕ должен ship без monitoring настроенного
• Area 2 (GTM) → Area 3 (support): marketing НЕ должен анонсировать пока support не trained
• Area 5 (comms) → Area 6 (rollback): comms НЕ должен анонсировать пока rollback не rehearsed
• Все → Area 1: остальные областям не имеет смысла начинать пока product не на ~80% готов

Anti-patterns

• ❌ Запуск в пятницу вечером — некому будет чинить
• ❌ "Soft launch" без явного определения когда переходим в "full launch"
• ❌ GO/NO-GO как formality — никто не готов сказать NO-GO, даже когда надо
• ❌ Marketing announce за день до тех. готовности — pressure ship broken thing
• ❌ Один человек на on-call в день launch — выгорит к концу дня
• ❌ Rollback plan = "git revert" без понимания DB consequences
• ❌ Help docs пишутся ПОСЛЕ launch — первая неделя support tickets утопит команду
• ❌ Нет owner у области → никто не отвечает → ничего не сделано

Day-of timing playbook (час за часом)

День launch — не "нажми кнопку и иди обедать". Структурированный runbook:

• T-24h: final go/no-go call (15 мин). Все area owners ещё раз подтверждают GO. Любой NO-GO → откладываем.
• T-2h: dashboard открыт, on-call в сборе, support обзвонил всех о готовности, internal Slack channel создан
• T-1h: final smoke test на production (с flag off → on для internal users)
• T-0: flag enabled для launch_scope. Comms timer запущен.
• T+15min: первая metrics check (5xx rate, latency, error rate). Если зелёное — продолжаем.
• T+1h: первая publicly visible status update в Slack
• T+4h: второй metrics check + decision: продолжать ramp, держать, или откатить
• T+24h: day-1 review (60 мин). Что сработало, что нет, что меняем для следующих launches.
• T+72h: post-launch retro (90 мин) со всеми area owners. Учимся на будущее.

Финальные артефакты

1. Launch readiness doc с GO/NO-GO статусом по 6 областям
2. Day-of runbook (timing, кто что делает, comms cadence)
3. Rollback playbook (triggers, mechanism, decision-maker)
4. Internal announce + external announce drafts
5. Support training materials + FAQ
6. Post-launch monitoring dashboard
7. Day-1 review notes + day-3 retro doc

Запусти review с Area 1 СЕЙЧАС. После каждой area — checkpoint с owner. Не объявляй GO пока все 6 областей не пройдены.