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

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

Пример (имена вымышленные, совпадения случайны):
продукт «Маркировка» целиком находится на стадии ЖЦ продукта «Операционный фонд». Но внутри него несколько программных продуктов, и каждый — на своей стадии:

• Маркировка.Веб — операционная деятельность
• Маркировка.1С — операционная деятельность
• Маркировка.Мобилка — масштабирование
• Маркировка.ВЭД — закрытие

Такое разделение позволяет предъявлять к каждому программному продукту, его команде и процессам свои требования и стандарты.

Если же в рамках продукта есть только один программный продукт, его стадия ЖЦ совпадает со стадией ЖЦ продукта в целом.

Данная классификация дополняет описание стадий жизненного цикла продукта, и сфокусирована на программном продукте.

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

0. Проверка гипотезы ценности и возможности реализации

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

Ключевые задачи
– Подтвердить, что проблема реальна и значима для достаточного сегмента клиентов.
– Убедиться, что проблему можно решить программным способом (а не только процессами или консалтингом).
– Сформулировать базовую ценностную гипотезу и первые метрики успеха.
– Понять, какие гипотезы стоит проверять дальше на этапе 1.

Ключевые риски
– Неправильная формулировка проблемы (решаем не то или слишком узкую/широкую задачу).
– Ориентация на «своё мнение» вместо реальных данных исследований.
– Слишком ранний уход в детальное решение и разработку.
– Игнорирование экономических ограничений, стоимость решения превосходит готовность клиента платить.

1. Проверка гипотезы решения

Этап, на котором команда создаёт первые версии программного продукта и проверяет, решают ли они подтверждённую на нулевой стадии проблему клиента.
Соответствует Стадия 1. Разработка продукта и запуск продаж в описании ЖЦ продукта. Разработка прототипа решения может происходить как с формированием полноценной команды разработки, так и с привлечением команды Бюро разработки или формированием мини-команды с AI-First подходом.

Границы и ключевые результаты:

• Максимальный результат за минимальные деньги.
• Результат ограничен той функциональностью, которая необходима в рамках проверки гипотезы

Продукты в Контуре могут попадать на этот этап разными путями:
– как новые гипотезы в рамках существующего продукта и его бюджета;
– как проекты Службы запуска и развития проектов (СЗРП);
– как инициативы, выходящие на инвесткомитет компании самостоятельно.

Как определить, что продукт на этом этапе

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

Ключевые задачи

• На основе целевых сегментов уточнить основные сценарии использования продукта.
• Выделить ядро продукта: минимальный набор функций, без которых ценность для клиента не появляется.
• Сконструировать и запустить первую версию программного продукта для проверки гипотез с реальными пользователями. Максимально переиспользовать существующие в компании решения и технологии.
• Настроить сбор обратной связи и базовых метрик использования (активность, удержание, удовлетворённость).
• Подготовить список гипотез, которые нужно проверить до перехода к масштабированию.

Ключевые риски

– Недостаток данных: выводы делаются по очень узкому кругу пользователей.

– Перегруз команды: совмещение плотных исследований с поддержкой первых клиентов без приоритизации.

– Слишком «толстая» первая версия: много функций до подтверждения базовой ценности.

– Преждевременная усложнённая архитектура и инфраструктура, не соответствующие масштабу продукта.
– Подмена проблемы: команда постоянно развивает решение(программный продукт), не возвращаясь к исходной задаче клиента.

Что происходит с различных точек зрения

Управленческая точка зрения

Происходит формирование  кросс-функциональной команды исследовательской (UX-исследователи, аналитики, продуктовые специалисты) и команды разработки. Планирование и организация исследовательской работы.

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

Техническое качество

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

Продуктовое качество

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

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

Создается система обратной связи для сбора информации о проблемах качества. Выстраивается взаимодействие с продающими и продвигающими подразделениями.

Пользовательская точка зрения

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

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

Ожидания от УР на этапе

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

2. Масштабирование

На этапе Масштабирования программный продукт переходит от первых подтверждений ценности к росту: увеличивается количество пользователей и объём использования, а команда готовит архитектуру, инфраструктуру и процессы к работе «на потоке».

Соответствует документу Стадия 2. Масштабирование в описании ЖЦ продукта.

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

На этапе бета-тестирования продукт предоставляется ограниченной группе пользователей для тестирования в реальных условиях перед полномасштабным запуском. Это позволяет получить более обширную обратную связь и выявить проблемы, которые не были замечены на этапе MVP.

Как определить, что продукт на этом этапе

