Почему разработка бизнес-приложений становится сложнее и дороже, а бизнес не получает от этого дополнительной выгоды? Как найти баланс между сложностью разработки и реальными результатами для бизнеса?
Технологический прогресс, но где результаты?
ИТ-индустрия развивается стремительно, и вместе с этим растут размеры команд, которые занимаются созданием бизнес-приложений. Но как так получилось, что приложения, разрабатываемые сегодня, не сильно отличаются от тех, которые можно было создать двадцать лет назад силами одного человека? В чём прогресс?
Сейчас для создания простейшего бизнес-приложения на стеке Open Source требуется целая команда: бизнес-аналитик, дизайнер, бэкенд-разработчик, фронтенд-разработчик, инженер по качеству, специалист DevOps и руководитель проекта. Приложение, которое они создадут — будь то система управления заказами или планирование отпусков, — по функциональности не будет сильно отличаться от программы, которую можно было разработать два десятилетия назад. Получается, что мы усложняем процесс, но не получаем пропорциональной выгоды. Поэтому назрела необходимость приведения сложности разработки в соответствие с тем, какую ценность бизнес получает от этого.
Проблемы традиционной разработки
С начала 2000-х годов мир корпоративного ПО перешёл от настольных приложений к веб-разработке. Этот переход ускорился, и веб-приложения стали стандартом для внутренних систем. Их популярность обусловлена преимуществами, которые они предлагают: кроссплатформенность, простота обновления и удалённый доступ к данным предприятия.
В отличие от настольных приложений, которые зависели от операционной системы и требовали сложных процедур установки и обновления, веб-приложения открываются через браузер, а их обновления можно производить централизованно. Это снижает эксплуатационные издержки. Однако сама разработка таких приложений оказалась сложнее из-за множества технологий, используемых как на стороне клиента (фронтенд), так и на стороне сервера (бэкенд).
Задачи по обеспечению безопасного сетевого взаимодействия, управлению состояниями пользователей, поддержке высокой производительности при большом количестве одновременных пользователей добавляют новые слои сложности. Эти сложности влекут за собой рост требований к интерфейсу, интеграции с сервисами и API, а также потребность в квалифицированных специалистах. Таким образом, разработка усложняется, команды растут, но бизнес часто не видит явных преимуществ от этого.
Технологический прогресс и его цена
Можно сказать, что прогресс в технологиях привёл к тому, что некоторые старые специальности ушли — например, системные администраторы баз данных уже не так востребованы, как раньше. Но команду разработки сильно уменьшить всё равно не удастся. Даже если исключить одного-двух специалистов, пяти человек в команде, скорее всего, не избежать.
Рассмотрим ситуацию: бизнес ставит задачу модернизировать систему управления снабжением. Новые требования включают интеграцию с внешнеэкономическими сервисами и B2B-маркетплейсами. Что изменится для пользователей системы? Возможно, интерфейс станет немного удобнее, но кардинальных улучшений они вряд ли заметят. При этом бизнес не получит ощутимого эффекта от повышения нефункциональных характеристик, таких как надёжность или производительность. Для простейших систем, которые занимают до 80% ИТ-ландшафта предприятия, эффект от улучшений может быть минимальным.
Получается, традиционная разработка оправдана только для критических информационных систем — тех, от которых напрямую зависит работа компании. Такие системы требуют высокой надёжности и масштабируемости. Например, это может быть автоматизация управления производственными процессами или обслуживание клиентов через цифровые каналы. Но как быть с остальными системами, которые не являются критически важными, но необходимы для выполнения повседневных задач?
Альтернативы традиционной разработке: 1С и Low-code
Для разработки рутинных бизнес-систем традиционно выбирают готовые решения на базе платформ вроде «1С: Предприятие» или систем Low-code. Но тут возникает вопрос: можно ли с помощью этих подходов достичь баланса между затратами и выгодой для бизнеса?
В проектах на платформе «1С: Предприятие» часто участвуют специалисты, стоимость которых выше, чем у веб-разработчиков. При этом команда всё равно нужна сопоставимая по численности, за исключением дизайнера — интерфейс автогенерируется и не требует сильной кастомизации. Как же так получилось, что «1С», которая считалась альтернативой традиционной разработке, по стоимости и срокам стала с ней сопоставима?
Причина кроется в лавинообразном спросе на специалистов «1С». В российском бизнесе зачастую предпочитают разрабатывать системы «с нуля» на «1С», вместо того чтобы выбирать одно из тысяч готовых решений. Освоение технологии «1С» требует времени, и оно сравнимо с обучением работе на Open Source. Платформа «1С» остаётся изолированной, и разработчики с других стэков не спешат её осваивать, как и специалисты «1С» не стремятся перейти на популярные языки вроде Java.
В результате разработка на «1С» не даёт ощутимого снижения стоимости, а её закрытая экосистема ограничивает возможности внедрения инноваций.
Проблемы Low-code платформ
Low-code платформы задумывались как инструмент для упрощения разработки, чтобы бизнес-пользователи могли создавать приложения сами, без участия разработчиков. Однако по мере того, как платформы становились функциональнее и гибче, они усложнялись. Теперь для работы с ними требуются специальные навыки, а найти специалистов, которые умеют эффективно использовать Low-code, становится всё труднее.
Low-code разработчики стоят дороже, чем специалисты «1С», а стоимость лицензий и пакетов поддержки часто сводит на нет все экономические преимущества этого подхода. К тому же платформа всё ещё зависит от вендора, что создаёт замкнутый круг, в котором бизнес оказывается привязанным к одному поставщику и несёт дополнительные издержки.
Почему все варианты дороги и сложны?
Возникает закономерный вопрос: почему ни один из вариантов разработки не даёт ощутимого снижения стоимости или улучшения бизнес-эффектов, кроме разработки критических систем? Ответ прост: проблема не в технологиях. Все современные инструменты созданы для того, чтобы облегчить жизнь разработчикам и бизнесу, а не усложнить её.
Проблема в том, что технологии часто применяются не по назначению или выбираются без должной аналитики. Компании выбирают решения, о которых «слышали», но не всегда оценивают их долгосрочные последствия. Технологии для цифровизации и автоматизации должны быть инструментом, который помогает решать реальные бизнес-задачи, а не просто «галочкой» для отчётов.
Рекомендации по выбору инструментов
Как выбрать правильный технологический стек для разработки корпоративных систем? Универсального решения нет. Важно понимать задачи, которые нужно решить, и возможности команды.
Первый шаг — это классификация цифрового продукта или проекта, который планируется реализовать. Хотя существует большое разнообразие корпоративных систем, их можно расположить в пространстве с двумя осями: критичность системы и масштаб её использования. В левой верхней части этого пространства будут системы, от которых зависит работа всей компании. В правой нижней части — системы, которые используют небольшие группы пользователей (см. рисунок 1).
Рисунок 1. Классификация корпоративных приложений
На пересечении этих осей можно выделить несколько типов приложений. Системы в верхнем левом углу будут критически важными для бизнеса, их отказ может остановить работу компании. В правом нижнем углу — системы, которые используют небольшие группы сотрудников.
Теперь важно понимать, кто будет разрабатывать эти системы. Можно выделить три основных типа команд:
Индустриальная разработка — команды из нескольких десятков человек, состоящие из 3–5 полноценных групп.
Профессиональная разработка — команды из одного-трёх разработчиков, где каждый участник может работать и с фронтендом, и с бэкендом.
Гражданская разработка — разработкой занимаются продвинутые пользователи, не являющиеся профессиональными программистами.
Эти категории приложений и команды разработки можно наглядно соотнести друг с другом (см. рисунок 2).
Рисунок 2. Профили команд в зависимости от класса разрабатываемого приложения
Требования к разработке и командам естественным образом определяют выбор технологий. В идеале команды выбирают инструменты, которые подходят для их задач и компетенций.
Рисунок 3. Органичный выбор технологий и зависимость значений параметров оценки от выбора технологий
Важно, чтобы руководители команд знали, как лучше всего применить технологии, учитывая размер команды, её навыки и стратегические цели компании. Принятие решений должно быть основано на объективной оценке параметров, таких как скорость разработки, диапазон применимости технологии и степень контроля над системой.
Чек-лист для выбора технологии:
- Какого класса продукт планируется создать?
- Какие навыки есть у команды?
- Соответствует ли предлагаемая технология профилю задачи и команды?
- Позволяет ли предлагаемая технология реализовать проект в срок?
- Каковы ограничения применения технологии, и насколько вероятно столкнуться с ними?
- Легко ли найти разработчика для данной технологии на рынке труда?
- Соответствует ли технология стратегическим целям компании в области технологической независимости?
Эти вопросы очевидны, но часто ими пренебрегают, и именно поэтому возникают неудачи на проектах. На всех схемах присутствуют «пограничные зоны», где пересекаются области гражданской, профессиональной и индустриальной разработки. Эти зоны полны неопределённости. Снизить неопределённость можно через прототипирование, оценку результата на разных технологиях и получение метрик (см. рисунки 1–3).
Выбор инструментов для разработки должен быть прагматичным. Следуя рекомендациям по оценке проектов и возможностям команды, можно минимизировать риски и сократить затраты.