Десятилетия развития информационных технологий привели к тому, что для разработки простейшего бизнес-софта на стеке технологий Open Source сегодня требуется команда из семи человек: бизнес-аналитик, дизайнер, бэкенд-разработчик, фронтенд-разработчик, инженер по качеству, специалист DevOps и руководитель проекта. При этом созданное такой командой приложение, будь то система управления производственными заказами или система планирования отпусков сотрудников, по своим функциональным характеристикам не будет сильно отличаться от программы, которая могла быть разработана 20 лет назад силами одного человека. В чем тогда ощутимый результат технологического прогресса?

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

Проблемы традиционной разработки

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

Рост популярности веб-разработки в сфере корпоративного ПО был обусловлен необходимостью обеспечивать кроссплатформность, простоту обновления и удаленный доступ к сервисам и данным предприятия из любой точки физического пространства. В отличие от настольных приложений, которые зачастую зависят от ОС и требуют сложной процедуры развертывания и обновления, веб-приложения доступны через браузер и могут быть обновлены централизованно, что значительно снижает эксплуатационные издержки. Тем не менее разработка таких приложений зачастую сложнее, чем создание приложений на классической трехзвенной архитектуре из-за разнообразия технологий и инструментов, используемых для фронтенда и бэкенда. Необходимость обеспечения безопасного сетевого взаимодействия, управления состояниями и поддержки гарантированного уровня производительности для большого количества одновременно работающих пользователей добавляет слои сложности. В свою очередь, усложняются требования к пользовательскому интерфейсу, интеграции с многочисленными сервисами и API, а значит — растет потребность в квалифицированных разработчиках.

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

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

Предположим, бизнес ставит задачу отделу разработки или cлужбе заказчика модернизировать систему управления снабжением в соответствии с новыми бизнес-требованиями: интеграция сервисов внешнеэкономической деятельности, интеграция с B2B-маркетплейсами и т. д. Какие преимущества увидят пользователи вновь созданной системы? Руководители и сотрудники скорее всего оценят более дружественный пользовательский интерфейс. Впрочем, это вряд ли — часто систему просят сделать точь-в-точь, как прежде. Что же получает бизнес от повышения уровня нефункциональных характеристик и какие показатели деятельности это может улучшить? Для простейших бизнес-систем, которые занимают до 80% всего ИТ-ландшафта современного предприятия, эффект близок к нулю. Получается, что использование традиционной разработки (обычно на основе Open Source) целесообразно только для критических информационных систем предприятия, где высоки нефункциональные требования по масштабированию и устойчивости приложений. К критическим можно отнести класс информационных систем, остановка которых приведет к остановке деятельности предприятия или возникновению аварийной ситуации. Например, автоматизация учетных операций и управления производственным процессом или обслуживание покупателей по цифровым каналам, если это основной канал продаж. Что делать с остальными бизнес-системами, не относящимися к категории критических, но без которых невозможно с надлежащим уровнем качества обеспечить выполнение бизнес-функции? Для разработки рутинных и стандартизированных систем традиционно выбирают готовые решения на базе «1С: Предприятия» или ту или иную платформу Low-code. Можно ли достичь баланса бизнес-выгоды и стоимости разработки при выборе альтернативных подходов?

Проблемы разработки на платформе «1С: Предприятие»

В реализации корпоративных проектов на базе «1С: Предприятие» участвуют специалисты, стоимость которых превышает стоимость специалистов по веб-разработке, при этом требуется сопоставимая по численности команда. С большой долей вероятности в ней не будет дизайнера, так как платформа предоставляет автогенерируемый UI без сильной кастомизации. Как же получилось, что выбираемая в качестве альтернативы дорогой традиционной разработке разработка на «1С: Предприятии» стала сопоставимой по стоимости и продолжительности?

