[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"post-plan-soft-launch-za-14-dney":3},{"id":4,"title":5,"slug":6,"description":7,"excerpt":7,"content":8,"body":8,"cover_path":9,"cover_url":10,"cover":10,"inline_path":11,"tags":12,"published_at":13,"published":14,"author_id":15,"author":16,"created_at":17,"updated_at":17},50,"План soft launch за 14 дней: пошаговый график с волнами тестирования","plan-soft-launch-za-14-dney","Готовый календарный план подготовки к запуску за две недели: что делать в каждый день, три волны честного тестирования, бюджет с комиссией, критерии готовности к релизу и что делать, если план сорвался.","## Сценарий: две недели до даты, которую нельзя сдвинуть\r\n\r\nКоманда из четырёх человек: двое разработчиков, дизайнер и Лена, которая совмещает продакта и всё остальное. Приложение — планировщик семейных дел с общими списками. Код готов, сборка собирается, ревью в сторах пройдено.\r\n\r\nДо объявленной даты запуска — 14 дней. Сдвинуть нельзя: договорённости с двумя телеграм-каналами о публикации уже есть, даты зафиксированы.\r\n\r\nПроблема: приложение никто, кроме команды, не проходил целиком. Ни один человек со стороны не создавал общий список, не приглашал второго участника, не оформлял подписку.\r\n\r\nЛена знает, что за 14 дней можно либо надеяться, либо проверить. Эта статья — её план: календарь по дням, три волны тестирования, бюджет и критерии, по которым в день 14 принимается решение «запускаемся» или «переносим».\r\n\r\nПлан рабочий для любого приложения с похожей ситуацией. Даты условные, логика — переносимая.\r\n\r\n## Принципы, на которых построен план\r\n\r\nПрежде чем смотреть календарь, четыре принципа. Без них план превращается в набор дел.\r\n\r\n**1. Между волнами обязательны правки.** Волна тестирования, после которой ничего не изменилось, — потраченные деньги. Если в графике нет дней на исправления, уменьшайте число волн, а не время на правки.\r\n\r\n**2. Каждая волна проверяет другую область или другую версию.** Три волны по одному и тому же чек-листу на одной сборке дадут одну и ту же информацию трижды.\r\n\r\n**3. Последняя волна — регресс, а не поиск нового.** В день 12 вы не хотите узнать о новой большой проблеме. Вы хотите подтвердить, что исправленное работает и ничего не сломалось.\r\n\r\n**4. Критерии готовности к релизу зафиксированы заранее, до первой волны.** Иначе в день 13 они подстроятся под то, что получилось.\r\n\r\n| Принцип | Что нарушается без него |\r\n|---|---|\r\n| Правки между волнами | Покупаете одну находку многократно |\r\n| Разные области по волнам | Теряете покрытие продукта |\r\n| Финальная волна = регресс | Узнаёте о блокере накануне релиза |\r\n| Критерии заранее | Решение о релизе становится эмоциональным |\r\n\r\n![Календарный план soft launch: волны тестирования и дни на исправления](inline-mid.jpg)\r\n\r\n## Календарь: дни 1–3, подготовка\r\n\r\n**День 1. Фиксируем предмет проверки и критерии готовности.**\r\n\r\nЛена выписывает три вещи.\r\n\r\nВо-первых, ключевое действие продукта: «создать общий список и получить в него второго участника». Не «зарегистрироваться», не «открыть приложение» — именно то действие, после которого продукт имеет смысл.\r\n\r\nВо-вторых, критические сценарии, которых оказалось четыре: регистрация и первый вход; создание списка и приглашение; выполнение и синхронизация задач между двумя участниками; оформление подписки и её восстановление.\r\n\r\nВ-третьих, критерии готовности к релизу — их мы разберём отдельным блоком ниже, но пишутся они сегодня, в день 1.\r\n\r\n**День 2. Готовим инфраструктуру тестирования.**\r\n\r\n- Сборка в TestFlight для iOS, закрытый трек для Android.\r\n- Тестовые аккаунты, если они нужны для сценария синхронизации (для проверки «двух участников» нужен либо второй аккаунт, либо второй тестировщик).\r\n- Sandbox для платежей или промокоды: реальные деньги тестировщиков использовать нельзя.\r\n- Отдельная ссылка с параметрами для отделения тестовых установок от органических в аналитике.\r\n- Проверка, что базовые события логируются: иначе после релиза вы не увидите ничего.\r\n\r\n**День 3. Пишем чек-лист волны 1 и запускаем кампанию.**\r\n\r\nЧек-лист на 5 шагов, область — вход и первое ключевое действие.\r\n\r\n1. Откройте приложение, 15 секунд ничего не нажимайте. Напишите, что это за приложение и что оно предлагает. Скриншот обязателен.\r\n2. Пройдите регистрацию до главного экрана. Опишите каждое сомнение и каждую ошибку. Укажите способ регистрации и число попыток.\r\n3. Создайте список из трёх дел. Опишите путь и приложите скриншот результата.\r\n4. Найдите способ пригласить второго участника в список. Опишите, как искали и что произошло. Скриншот обязателен.\r\n5. Закройте приложение полностью и откройте снова. Опишите, что увидели.\r\n\r\nОбязательно: модель устройства, версия ОС, версия приложения.\r\n\r\nОбъём: 40 прохождений. Бюджет: 99 ₽ × 40 × 1,15 = **4 554 ₽**.\r\n\r\nКритерии приёмки публикуются вместе с заданием: все 5 шагов, скриншоты на шагах 1, 3, 4, указано устройство, ответы описывают действия.\r\n\r\n## Календарь: дни 4–6, первая волна и разбор\r\n\r\n**День 4–5. Отчёты приходят, Лена модерирует по мере поступления.**\r\n\r\nВажная деталь: не ждать все 40, а проверять партиями. Так к вечеру дня 5 уже есть картина, а не аврал.\r\n\r\nТаблица для разбора заполняется сразу: ID отчёта, устройство, версия ОС, шаг, где проблема, краткое описание, цитата, серьёзность.\r\n\r\n**День 6. Группируем находки и приоритизируем.**\r\n\r\nЛена получила 34 принятых отчёта из 40 (6 отклонены: 4 без обязательных скриншотов, 2 не на той платформе). Находки после группировки по причинам:\r\n\r\n| Находка | Частотность | Блокирует? | Приоритет |\r\n|---|---|---|---|\r\n| Не нашли кнопку приглашения участника (она в меню списка, а не на экране списка) | 22 из 34 | Да | 1 |\r\n| Описали приложение как «список покупок», не как семейный планировщик | 19 из 34 | Нет, но критично | 2 |\r\n| Ошибка при регистрации через Google на Android 13 | 7 из 34 | Да | 1 |\r\n| При повторном входе открывается пустой экран «Создать список», хотя список есть | 11 из 34 | Нет | 3 |\r\n| Непонятно, что список сохраняется автоматически, искали кнопку «Сохранить» | 9 из 34 | Нет | 3 |\r\n| Приглашение отправляется, но приглашённый не понимает, что делать со ссылкой | 6 из 34 | Да | 2 |\r\n\r\nПравило приоритизации: сначала блокирующие с высокой частотностью, затем всё, что затрагивает больше четверти людей, затем остальное.\r\n\r\nПриоритеты 1 и 2 идут в работу. Приоритет 3 — в бэклог после релиза.\r\n\r\n:::chart type=bar title=\"Находки волны 1 по частотности (из 34 отчётов)\"\r\nНе нашли приглашение участника|22\r\nНеверно понято назначение продукта|19\r\nПустой экран при повторном входе|11\r\nНе поняли автосохранение|9\r\nОшибка регистрации Google на Android 13|7\r\nПриглашённый не понял ссылку|6\r\n:::\r\n\r\n## Календарь: дни 7–9, исправления и вторая волна\r\n\r\n**День 7–8. Разработка вносит правки.**\r\n\r\nЧто делает команда Лены:\r\n\r\n- Кнопка «Пригласить» выносится на экран списка, крупно, с текстом-подсказкой при пустом списке участников.\r\n- Первый экран переписывается: вместо «Ваши списки» — короткая фраза о совместном использовании и иллюстрация с двумя участниками.\r\n- Чинится регистрация через Google на Android 13.\r\n- Экран приглашённого получает явное объяснение: кто пригласил, в какой список, одна кнопка «Присоединиться».\r\n\r\nПриоритет 3 сознательно откладывается: в 14-дневном плане нет места на всё, и попытка сделать всё — главная причина срыва таких планов.\r\n\r\n**День 9. Волна 2: проверка правок плюс новая область.**\r\n\r\nЧек-лист меняется. Шаги 1–4 повторяют волну 1 (чтобы сравнить с базой), шаги 5–6 добавляют новую область — синхронизацию между участниками.\r\n\r\n1. Первое впечатление без действий (повтор).\r\n2. Регистрация (повтор, с акцентом на Google на Android).\r\n3. Создание списка (повтор).\r\n4. Приглашение участника (повтор — главная проверяемая правка).\r\n5. Попросите знакомого принять приглашение либо примите его со второго устройства. Опишите, что увидел приглашённый и сколько времени заняло присоединение.\r\n6. Отметьте одну задачу выполненной. Проверьте, через сколько секунд изменение видно у второго участника. Приложите скриншот.\r\n\r\nОбъём: 30 прохождений. Бюджет: 99 ₽ × 30 × 1,15 = **3 415,50 ₽**.\r\n\r\nТребование к устройствам в задании: не менее 10 отчётов на Android 13 или новее.\r\n\r\n## Календарь: дни 10–12, третья волна\r\n\r\n**День 10–11. Разбор волны 2 и правки.**\r\n\r\nРезультат по главной правке: кнопку приглашения не нашли 2 человека из 28 принятых (было 22 из 34). Приложение назвали семейным планировщиком 21 из 28 (было 15 из 34 — точнее, правильно поняли только 15). Регистрация через Google — ошибок нет.\r\n\r\nНовые находки волны 2:\r\n\r\n- Синхронизация занимала до 40 секунд без индикации, 12 человек решили, что не работает, и обновляли вручную.\r\n- Приглашённый попадал в список, но не видел, кто ещё в нём участвует — 8 упоминаний.\r\n\r\nПервую правку делают сразу: локальное отображение изменения плюс индикатор синхронизации. Вторую — простой список участников в шапке.\r\n\r\n**День 12. Волна 3: платежи и регресс.**\r\n\r\nЭто последняя волна, и у неё двойная задача.\r\n\r\n1. Пройдите полный путь: регистрация → создание списка → приглашение → отметка задачи. Опишите, если что-то не работает. Скриншот финального состояния.\r\n2. Откройте экран подписки. Напишите своими словами, что даёт платная версия и сколько стоит.\r\n3. Оформите подписку по промокоду из задания. Опишите каждый экран. Скриншот подтверждения.\r\n4. Удалите приложение, установите заново, войдите и восстановите покупку. Опишите результат. Скриншот обязателен.\r\n5. Включите авиарежим, отметьте задачу, выключите авиарежим. Опишите, что произошло с изменением.\r\n\r\nОбъём: 25 прохождений. Бюджет: 99 ₽ × 25 × 1,15 = **2 846,25 ₽**.\r\n\r\nОбратите внимание на шаг 2: он проверяет не работу экрана, а его **понятность**. Это дешёвый способ найти проблему, которая после релиза выглядит как «низкая конверсия в подписку».\r\n\r\n## Календарь: дни 13–14, решение\r\n\r\n**День 13. Разбор волны 3 и финальные правки только критического.**\r\n\r\nПравило дня 13: правится **только то, что блокирует ключевой сценарий или теряет деньги**. Всё остальное — в бэклог первой недели после релиза. Любая необязательная правка в последний день — источник регрессии, которую уже некому проверить.\r\n\r\n**День 14. Решение по критериям, зафиксированным в день 1.**\r\n\r\nВот эти критерии. Они простые, проверяемые и написаны до того, как стало известно, что получится.\r\n\r\n| Критерий готовности | Порог | Проверяется |\r\n|---|---|---|\r\n| Ключевое действие выполнено | ≥ 85 % отчётов последней волны | Волна 3, шаг 1 |\r\n| Блокирующих проблем не осталось | 0 | Волны 2 и 3 |\r\n| Оплата и восстановление покупки работают | 100 % отчётов, где пробовали | Волна 3, шаги 3–4 |\r\n| Назначение продукта понято верно | ≥ 65 % отчётов | Шаг «первое впечатление» |\r\n| Покрытие устройств | ≥ 3 производителя, ≥ 2 версии ОС каждой платформы | Все волны |\r\n| Crash-free сессии | ≥ 99 % | Аналитика сборки |\r\n| Ключевые события логируются | Все из списка дня 1 | Проверка вручную |\r\n\r\nЕсли все строки зелёные — запуск. Если красная только одна и она не про блокеры и не про оплату — запуск с задачей в первую неделю. Если красная строка про блокеры или оплату — перенос, даже при договорённостях с каналами. Публикация в двух телеграм-каналах приведёт людей в приложение, где не работает оплата; это не экономия, а сожжённый канал.\r\n\r\nКоманда Лены закрыла все строки, кроме «назначение понято верно» — 61 % против порога 65 %. Решение: запуск, а переписывание первого экрана — задача первой недели.\r\n\r\n## Сводный бюджет и трудозатраты\r\n\r\n| Позиция | Объём | Стоимость |\r\n|---|---|---|\r\n| Волна 1: вход и ключевое действие | 40 | 4 554 ₽ |\r\n| Волна 2: проверка правок + синхронизация | 30 | 3 415,50 ₽ |\r\n| Волна 3: платежи и регресс | 25 | 2 846,25 ₽ |\r\n| Резерв на добор и бонусы | — | 1 200 ₽ |\r\n| **Итого на платформе** | **95** | **≈ 12 016 ₽** |\r\n\r\nВнутренние трудозатраты, которые тоже стоит посчитать:\r\n\r\n| Работа | Часы |\r\n|---|---|\r\n| Написание трёх чек-листов | 3 |\r\n| Модерация 95 отчётов | 6 |\r\n| Группировка находок и приоритизация | 4 |\r\n| Подготовка сборок и тестовых аккаунтов | 4 |\r\n| Разработка: правки по трём итерациям | 40–50 |\r\n\r\nИтого около 17 часов работы продакта и 40–50 часов разработки. Это и есть реальная цена плана: деньги — меньшая его часть.\r\n\r\n:::chart type=bar title=\"Распределение 14 дней по типам работ\"\r\nПодготовка|3\r\nВолны тестирования|6\r\nИсправления|4\r\nРешение и финальные правки|1\r\n:::\r\n\r\n## Что делать, если план сорвался\r\n\r\nРеалистичная часть. Три типичных срыва и что с ними делать.\r\n\r\n**Срыв 1: волна 1 нашла блокер, на исправление которого нужна неделя.**\r\n\r\nНапример, синхронизация в принципе работает нестабильно, это архитектурная проблема. Решение: сократить объём релиза. Запускайтесь без функции, которая не работает, если продукт без неё имеет смысл. Если не имеет — переносите дату. Выпускать неработающее ключевое действие бессмысленно: вы получите отзывы, которые потом придётся отрабатывать месяцами.\r\n\r\n**Срыв 2: отчёты приходят медленно, волна 1 набирается 4 дня вместо 2.**\r\n\r\nПричины обычно две: слишком узкие требования к устройствам или слишком низкая ставка для сложного задания. Решение: повысить ставку на следующие волны и расширить требования, а график сжать за счёт сокращения волны 3 до 15 прохождений.\r\n\r\n**Срыв 3: правки внесли, но волна 2 показала те же проблемы.**\r\n\r\nЗначит правка не устранила причину — вы исправили симптом. Это очень ценная информация, которую вы получили за 3 400 ₽ вместо того, чтобы узнать её из отзывов после релиза. Возвращайтесь к отчётам волны 1 и читайте цитаты внимательнее: обычно причина описана, но была понята неверно.\r\n\r\n:::compare\r\nПлан без волн тестирования|План с тремя волнами\r\nПроблемы находят пользователи после релиза|Проблемы находят до релиза\r\nПервые отзывы формируют рейтинг на месяцы|Рейтинг формируется на исправленной версии\r\nПравки идут хотфиксами под давлением|Правки идут в плановом режиме\r\nРешение о релизе принимается на ощущениях|Решение принимается по зафиксированным критериям\r\nЭкономия ≈ 12 000 ₽|Расход 12 000 ₽ и понимание, что запускаешь\r\nНет данных о покрытии устройств|Известно, на чём проверено\r\n:::\r\n\r\n## Вариант плана на 7 дней, если времени совсем нет\r\n\r\nИногда 14 дней нет. Минимальная работающая версия:\r\n\r\n| День | Что делать |\r\n|---|---|\r\n| 1 | Критерии готовности, ключевое действие, сборка, тестовые аккаунты |\r\n| 2 | Волна 1: 25 прохождений, вход + ключевое действие (2 846 ₽) |\r\n| 3 | Модерация и группировка находок |\r\n| 4 | Правки только блокирующих проблем |\r\n| 5 | Волна 2: 20 прохождений, повтор чек-листа + платежи (2 277 ₽) |\r\n| 6 | Модерация, критические правки |\r\n| 7 | Решение по критериям |\r\n\r\nБюджет ≈ 5 123 ₽. Покрытие меньше, но блокеры входа и проблемы с оплатой вы найдёте — а это те две области, где ошибка дороже всего.\r\n\r\nЧто при этом сознательно теряется: проверка краевых случаев, покрытие редких устройств, вторая итерация по формулировкам. Это допустимый компромисс, но он должен быть осознанным, а не случайным.\r\n\r\n:::quiz\r\nДо релиза 3 дня. Волна тестирования показала: ключевое действие выполняют 87 % тестировщиков, но восстановление покупки после переустановки не работает у всех, кто пробовал. Что делать?\r\nA) Запускаться: ключевое действие работает, восстановление покупки — редкий сценарий\r\nB) Запускаться и починить восстановление покупки в первом обновлении\r\nC) Перенести релиз до исправления: неработающее восстановление покупки означает, что заплатившие люди теряют доступ\r\nD) Запускаться, но отключить подписку до исправления\r\nПравильный: C\r\nПояснение: критерий «оплата и восстановление покупки работают» относится к деньгам пользователей и не допускает компромисса: человек, заплативший и потерявший доступ, гарантированно оставит негативный отзыв и запросит возврат. Варианты A и B недооценивают частоту переустановок и смены устройств. Вариант D выглядит аккуратнее, но убирает монетизацию и всё равно требует релиза с изменением — проще починить сам механизм.\r\n:::\r\n\r\n## FAQ\r\n\r\n**Почему три волны, а не две или четыре?**\r\nТри — минимум, при котором есть проверка правок (волна 2) и регресс перед релизом (волна 3). Четвёртая волна полезна, если продукт большой, но она требует ещё 3–4 дней на цикл правок, а в 14 днях их нет.\r\n\r\n**Можно ли запускать волны параллельно, чтобы сэкономить время?**\r\nПараллельно имеет смысл только для разных платформ или совсем разных областей продукта. Параллельные волны по одной области на одной сборке — это одна волна, разбитая пополам, без выигрыша в информации.\r\n\r\n**Сколько прохождений минимально в волне?**\r\n15–20. Меньше — вы найдёте блокеры, но не оцените частотность и не покроете устройства.\r\n\r\n**Что делать с приоритетом 3, который отложили?**\r\nЗаведите его в бэклог сразу с частотностью и цитатами. Через месяц после релиза вы будете решать, что делать дальше, и эти записи окажутся лучшим источником задач.\r\n\r\n**Нужно ли тестировать после релиза?**\r\nДа, и первая волна после релиза особенно полезна: она проходит на продакшн-версии, с реальным стором, реальной оплатой и без тестовых упрощений. Планируйте её на первую-вторую неделю.\r\n\r\n**Как понять, что критерии готовности слишком мягкие?**\r\nЕсли вы можете выполнить их все без единой правки — они слишком мягкие. Хорошие критерии в первой волне обычно не выполняются: в этом и смысл.\r\n\r\n## Итоги\r\n\r\n- План на 14 дней делится так: 3 дня подготовка, три волны тестирования с днями на правки между ними, 2 дня на решение и финальные критические правки.\r\n- Критерии готовности к релизу фиксируются в день 1, до первой волны, иначе они подстроятся под результат.\r\n- Объёмы волн: 40 на вход и ключевое действие, 30 на проверку правок плюс новую область, 25 на платежи и регресс. Всего 95 прохождений, около 12 000 ₽ с комиссией.\r\n- Между волнами обязательны правки; волна без изменений в продукте покупает одну и ту же информацию повторно.\r\n- Последняя волна — регресс, а не поиск нового. В день 13 правится только то, что блокирует сценарий или теряет деньги.\r\n- Неработающая оплата или восстановление покупки — единственное безусловное основание перенести релиз, даже при зафиксированных договорённостях о публикациях.\r\n- Если времени только неделя, работает сокращённая версия на 45 прохождений и 5 123 ₽: она закрывает блокеры входа и платежи.\r\n\r\n## Заключение\r\n\r\nКоманда Лены запустилась в срок. К вечеру дня релиза из двух телеграм-каналов пришло около 1 900 установок. Ключевое действие — создание общего списка с приглашённым участником — выполнили 54 % пришедших, retention D1 составил 41 %.\r\n\r\nЗа две недели до этого кнопку приглашения не могли найти 22 человека из 34. Если бы эти 1 900 человек пришли на ту версию, история запуска была бы другой — и её нельзя было бы переиграть, потому что первые отзывы и первый рейтинг формируются один раз.\r\n\r\nДвенадцать тысяч рублей и семнадцать часов работы. Основная ценность плана не в деньгах, а в том, что в день 14 решение принималось по таблице с порогами, а не по ощущению «вроде готово».\r\n","\u002Fstorage\u002Farticles\u002F49-plan-soft-launch-14-dney\u002Fcover.jpg","https:\u002F\u002Fmanica.mrdev.ru\u002Fstorage\u002Farticles\u002F49-plan-soft-launch-14-dney\u002Fcover.jpg","\u002Fstorage\u002Farticles\u002F49-plan-soft-launch-14-dney\u002Finline.jpg",[],"2026-09-19T00:00:00+03:00",true,1,"Admin","2026-09-26T01:56:20+03:00"]