Когда говорят о Product Life Cycle, чаще всего вспоминают красивую кривую из учебника: вывод на рынок, рост, зрелость, спад. На практике это не график, а конкретный момент, когда нужно решить, что делать с продуктом, который ещё работает, но уже не отвечает реальности рынка.
У нас в Связьком такой момент случился с платформой SMSC.
SMSC (Short Message Service Centre) — это аппаратно-программный комплекс, который обеспечивает приём и передачу SMS-сообщений в сети мобильного оператора. Через него проходит весь SMS-трафик: личная переписка абонентов, банковские уведомления, одноразовые коды подтверждения, сервисные сообщения от приложений. Без SMSC оператор физически не может предоставлять SMS-сервис.
Классическая версия SMSC, обкатанная годами в реальных сетях, отлично закрывает базовые задачи оператора. Но со временем индустрия вокруг изменилась: выросли требования к маршрутизации, стало больше A2P-интеграций с собственной логикой, короче стали сроки, за которые оператор должен запустить новую услугу или подключить корпоративного клиента. Классическая архитектура эти нагрузки выдерживает, но каждое изменение конфигурации требует всё большей осторожности от инженеров оператора.
Это и есть тот самый архитектурный потолок, о котором говорит PLC. Продукт не стал плохим — просто рынок ушёл вперёд, и то, что раньше было нормой, начало становиться ограничением.
В этой точке у любой компании есть два соблазнительных, но неверных пути. Первый — латать классическую архитектуру до бесконечности, накапливая технический риск и теряя конкурентоспособность. Второй — резко вывести старую версию с рынка и заставить всех клиентов мигрировать одним днём, разрушив доверие и стабильность тех, кто строил на этой платформе годы работы. Оба пути — это реакция на стадию спада, а не управление ею.
Мы выбрали третий путь. Основной вектор развития — новая платформа, в которой упор сделан на предсказуемость изменений: инженер оператора видит, как новая конфигурация поведёт себя, до того как она попадёт на боевой трафик. Это принципиально иной уровень контроля над рисками, чем в классической архитектуре, где часть проверок неизбежно приходится делать уже на живых клиентах.
При этом классическая версия не списана в архив. Она и сегодня устанавливается клиентам с ограниченным бюджетом или узкоспецифичными задачами, где вся гибкость новой архитектуры избыточна. Это решение не от нехватки ресурсов: классическая версия проверена годами эксплуатации в реальных сетях, и её поддержка не отнимает у нас значительного ресурса. Новая платформа становится стандартом для новых внедрений, но мы не заставляем мир подстраиваться под наш продуктовый roadmap, если у клиента другая задача и другой бюджет.
Именно в этом, кажется, и заключается практический смысл управления Product Life Cycle: не выбор «оставить или выпилить», а понимание, какая стадия жизни продукта подходит какому клиенту и сколько ресурса каждый сценарий реально требует.