Причина — лавинообразный спрос, который когда-то закончится, и, возможно, тогда случится откат. Но это не точно. Российский бизнес вместо выбора и внедрения одного из 1000 готовых решений компании «1С» и ее партнерской сети разрабатывает для себя все сам, однако срок освоения технологии разработки сопоставим со сроком разработки на cтеке Open Source. По причине проприетарности платформы и изолированности ее экосистемы разработчикам с других технологических стеков переучиваться не захочется — как и разработчикам на базе «1С: Предприятия» переходить, например, на Java. Причина проста — потеря квалификации и заработка на период переучивания. К тому же до момента повышения спроса «1С»-разработчики искали возможность перейти на другие популярные технологии, а не наоборот.

При сохранении существующих тенденций удешевление разработки на технологической платформе «1С: Предприятие» невозможно, не говоря уже о том, что реализация проектов не позволит принести какие-то инновации от технологии возрастом более двадцати лет.

Проблемы Low-code

Концепция платформ Low-code изначально создавалась для облегчения разработки приложений и реализации проектов силами самих бизнес-пользователей, минимизируя их зависимость от профессиональных разработчиков и ускоряя процессы создания ПО внутри компании. Однако по мере увеличения функциональности и гибкости таких платформ они стали сложнее, особенно в корпоративном сегменте. Вместо упрощения эти платформы теперь претендуют на единое технологическое решение для создания широкого спектра приложений, что, в свою очередь, формирует потребность в узкоспециализированных навыках сотрудников и глубоком понимании специфичных технологий разработки Low-code, которые, в свою очередь, часто оказываются совсем не массовыми. В итоге бизнес сталкивается с дефицитом специалистов, способных эффективно работать с такими платформами, что поднимает ставки на рынке труда. В итоге такие разработчики становятся даже дороже, чем разработчики «1С». Конечно, их требуется меньше, чем при традиционной разработке, однако в реальности разница будет в лучшем случае нивелирована, но, скорее всего, превышена, если учитывать стоимость лицензий и пакета поддержки.

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

Все эти обстоятельства убивают первоначальную идею Low-code — возникает замкнутый круг зависимости от вендора, приводящий к дополнительным издержкам и ограничениям в возможностях самостоятельного развития созданных решений. Усложнение платформ Low-code и высокая стоимость специалистов создают значительные вызовы для бизнеса. В итоге внедрение таких платформ не дает дополнительных выгод бизнесу по сравнению с традиционной разработкой. Бизнес-выгоды можно получить только при внедрении класса систем, решающих конкретную бизнес-задачу по четким требованиям и предусматривающих минимальную кастомизацию, что означает возврат к готовым решениям.

Итого — ни один из вариантов разработки корпоративных бизнес-приложений не дает снижения стоимости и новых бизнес-эффектов, кроме случаев разработки критических систем, где сложность оправдана. Почему так происходит и что делать?

Разбираемся в причинах

Фразы «доступные на рынке технологии не способны решить наших задач» и «уровень импортозамещения составляет от 80 до 100% по разным направлениям» в российском информационном пространстве сегодня поочередно сменяют друг друга. Искать причины упомянутых проблем в технологиях — бессмысленно. Нет ни одной технологии разработки, которая создавалась бы для усложнения жизни разработчикам или бизнеса. В реальности все как раз наоборот — технологии создаются для упрощения и расширения возможностей. Причина кроется в применении этих технологий не по назначению или не применении вовсе по неосведомленности, по привычке делать как раньше или по причине отсутствия управленческой воли. К сожалению, в информационном поле об этом говорят мало.

Технологический суверенитет для «галочки». Отсутствие долгосрочной стратегии достижения технологического суверенитета приводит к тому, что лидеры компаний принимают реактивные решения в условиях постоянных изменений внешней среды и дефицита времени. Бизнес-руководители часто выбирают решения из списка «на слуху», не оценивая последствия их применения в долгосрочной перспективе. Такая тактика уже приводила к зависимости от внешних поставщиков и дефициту внутренних навыков, а без этого невозможно обеспечить долговременную независимость и гибкость. Примером такого подхода могут служить опыт применения практик InnerSource, когда сотрудники компании в режиме открытого сотрудничества развивают программное обеспечение внутри компании. Эта практика способствует улучшению сотрудничества между командами разработки и повышает эффективность. Кроме этого, важно инвестировать в цифровизацию систем управления компаниями и обучение кадров, что снижает риски зависимости от внешних факторов, укрепляет рыночные позиции компании и повышает их способность адаптироваться к изменениям. Компаниям важно сформировать критерии реального технологического суверенитета для себя и связать их с долгосрочными стратегиями.

