Как ускорить выход ИТ-продукта на рынок

Даже в высококонкурентных нишах вроде разработки AI.

Материал подготовлен экспертами Cloud.ru — российского провайдера облачных сервисов и AI-технологий для бизнеса.

Содержание

Time to market (TTM) — это скорость, с которой продукт проходит путь от этапа идеи до выхода на рынок хотя бы в версии MVP (от англ. minimal viable product — «минимально жизнеспособный продукт»). Если говорить про ИТ, то в TTM войдут этап разработки, тестирования и развёртывания приложения, а финалом будет дата релиза, когда им начнут пользоваться реальные клиенты.

Короткий time to market особенно важен в сферах с высокой конкуренцией. Например, две компании разрабатывают похожие по функционалу AI-приложения. Сейчас, когда тема искусственного интеллекта — один из главных трендов, большую часть рынка как минимум в короткой перспективе заберёт та компания, которая быстрее запустит свой продукт. И часто не так важно, будет ли второе приложение удобнее и функциональнее, если пользователи уже используют первое и рекламируют его друзьям и коллегам.

После начального ажиотажа приложение продолжит развиваться, обновления будут уже на уровне доработок фич (feature — функция, особенность) — это следующий уровень time to market. И ему тоже лучше пройти быстро: если новая фича в приложении конкурента потенциально принесёт ощутимый рост выручки, клиенту может быть выгоднее уйти к другому разработчику, даже несмотря на то, что миграция в ИТ чаще сильно дороже адаптации.

Большая часть современных ИТ-приложений — это в первую очередь разработка. Есть поддержка, масштабирование, обновление версий, но саму ценность клиенту несёт функциональность, то есть написанный код.

Чаще всего в разработке приложения участвуют трое: разработчик пишет код, инженер собирает релиз и разворачивает его на тестовой среде, а QA-инженер (специалист по обеспечению качества программного обеспечения), собственно, тестирует приложение. У каждого своя задача, но одна цель: быстрее отдать релиз в прод.

У разработчиков есть редакторы кода, например Visual Studio Code или IntelliJ IDEA, со встроенными функциями и инструментами, которые упрощают рутинные действия. Многие разработчики кодят с AI-сервисами: ChatGPT, GigaChat, Qwen. Есть модели, которые обучены именно кодить, поэтому работать руками приходится уже сильно меньше: искусственный интеллект не только оптимизирует код, чтобы он работал быстрее, но и вообще напишет его с нуля. Участие разработчика в самом процессе написания кода становится минимальным.

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

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

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

Облако — это всегда доступная инфраструктура и готовые PaaS-сервисы (platform as a service — платформа как услуга). В разработке его используют по-разному:

Облако вряд ли будет интересно самому разработчику: написать код он может с AI и на своём ноутбуке. Зато DevOps-инженер (ИТ-специалист общего профиля со знаниями в области разработки и эксплуатации) быстро соберёт в облаке даже очень специфическую среду и не будет думать о настройке, наладке, обеспечении безопасности и доступности самой инфраструктуры, потому что это забота облачного провайдера.

Опытные DevOps идут дальше и автоматизируют жизненный цикл тестовых сред в облаке: для каждого релиза тестовая среда сама будет создаваться в нужной конфигурации, отдаваться QA-инженеру для тестирования, а по завершении удаляться. При этом будут учитываться необходимые права доступа, лимиты и квоты, чтобы не выйти за рамки выделенных ресурсов и бюджета.

QA-инженер может автоматизировать в облаке процесс тестирования и выносить вердикт по релизу уже после того, как он будет проверен автоматическими средствами. Если релиз прошёл автоматические тесты, инженер проведёт ручное тестирование, данные по релизу сохранятся, а среда схлопнется. Если нет, вероятно, тестировщик даже не будет привлечён, а код вернётся разработчикам на доработку.

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

Формально пользователей облака можно разделить на два лагеря:

1. Те, кто использует IaaS (infrastructure as a service), то есть инфраструктуру как сервис: виртуальные машины, балансировщики нагрузки, S3-хранилища, IP-адреса, Bare Metal и так далее. В таких компаниях есть эксперты, которые умеют настраивать необходимые компоненты руками с нуля. Например, развернуть виртуальные машины, собрать на них кластер PostgreSQL, сделать performance tuning (процесс оптимизации и повышения производительности), настроить бэкапы и обеспечить безопасность. Многие компании с большим и сильным штатом ИТ предпочитают этот вариант.

2. Те, кто использует PaaS, то есть платформу как сервис: управляемые кластеры Kubernetes, базы данных, брокеры, кеши. Такие компании берут готовые компоненты для своих систем. Например, если приложение — это интернет-магазин, для него не придётся всё настраивать с нуля, можно поднять управляемый кластер Kubernetes, сервис кеширования и управляемую базу данных в виде PaaS-сервиса. Готовые сервисы — это про скорость и тех, кто готов делегировать настройку компонентов, безопасности и резервного копирования облачному провайдеру.

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

Возьмём, например, популярный среди B2C-сервисов подход к релизу новых версий под названием Canary, или «Канарейка». По этой стратегии развёртывания новые фичи и доработки релизят постепенно на небольшие группы пользователей и только потом обновляют основную версию. Подход удобный, чтобы быстро собрать обратную связь или откатить релиз к предыдущей версии, если возникает проблема. Другая сторона медали в том, что приложению одновременно нужны как минимум две среды: одна для основной версии, другая — для «канареечной». Ответ на вопрос «где разворачивать эти среды?» упирается в инфраструктуру. Если работать в облаке, такой вопрос не возникнет.

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

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

Перед тем как перейти в облако, компании рассчитывают экономическую целесообразность — это логично. Совокупная стоимость владения облаком включает преимущественно операционные затраты, а владения локальной инфраструктурой (on-premise) — это сумма капитальных (CAPEX) и операционных (OPEX) затрат.

Часто, анализируя издержки на локальное оборудование, компании учитывают только капитальные затраты и не учитывают стоимость обслуживания и поддержки. В реальности OPEX на on-premise достаточно высоки и неучёт этих расходов ведёт к ошибочным выводам об экономике локальной и облачной инфраструктур.

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

В любых.

С точки зрения самих проектов ограничений нет. Всё зависит от того, какой нужен уровень доступа к самому железу. Есть компании, которые хотят контролировать всё с самого низкого уровня, собирать строго кастомизированное железо и управлять им самостоятельно, — облака здесь, скорее всего, нет. А есть компании, которых устраивает, что команда ИТ находится не на уровне железа, а выше: на уровне виртуальных машин и готовых сервисов, — здесь уже можно говорить про облако.

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

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

CDO Global разворачивает в облаке среды разработки, чтобы создавать, тестировать и передавать заказчику готовые продукты по моделям SaaS и on-premise. Использует встроенный в облако функционал мониторинга ресурсов, чтобы создавать кастомные конфигурации виртуальных машин и самостоятельно управлять всей созданной инфраструктурой.

Особое внимание компания уделяет безопасности облака, понимая, что падение всей инфраструктуры от DDoS-атаки повлечёт за собой финансовый и репутационный ущерб и для неё, и для её клиентов. Отсюда требования к провайдеру: поддержка многоуровневой защиты облака и клиентских данных, соответствие российским законам и международным стандартам, наличие сервисов для защиты размещённых в облаке ресурсов.

А ваша компания уже использует облака для ускорения разработки? Делитесь в комментариях, какой был результат.