– Ядро продукта стабильно: есть устоявшийся набор ключевых функций, которые регулярно используются и приносят ценность.
– MVP/первая версия успешно протестированы и получили положительную обратную связь от реальных пользователей.
– Есть подтверждённый интерес и потенциал роста: появляются новые сегменты или растут объёмы использования.
– Команда работает над масштабируемостью технической инфраструктуры и процессов (подготовка к росту нагрузки, более широкому запуску).
– Формируются процессы поддержки большего числа пользователей и расширяется функциональность.

Ключевые задачи

– Расширить функциональность на основе обратной связи пользователей, не ломая ядро продукта.
– Подготовить продукт и команды к полномасштабному запуску:
– сформировать команды для поддержки роста,
– оптимизировать ключевые процессы и пользовательские сценарии,
– устранить барьеры для масштабирования (узкие места в интерфейсе, процессах, регламенте).
– Подготовить техническую инфраструктуру к росту нагрузки:
– оптимизировать производительность и стабильность,
– улучшить мониторинг, логирование, автоматизацию деплоя.
– Разработать и проверить процессы онбординга и поддержки большего числа пользователей.
– Уточнить и «дотюнить» продуктовые метрики, по которым команда будет отслеживать успешность масштабирования.

Ключевые риски

• Преждевременное масштабирование: рост инвестиций и нагрузки без достаточного подтверждения ценности и устойчивого спроса.
• Техническая инфраструктура не выдерживает рост:
• деградация производительности,
• частые инциденты,
• сложности с масштабированием поддержки пользователей.
• Потеря фокуса на потребностях пользователей при расширении функциональности (раздувание продукта).
• Рост издержек быстрее, чем рост доходов: ухудшение unit-экономики.
• Выявление критических проблем, требующих серьёзной переработки архитектуры или ключевых сценариев.
• Утечка информации и неконтролируемые ожидания до официального релиза.

Управленческая точка зрения

– Формируется устойчивая команда, распределяются роли, появляется регулярный цикл планирования и выпуска версий.
– Появляются формальные процессы приоритизации, управления техническим долгом и согласования изменений с основными стейкхолдерами.
– Управленческие решения опираются на продуктовые и финансовые метрики, а не только на запросы отдельных клиентов. 

Техническое качество

– Рефакторится архитектура и код для работы под рост нагрузки, появляются явные границы модулей и сервисов.
– Развиваются CI/CD, мониторинг, логирование, алертинг, автоматизация деплоя и инфраструктуры.
– Управляются риски масштабирования: контроль производительности, отказоустойчивости, безопасности и техдолга.

– Соответствовать требованиям безопасности

Продуктовое качество

– Выстраивается системное тестирование: автоматизированные проверки, регрессы, нагрузочные и UX‑тесты.
– Вводятся критерии качества релизов (definition of done, уровни критичности дефектов, SLA на исправление).
– Культура качества становится частью повседневной работы команды, а не разовой инициативой.

Пользовательская точка зрения

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

3. Операционная деятельность (Опер. фонд)

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

3а. Операционная деятельность

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

Соответствует Операционному фонду по ЖЦ продукта.

Ключевые задачи на этапе поддержки и развития

– Поддерживать высокий уровень стабильности, производительности и надёжности программного продукта.

– Оптимизировать существующие процессы, функции и инфраструктуру (стоимость владения, эффективность эксплуатации).

– Адаптировать продукт к меняющимся потребностям пользователей и требованиям рынка (регуляторика, конкуренты, новые сценарии).

– Управлять техническим долгом и технологическим устареванием: планировать рефакторинг, миграции, модернизации.

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

Ключевые риски

– Технологическое устаревание: стек, архитектура или инфраструктура перестают соответствовать требованиям рынка и безопасности.

– Появление более быстрых и удобных конкурентов, из‑за чего продукт теряет привлекательность для пользователей.

– «Застой» продукта: снижение интереса пользователей из‑за отсутствия заметных улучшений и нововведений.

– Рост технического долга и усложнение поддержки, что делает изменения дорогими и рискованными.

– «Раздувание» функциональности: добавление множества функций без явной ценности, усложняющих продукт.

– Поддержка и развитие функциональности, которая потеряла актуальность для клиента.

– Потеря ключевых специалистов и выгорание команды из‑за длительной работы в режиме поддержки.

Управленческая точка зрения

– Балансировать ресурсы между поддержкой, развитием и возможной эволюцией продукта.

– Оптимизировать процессы и оргструктуру под «операционный режим», поддерживать мотивацию команды.

– Планировать долгосрочное развитие: когда вкладываться в модернизацию, когда готовиться к эволюции или закрытию.

Техническое качество

– Проводить регулярный технический аудит, модернизировать устаревшие компоненты и инфраструктуру.