Гонка за «вау-инновациями». Внедрить современную ERP-систему, а затем повысить эффективность работы с ней с помощью RPA — это яркий пример вау-инноваций. Внедрить корпоративную систему бизнес-аналитики, которая получает исходные данные из электронных таблиц, заполняемых ответственными лицами отделов по регламенту, — тоже пример таких инноваций. Каждый раз с появлением новой технологии руководители, отвечающие за инновации, начинают поиск способа применения новых технологий без оценки реальных бизнес-эффектов и забывая про пресловутый хайп по Gartner. Желание внедрить все самое новое приводит к тому, что на старое уже не хватает бюджетов. При этом инвестиции в модернизацию «скучных» вещей и интеграцию информационных систем внутри компании могут принести реальные бизнес-эффекты и не превратиться вскоре в неподъемный технологический долг. Умение видеть и системно решать «скучные» задачи проигрывает вау-инновациям и выливается в том числе в неэффективную разработку из-за завышенных бизнес-требований.

Профессиональная деформация. Опытные врачи со временем склонны видеть пациентов во всех окружающих их людях, а учителя — учащихся. Продолжительная профессиональная работа в рамках конкретной предметной области часто приводит к деформации восприятия и ограничивает инновации. Однако в динамичном мире ИТ это непозволительная роскошь — не зря представители отрасли говорят, что для сохранения конкурентоспособности разработчикам приходится учиться всю жизнь. В реальности далеко не все предприятия уделяют достаточно внимания развитию навыков своих сотрудников. Бытует мнение, что разработчики должны сами об этом позаботиться и вообще «вся информация есть в Сети». В результате на профессиональных конференциях и тематических мероприятиях очень редко удается встретить разработчиков корпоративных бизнес-приложений — руководство не видит смысла тратить время на профессиональную «прокачку» своих специалистов, более того, посещение мероприятий считается нежелательным, так как ценных сотрудников могут еще и переманить другие работодатели. Ну простите — если вы ограничиваете разработчиков в знакомстве с технологиями эффективной разработки и профессиональным сообществом, каким образом можно построить эффективные процессы создания приложений? Они не смогут появиться из вакуума или только после очень абстрактных бесед о будущем искусственного интеллекта. Профессиональная деформация ограничивает кругозор разработчиков и возможности для повышения эффективности внутренней разработки.

Вера в «серебряные пули». Поиск «серебряной пули» нередко остается драйвером при выборе инженерных решений цифровизации предприятий. Аргументация со стороны бизнеса почти всегда одинаковая — одна платформа, единый профиль компетенций разработки, все модули гарантированно интегрируются друг с другом и один договор поддержки с вендором. Но при этом не учитывается, что про технологии Open Source корпоративного уровня можно сказать то же самое. Так, в мире Java-разработки окончательно победила технология Spring Boot для создания веб-приложений, в которой на все случаи жизни есть спецификация, документация и открытая база знаний. Нет проблем в доступе к разработчикам — их готовят в вузах. Но и Java и Spring Boot нельзя назвать универсальным решением для всех задач, так как технология направлена на повышение удобства бэкенд-разработки в части работы с данными, интеграции приложений и обеспечения безопасности. Для анализа данных и выработки гипотез потребуются фреймворк и библиотеки Python, а для разработки красивых приложений для конечных потребителей потребуется набор фронтенд-технологий, а сама разработка ведется на JavaScript. Почему так? Потому что современный уровень проникновения цифровых технологий в множество устройств, с которыми мы каждый день взаимодействуем, не может обеспечивать простоту. Для каждого проекта есть своя специализация и набор инструментов. Ключ к высокой эффективности и гарантированному получению выгод от использования технологий лежит в подходе к выбору подходящей технологии для конкретной бизнес-задачи. Приоритет Open Source, прагматичное формирование требований и ориентация на возможности команды позволят сделать оптимальный выбор и не стать заложником обстоятельств.

