Пять нюансов при разработке ИТ-платформы
Цифровая платформа включает в себя набор программных инструментов (приложений, баз данных, средств разработки и пр.), которые упрощают и автоматизируют процессы. Благодаря платформе пользователи могут собрать собственное решение как из кубиков, выбрав необходимые компоненты.
Платформы для разработки могут включать инструменты для автоматизации, оптимизации и ускорения процесса создания ПО. Облачные платформы предоставляют набор IaaS- и PaaS-сервисов для построения ИТ-инфраструктуры, необходимой для цифрового развития компании. Платформы для коммуникаций и совместной работы, например VK Teams, позволяют обмениваться сообщениями в мессенджере, проверять почту и планировать встречи в календаре с уведомлением всех участников. Платформы для команд маркетинга умеют автоматически создавать приложения для мероприятий. Финансовые платформы дают пользователям возможность управлять активами из разных источников в режиме единого окна.
Благодаря платформам пользователи могут сосредоточиться на бизнес-задачах. Им не нужно заботиться о совместимости, актуальности версий инструментов и их обновлении. Более того, так реализуется современный no-code-подход, когда пользователи решают свои задачи без привлечения разработчиков.
Желание компаний предоставлять внутренним или внешним пользователям сложную функциональность в одном окне понятно, но практика только накапливается. В этом смысле в России платформенные решения вписываются в мировой тренд — предприятия активно накапливают экспертизу. На конференциях появляются специальные секции Platform Engineering, где специалисты ведущих компаний делятся своим опытом в построении комплексных отраслевых платформ.
Компании используют платформы сторонних разработчиков или создают их сами. При самостоятельной разработке важно обратить внимание на несколько принципиальных моментов. Их игнорирование может затянуть процесс или свести пользу от применения платформы к нулю.
Нюанс 1. Формулирование четкой цели создания платформы
Идеальное состояние платформы — это интеграция инструментов, знаний и процессов, предоставляемая как сервис. При проектировании главное не забыть, что цель — не объединение инструментов, а снижение нагрузки на пользователя: он должен получить в едином окне доступ к большому количеству функций, относящихся к его бизнес-задачам. Например, платформа для налогового мониторинга VK Tax Compliance автоматизирует и оптимизирует бизнес-сценарий, состоящий из большого количества этапов, инструментов и процессов, ручная настройка и поддержка которых требуют времени и инвестиций.
Если нет стратегии, сфокусированной на пользовательском опыте и учитывающей существующие процессы, возникает риск создания платформы ради платформы. В этом случае продукт будет не востребован, а инвестиции потеряны. Без понимания пользы от нового решения сотрудники вернутся к старым инструментам в теневом режиме, формируя параллельный операционный мир.
Например, CRM-системы часто рассчитаны на определенные бизнес-процессы, включая управление проектами. Внедрение отдельной платформы для управления проектами без обоснованной цели может привести к увеличению времени на формальное заполнение нового интерфейса, но не улучшит эффективность команды.
Нюанс 2. Формирование команды и ее позиционирование
«Платформенная команда» или любое другое абстрактное название группы разработчиков, создающих платформу, ничего не говорит о ней будущим пользователям. Однако одно из важнейших условий эффективной работы команды — то, как она воспринимается остальными сотрудниками компании. Все должны понимать, чем занимается новая команда, в каких случаях с ней взаимодействовать: на какие встречи приглашать и кого из сотрудников в нее делегировать. Например, при создании платформы налогового мониторинга финансовый отдел понимает, что стоит включить в команду своего специалиста для описания необходимых функций и оценки хода реализации проекта.
В противном случае уже в процессе создания новой команды может быть заложено организационное бутылочное горлышко. Команда становится ответственной за важный цифровой продукт, но, будучи частью старой организационной структуры, не отвечает за обновленный пользовательский опыт и бизнес-задачи. Она формирует исключительно технологическую часть, игнорируя запросы будущих пользователей.
Нюанс 3. Создание технологического бренда и вовлечение пользователей
Платформы предназначены для того, чтобы снизить время сотрудников на выполнение задач за счет интегрированных автоматизированных инструментов Например, платформа дистанционного банковского обслуживания Газпромбанка передает данные во внутренние и клиентские приложения из разных источников — от биржевых курсов до СУБД с данными пользователей.
Для быстрого освоения сотрудниками всех возможностей платформы часто используются обучение и дополнительная мотивация. Эффективность обучения зависит от того, кто его разрабатывал. Если команда платформы состоит из одних инженеров, то эта задача, скорее всего, уйдет в более подходящие департаменты — например, развития или HR. Но это не лучший путь.
Намного эффективнее, когда появляются люди, которые отвечают за вовлечение пользователей на кросс-командном уровне. Внутри классической организационной структуры создаются новые роли — Developer Advocate, Platform Advocate и т. д. Их задача — создать технологический бренд продукта (в данном случае платформы), вовлекая новых пользователей совместно с коллегами из подразделений маркетинга, обучения, HR и команды платформы.
Без должного внимания к обучению сотрудников новый продукт рискует остаться без пользователей. Руководителям, которые инвестировали в проект много средств, придется перейти к директивным мерам, которые ломают привычные процессы пользователей. В результате эффект от внедрения платформы в лучшем случае будет нулевым.
Нюанс 4. Выбор инструментов для платформы
Платформа может объединять как готовые инструменты, так и самостоятельно разработанные компанией. Рассмотрим три основных подхода.
Купить
Если позволяет бюджет, этот вариант предпочтителен, так как инструмент становится доступен сразу. Можно высвободить ресурсы для других бизнес-задач и отвлечься от проблем поддержки — ключевой статьи бюджета, отличающей кастомное ПО от купленного. Скорее всего, уровень информационной безопасности такого продукта будет гораздо выше, особенно если у инструмента есть большие клиенты-вендоры, которые требуют серьезных мер безопасности. Стартовые инвестиции могут показаться значительными, однако часто оказываются оправданными по итогам анализа рисков и стоимости поддержки системы.
Воспользоваться готовым
На базе компонентов Open Source можно в довольно сжатые сроки создать необходимый инструмент собственными силами или с помощью подрядчиков. Изначальные вложения при такой модели разработки невысоки, но возникают риски для информационной безопасности и поддержки кода в будущем. Суммарная стоимость вложений в долгосрочной перспективе часто оказывается выше, чем у готовых коммерческих продуктов.
Построить свое
В этом случае компания должна иметь квалифицированную команду разработчиков или заказать создание продукта серьезному подрядчику. Без готовой команды и опыта заказной разработки такой подход может оказаться слишком дорогим и привести к затягиванию сроков или остановке проекта.
Нюанс 5. Микросервисный подход и middleware
Часть инструментов может быть куплена, часть — разработана с нуля или на основе готовых компонентов. В результате они могут различаться по своей реализации настолько, что выравнивание их по единому знаменателю и интеграция в рамках платформы потребуют значительных вложений. Поэтому в индустрии развивается разработка по принципу Thinnest Viable Platform (минимально работоспособная платформа).
При таком подходе разработчики не пытаются объединить всё и сразу, а сосредотачиваются на внутренних системах, которые вызывают наибольшие проблемы у пользователей. Для их интеграции используется middleware — ПО промежуточного слоя, задача которого быть «переводчиком» между системами. Это и есть минимально работоспособная платформа, которая позволяет разработчикам быстро выдать результат в виде пользовательского интерфейса.
Например, платформа для коммуникаций и совместной работы VK Teams включает в себя более 100 микросервисов, 30 из которых работают на middleware Tarantool. Это позволяет снижать нагрузку на корневые системы.
Внедрение middleware как базы для специализированной цифровой платформы позволяет предоставлять сервис пользователям и по частям подключать новые инструменты или изменять существующие. Результат — значительно ускоряется процесс внедрения нового продукта, его развития и адаптации к новым запросам бизнеса.
Платформенный подход — ключевой тренд в ИТ
Создание платформы — сложный и трудоемкий процесс. Круг задач при ее разработке выходит далеко за рамки технических вопросов. Однако компаниям, которые хотят сохранить конкурентоспособность, придется их решать — самостоятельно или заручившись поддержкой технологического партнера, имеющего соответствующие опыт и компетенции.
По прогнозу аналитиков Gartner, к 2025 году 70% новых приложений будут разрабатываться с использованием low-code/no-code-подхода. Это станет возможным в том числе благодаря цифровым платформам, которые помогут бизнесу высвобождать ресурсы и ускорять выпуск инновационных продуктов.
Опубликовано 21.09.2023