– Оптимизировать производительность и стоимость инфраструктуры, автоматизировать рутинные операции и мониторинг.

– Поддерживать совместимость с новыми технологиями и платформами, снижать техдолг.

Продуктовое качество

– Поддерживать высокий уровень стабильности, безопасности и качества релизов.

– Развивать процессы обеспечения качества и реагирования на инциденты.

– Анализировать повторяющиеся проблемы и устранять их причины, а не только симптомы.

– Проводить плановые исследования пользователей на предмет переоценки ценностей и появления новых запросов

Пользовательская точка зрения

– Поддерживать высокий уровень удовлетворённости и доверия пользователей.

– Быстро реагировать на проблемы и запросы, работать с накопленной обратной связью.

– Улучшать пользовательский опыт на основе данных (поведение, NPS/CSAT), развивать сообщество пользователей.

3б. Эволюция продукта*

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

Цель — продлить жизнь продукта и сохранить его ценность для клиентов при изменившихся условиях. Этап дополняет стадию операционного деятельности и предшествует возможному закрытию. Фактически в этот момент продукт выходит на новый цикл жизни продукта.

3в.Подготовка  к закрытию

Не является самостоятельным этапом с точки зрения ЖЦ продукта. На этапе закрытия принимается решение о прекращении поддержки и развития программного продукта. Причинами могут быть технологическое устаревание, изменение бизнес‑приоритетов, неактуальность решаемой задачи, снижение рентабельности или замена другим продуктом (в том числе внутри Контура).
Этап опирается на регламент «проекта по закрытию продукта» и происходит в рамках стадии Операционный фонд в ЖЦ продукта.

Как определить, что продукт на этом этапе

– Длительное снижение ключевых показателей использования и/или выручки, несмотря на предпринятые меры.

– Изменение потребностей рынка или структуры клиентской задачи: продукт перестаёт решать актуальную проблему.

– Появление более подходящих внутренних или внешних решений, на которые логично переводить клиентов.

Ключевые задачи на этапе закрытия

– Принять и зафиксировать решение о закрытии продукта, определить рамки проекта по закрытию (сроки, объём, ответственность).

– Разработать и реализовать стратегию закрытия:
– спланировать и провести коммуникации с клиентами и внутренними стейкхолдерами,
– подготовить и выполнить миграцию пользователей на альтернативные решения,
– минимизировать негативный эффект для клиентов и бизнеса.

– Управлять техническим завершением продукта:
– план миграции и/или удаления данных,
– отключение интеграций и инфраструктуры,
– архивирование кода и документации.

– Перераспределить команду на другие продукты/проекты, сохранить ключевые компетенции и знания.

– Зафиксировать уроки и выводы по продукту, чтобы использовать опыт в новых инициативах.

Ключевые риски

– Репутационные риски при некорректном управлении процессом закрытия.

– Потеря ценных клиентов и снижение доверия к другим продуктам компании.

– Нарушение юридических и контрактных обязательств (в том числе по SLA, хранению и обработке данных).

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

Управленческая точка зрения

– Инициация и ведение проекта по закрытию продукта согласно регламенту.

– Планирование и контроль сроков, ресурсов, затрат и рисков закрытия.
– Управление коммуникациями с клиентами, руководством и командами, сохранение ключевых специалистов и знаний.

Техническое качество

– Планирование и выполнение миграции данных и интеграций, безопасное выключение инфраструктуры.

– Архивирование кода, конфигураций и документации, при необходимости — подготовка к возможному восстановлению.

– Обеспечение безопасности данных и соответствие требованиям по их хранению и удалению.

Продуктовое качество

– Поддержание минимально необходимого уровня качества и безопасности до полного закрытия.

– Контроль качества миграции и выключения (корректность данных, отсутствие критических инцидентов).

– Фиксация и анализ проблем, возникших в процессе закрытия, для улучшения будущих проектов.

Пользовательская точка зрения

– Прозрачная коммуникация с пользователями о причинах и сроках закрытия.

– Предоставление понятных маршрутов миграции и поддержки в процессе перехода.

– Работа с обратной связью пользователей, смягчение негативного опыта (при необходимости — компенсации, спецпредложения).

Материалы

1. Навигация по жизненному циклу продукта от МП
2. Exploit the Product Life Cycle. Harvard Business Review
3. Understanding the Stages of the Product Life Cycle. August 2021(.pdf версия)
4. Жизненный цикл продукта на примере АМСБ. Статья Жанны Шебаршовой
5. Product Life Cycle от Сергея Тихомирова
6. Видео-доклад в рамках Крэш-курса МРов.
7. Жизненный цикл стартапа от Бюро разработки