Что делать?

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

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

Первым делом надо классифицировать цифровой продукт/проект, который планируется реализовать. Несмотря на значительное разнообразие типов систем в ИТ-ландшафте предприятия их можно расположить в пространстве координат с осями: степень критичности/сложности и масштабы использования приложения (рис. 1).

Рис. 1. Классификация корпоративных приложений

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

Индустриальная разработка. Численность группы разработки измеряется несколькими десятками человек, что соответствует 3–5 полноценным командам. В каждой команде 5–7 человек.

Профессиональная разработка. Численность команды проекта/продукта составляет один-три разработчика. Каждый разработчик чаще всего способен выполнять весь комплекс работ — создает фронтенд и бэкенд приложения.

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

Пример того, как описанные виды приложений проецируются на профили команд, приведен на рис. 2.

Рис. 2. Профили команд в зависимости от класса разрабатываемого приложения

Функциональные и нефункциональные требования проектируемого приложения вместе со спецификой организации процессов разработки в командах разного размера естественным образом определяют выбор технологии. В идеальных условиях группы разработки выбирают удобные для себя инструменты (рис. 3).

Рис. 3. Органичный выбор технологий и зависимость значений параметров оценки от выбора технологий

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

Скорость разработки. Скорость разработки максимальна для технологий Low-code.

Диапазон применимости. Наибольший диапазон применимости дает комбинация специализированных низкоуровневых технологий. Например, если для клиентского приложения приема заказов требуется дизайн Pixel Perfect (строго по макету), то предопределен выбор узкоспециализированного фронтенд-фреймворка.

Степень контроля. Наибольший уровень контроля над приложением бизнес получает при использовании специализированных технологий Open Source вместе с максимальной гибкостью и доступностью инноваций.

Для удобства восприятия зависимости значений параметров от выбранной технологии разработки они могут отображаться векторами (рис. 3).

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

  1. Продукт какого класса планируется реализовать?
  2. Какая имеется команда и какими навыками располагают ее участники?
  3. Соответствует ли предлагаемая технология профилю задачи и команды?
  4. Позволяет ли предлагаемая технология реализовать проект в требуемые сроки?
  5. Каковы ограничения применения предлагаемой технологии и какова вероятность столкнуться с ними в проекте?
  6. Насколько сложно найти на рынке разработчика для данной технологии?
  7. Соответствует ли применение предлагаемой технологии стратегическим целям компании по контролю над технологическим стеком (технологическому суверенитету)?

Список вопросов выглядит настолько очевидным, что, вероятно, может возникнуть вопрос — если все так просто, то почему так часто случаются неудачи на проектах, а бизнес не получает ожидаемых бизнес-эффектов от применения технологии. Ответ тоже достаточно простой — на всех схемах (рис. 1–3) есть пересечения областей гражданской, профессиональной и промышленной разработки. Это так называемые пограничные зоны неопределенности. Вследствие того, что системы оценок содержат преимущественно качественные параметры, подверженные субъективным эффектам, конкретные проекты очень часто попадают именно в эти «серые» зоны. И единственный действенный способ снижения неопределенности в пограничных зонах — это реализация прототипов на смежных технологиях с определениями метрик результативности.

***

В мире корпоративной разработки выбор инструментов, подходящих для конкретных задач, становится сегодня ключевым фактором обеспечения эффективного соотношения «ценность/затраты». Часто, в стремлении достичь быстрых успехов, компании увлекаются созданием «серебряных пуль» или внедрением прорывных технологий без доказанных бизнес-эффектов. Однако равновесие достигается через прагматичный и взвешенный подход. Предложенный фреймворк для принятия решений по выбору инструментов разработки учитывает характер создаваемого приложения, потенциал команды и стратегические цели в области технологической независимости. Следуя этим рекомендациям, можно минимизировать риски и сократить затраты на этапе реализации, оставаясь в рамках бюджета.

Виктор Фадеев (v.fadeev@haulmont.com) — директор платформы быстрой разработки бизнес-приложений Jmix (Самара).