Преимущества и недостатки разработки бизнес-приложений с помощью low-code
В этой статье я буду сравнивать в первую очередь технологии low-code BPMS с разработкой бизнес-приложений с нуля при помощи армии программистов без использования low-code или других современных инструментов. Хотя многое из упомянутого также относится и к кейсам — например, low-code BPMS против классических систем автоматизации вроде тех же bpms.
Преимущество № 1. Наглядный ход разработки
Мы не создаем решение месяцами, а всегда имеем наглядный понятный результат в виде набора эволюционирующих прототипов. Пока не получится итоговый результат, мы работаем с некоторым визуальным решением — его можно посмотреть, протестировать, понять, что было придумано удачно, а что нет, отследить ошибки и тому подобное. Это позволяет создавать более удобные и красивые решения, на ранних этапах исправить больше ошибок, а не оставлять все на последний день с риском неприятного результата. Чем раньше мы начинаем показывать решения бизнес-заказчикам, тем более удачные решения обеспечиваем себе в конце проекта.
Возможный недостаток: желание уйти в перфекционизм
Команда разрастается, и каждый из участников начинает вбрасывать идеи. Это может затянуться до бесконечности, и это проблема Agile-проектов — вместо конкретных дел все начинают заниматься бесконечным улучшательством, сбором идей, обсуждением. Время идет, проект двигается то влево, то вправо, то вбок, то в сторону и в итоге не продвигается, несмотря на бурную деятельность.
Решение
Нужен руководитель проекта, который будет заниматься управлением требованиями и отслеживать прогресс проекта. Да, нужна какая-то Agile-команда, но если мы ведем проект по гибким методологиям, то за нас все давно придумали, практик много — нужен некто, кто будет управлять ходом проекта и не допускать расшатывания.
Преимущество № 2. Вовлеченность всей команды проекта
При классической разработке внутри проекта преимущественно находятся программисты. Сейчас же все заказчики, потребители, кураторы составляют расширенную команду и видят прогресс проекта. Получается, что вместе работают и бизнес, и технические специалисты — это дает синергию и позволяет создавать более интересные решения, да и количество рук увеличивается. Это однозначно плюс, потому что решение создается не где-то там с краю, отдельной командой, а всеми причастными к необходимому результату.
Возможный недостаток: несовершенный результат
Вовлечение еще вчера неквалифицированных специалистов часто приводит к тому, что создающиеся решения не обладают должной технической элегантностью и могут быть объективно кривоваты — спроектированы не лучшим образом или с использованием неудачных паттернов.
Решение
Внедрение корпоративного продукта невозможно отдать на откуп с посылом «делайте, что хотите». Нужна понятная команда проекта и архитектор, который будет определять правила и механики разработки, методику принятия (или отклонения) решений и следить за тем, чтобы команды работали синхронизировано и принимали правильные решения, не изобретая велосипед.
Преимущество № 3. Разработка ведется гораздо быстрее
Поскольку мы ведем разработку при помощи визуальных конструкторов, то многое можно собрать прямо из готовых кубиков вместо того, чтобы месяцами писать код. Поэтому получаем результаты гораздо быстрее.
Возможный недостаток: некоторый хаос
Может начаться изобретение велосипеда, когда множество команд одновременно выпускают похожие друг на друга продукты, но не отслеживают, что разрабатывает сосед. И конечный пользователь не понимает, почему в одном месте он делает что-то одним образом, а в соседнем приложении очень похожую вещь почему-то реализовали иначе.
Решение
Нужна политика управления версиями, управления доработками, очередностью разработки и то, что называется CI/CD-политикой, то есть continuous integration, continuous delivery. Это касается непрерывной поставки результатов: в предыдущих двух пунктах я говорил, что нужен архитектор, управляющий технической грамотностью решений, и руководитель проекта, отвечающий за требования и общий прогресс проекта. Здесь же нужен администратор, который будет определять прогресс продукта на уровне релизов. Это может быть тот же человек, что и на предыдущем шаге, — руководитель проекта, владелец продукта.
Преимущество № 4. Простота проектирования решений
У пользователей не возникает ступора, как спроектировать решение по закупкам. В целом понятно, как выглядят согласования в системе, потому что есть некоторые паттерны и интерфейсы, уже предоставленные в продукте и отчасти стандартизированные. И если аналитику не хватает какого-то готового блока, то программисты могут разработать его для конечного потребителя. Это как черная коробка — бери и пользуйся, что удобно и позволяет сэкономить не столько на скорости разработки, сколько на сложности проектирования. То есть проектирование решений становится проще благодаря использованию системы конструкторов.
Возможный недостаток: ограничения на кастомизацию
Любой конструктор накладывает ограничения на реализацию и на кастомизацию. Продукт всегда про преимущества и недостатки, про те рельсы, по которым пользователь пойдет. И если конечному потребителю не нравятся паттерны, которые предлагает продукт, ему хочется другой интерфейс, другое расположение кнопок, другую цветовую схему — это предполагает кастомизацию, дополнительную настройку. Иногда стоимость кастомизации может быть даже выше, чем разработка самого решения с нуля. Ломая принципы, заложенные в продукт, мы попадаем на издержки по кастомизации и доработке — и зачастую это издержки не разовые, а постоянные, так как при любых выпусках новой версии вендорской платформы мы будем обречены что-то дорабатывать.
Решение
Главное — изучать особенности продукта и не пытаться всегда достичь полного соответствия своим фантазиям. Нужно здраво мыслить и оценивать пожелания, соотносить их с возможностями и практиками продукта. Реализация таких фантазий может быть дорогой и приводить к ненужным кастомизациям, замедлениям работы команды, ошибкам, переделкам. Это одна из основных причин неудачных проектов — когда берут конкретный продукт и пытаются его внедрять, но при этом все переделать и сделать ближе к архитектуре того продукта, с которым привычнее работать.
Преимущество № 5. Квалифицированные специалисты могут не тратить время на стандартные задачи
Речь о ненужных технических задачах, которые предполагают повторяемость, — например, написание экранных форм, примитивной бизнес-логики, бизнес-правил. Настоящему программисту такое не особо интересно делать, потому что это скучная работа, но в случае классической разработки программист делать ее не может, потому что нужны технические навыки. В случае low-code этим могут заняться аналитики, разгрузив программистов для более интересных задач.
Возможный недостаток: несерьезное отношение программистов к low-code
Часто программистам кажется, что low-code — это несерьезная игрушка для аналитиков, а настоящие продукты создаются только классическими подходами. Аналитики сделали что-то без нас — это же странно, да? Столь негативное отношение к продукту может приводить к бойкотам и к тому, что техническая команда несколько отстраняется от использования low-code.
Решение
При внедрении продукта нужно бороться с внутренними настроениями и объяснять, где сами разработчики получат пользу от low-code. Акцентировать внимание на том, что многие вещи программисты могут самостоятельно гораздо быстрее реализовать в low-code-системе и при этом спасти себя от скучных рутинных задач, переложив работу на аналитиков.
Преимущество № 6. Огромная часть продукта уже разработана
Часто low-code платформы — это не просто платформенное решение в вакууме. В нем могут быть реализованы системы документооборота — например, как в ELMA. CRM-системы, управление проектами, коммуникации, омниканальные системы и даже написание базовой бизнес-логики, связанной с переназначением, определением ответственных и тому подобное — уже реализованы в продукте. Это значительно экономит время и минимизирует количество ошибок, которые обязательно возникли бы при реализации этого с нуля.
Возможный недостаток: вендор-лок
При использовании low-code мы связываем свои бизнес-решения с выбранной нами платформой. Есть некоторые риски для бизнеса в том, что мы не можем залезть как потребитель в ядро платформы. Если нам что-то не нравится, мы можем либо рассчитывать, что вендор это разработает, либо не рассчитывать вообще, если речь идет о крайне экзотической «хотелке». Так или иначе использование любой технологии приводит к тому, что мы к ней привязываемся.
Решение
Решения тут нет, это некоторое необходимое зло. Сегодня бессмысленно не использовать совершенно никаких продуктов, потому что это может замедлить развитие бизнеса. Надо минимизировать риски и, самое главное, выбирать надежного поставщика low-code-платформы. Выбирать те компании, которые уже какое-то время существуют на рынке и завтра не пропадут, у которых есть клиенты, обязательства и планы по развитию, которые хорошо видны в информационном поле. Потому что не факт, что появившийся полгода назад продукт никуда через год не денется, какой бы он классный ни был — например, не хватило финансирования, исчез энтузиазм тех, кто начал бизнес, или что угодно еще. Если продукт больше пяти или тем более 10 лет на рынке — естественно, это более надежный партнер для развития бизнеса.
Резюме
Как и у любого другого решения, у low-code есть преимущества и недостатки. Главные недостатки low-code реализуются в двух случаях:
-
когда нас в платформе многое не устраивает и мы хотим это переделать и кастомизировать;
-
когда проект крайне нестандартный и предполагает много разработки в принципе.
В этих случаях меркнут преимущества, которые дает low-code, и мы упираемся в его недостатки. Такие проекты лучше делать с нуля с использованием классических методик разработки. Это единственный неудачный кейс, но его стоит иметь в виду.
Во всех прочих проектах low-code — это преимущество, потому что мы можем быстрее создавать более качественные решения за счет того, что итерационно видим, дорабатываем, улучшаем продукт. Это дешевле во владении.
Преимуществ больше, за технологией будущее, к тому же с недостатками можно либо бороться, либо как-то минимизировать их импакт на проект.
Опубликовано 23.05.2023
