Проблемы в low-code-разработке и как их решать

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

Особенности low-code-разработки

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

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

Если сравнивать low-code-разработку с той, которая делается без использования кода совсем (no-code), то можно отметить, что no-code ориентирован больше на непрофессиональных разработчиков, полностью ограждая их от программирования. При этом там нет возможности расширять или пополнять палитру инструментов, а также реализовывать некоторые функции, в то время как в low-code основу собирают с помощью конструктора, а для выполнения более узких задач используют полноценное программирование. Тем не менее такой подход позволяет получить результат быстрее и дешевле, чем классическая разработка с нуля.

Основные проблемы, которые поджидают в процессе low-code-разработки

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

Проблема № 1. Неправильные ожидания заказчика

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

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

Проблема № 2. Неготовность к компромиссам и перфекционизм

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

Решение.Важно найти баланс между тем, чтобы облегчить процесс создания продукта и возможностями, которые он предоставляет компании. Часто разумнее пойти на компромисс, чтобы получить весь эффект от использования low-code, в том числе временной и финансовый, а не превращать его в обычное программирование ради, например, желаемого расположения кнопок.

Проблема № 3. Недостаток знания low-code-платформы и ее архитектуры

Когда компания впервые подходит к внедрению low-code-системы, ее знания о том, как она устроена, стремятся к нулю. Отсутствие опыта других внедрений может привести к использованию неверных инструментов, так как система предоставляет множество вариантов решения одной задачи.

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

Проблема № 4. Избыточное использование кода и хаков

Попытка настроить систему не так, как она задумывалась, приводит к использованию недокументированных возможностей (хаков). Безусловно, совсем обойтись без их применения в крупных проектах сложно, однако избыточное применение кода может привести к неприятностям в будущем.

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

Проблема № 5. Недостаточное вовлечение заказчиков и бизнес-пользователей

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

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

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

Проблема № 6. Затягивание начала разработки

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

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

Проблема № 7. Отсутствие контроля качества, стандартов разработки и регламентов доставки

Процесс разработки и создания проектов — регулярная деятельность для low-code-команды. Это становится штатным инструментом постоянного развития и из проекта внедрения платформы превращается в процесс постоянной автоматизации. Следовательно, необходимо стандартизировать и регламентировать эту деятельность 

Решение.При создании стандартов качества обращайте внимание на некий стиль при разработке low-code-решений — например, как пишется код, как располагаются блоки бизнес-процессов, как происходит разделение на компоненты решения. Чтобы все участники проекта, включая новых сотрудников, могли легко понять, что уже было сделано, необходимо организовать доступ к документации. Это особенно важно, когда в команде происходят изменения и перестановки. Когда все разработчики придерживаются единого стиля, работу легче читать и в дальнейшем переделывать, если это необходимо. Так задачи выполняются быстрее. Стандартизация нужна и процессу доставки. Если он не отлажен, то могут возникать накладки: часть перенесли, а часть осталась или перенесли, то что еще не протестировано. Это приведет к проблемам у бизнес-пользователей.

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

Проблема № 8. Расхождение между регламентами и реальной работой

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

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

Проблема № 9. Неверные приоритеты

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

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

При этом не стоит сразу же браться и за основной процесс, особенно если у команды еще совсем нет опыта. На первом этапе стоит рассмотреть менее важные контуры, чтобы набраться начального опыта. Однако нужно не застревать на этом этапе надолго, а переходить к важным для бизнеса задачам. Поиск баланса — одна из главных задач в процессе разработки в целом и low-code-разработке в частности.

Источник: IT-World