Запуск продукта — это не дата, а система готовности

Я доделал «Центр запуска продукта» в 7LAMP и понял, что самое честное — написать не про то, что там есть, а про то, почему вообще понадобилось отдельное место для запусков.

Вроде бы всё уже есть: доска задач, чаты, документы. Но к каждому релизу одна и та же история — за неделю до срока выясняется, что половина вещей не сделана, никто не в курсе, и все по-разному понимают, что значит «готово».

Дата не умеет думать

Обычно запуск выглядит так: назначаем дату, раскидываем задачи, начинаем двигаться. Дата стоит в календаре, и вся команда на неё ориентируется.

Но «релиз 20 июня» — это не план. Это пожелание. Оно не говорит, что именно должно быть готово. Не показывает, кто за что отвечает и где уже началось отставание. Дата хороша как ограничение, но плоха как инструмент управления.

Мне хотелось, чтобы главным был не календарь, а путь к готовности. Число важно, но вопрос не «успеваем ли к числу», а «есть ли у нас право выпускать продукт?».

Почему всё разваливается

Каждый раз перед запуском одна и та же картина. Разработка говорит «мы закончили», но приёмочные критерии не пройдены. Тестирование провели кусками. Обучение поддержки забыли поставить в план. Материалы для клиентов лежат в черновиках. А ответственный за важную веху вообще не знает, что она просрочена.

Люди не плохие и не ленивые. Просто всё это разбросано: часть в доске задач, часть в чатах, часть в головах. Когда информация размазана, картину не собрать.

Готовность — не ощущения, а факты

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

Вместо «почти готовы» — «пять из семи критериев закрыто». Вместо «успеваем» — «веха горит через три дня, работа не начата». Вместо «разберёмся» — «запуск под угрозой».

Когда у каждого утверждения есть проверяемая основа, разговор становится другим.

Это не доска задач

Внутри Центра запуска есть рабочие потоки, но сам модуль — не очередная доска. Потому что доска отвечает на вопрос «что мы делаем». А запуск — на вопрос «готовы ли мы к релизу». Это разные вопросы.

Можно закрыть сотню задач и оказаться не готовыми. Можно иметь «зелёную» доску, но забыть про обучение, документацию или проверку ключевого сценария. Задачи — часть картины, но не вся картина.

Я специально не стал делать ещё одну доску. Запуск — это отдельная сущность со своими вехами, критериями, владельцами и рисками. Универсальный список тут не работает.

Статус, который не врёт

Система сама определяет статус запуска. Всё спокойно — «В норме». Поджимают сроки — «Под риском». Срок сорван — «Заблокировано». Лента «Требует внимания» показывает только критичные точки: просроченные вехи, горящие сроки, рискованные задачи.

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

Тут вообще принцип: ERP должна не вываливать данные, а говорить «посмотри сюда, тут может сорваться».

Что на самом деле меняется

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

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

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

Зачем всё это

Я сделал Центр запуска не ради очередной вкладки в ERP. Я сделал его, потому что для компании, которая выпускает продукты постоянно, нельзя каждый раз героически собираться перед релизом и вспоминать: «так, а что мы забыли?»

Нужна повторяемая модель. Каркас: этапы, вехи, критерии, ответственные, сроки, риски. Чтобы команда не держала всё в голове.

Запуск продукта — это не подвиг в ночь перед сроком. Это система готовности. И если она спроектирована правильно, то честно отвечает на вопрос: имеем ли мы право двигаться дальше.