Разделяй и властвуй: какую работу передать аналитику, а что оставить разработчику при использовании no- и low-code?

Суть концепции no-code в минимизации сложных действий для настройки информационных систем. Это позволяет передать основную работу с бизнес-процессами аналитику и ключевым бизнес-пользователям не привлекая разработчика. Об этом мы говорили в статье «В чем профит использования no/low-code для компаний? Разбираем на примере».

Итак, вы прочитали ряд статей по теме концепции no/low-code и решили привлечь к настройке бизнес-процессов в вашей компании аналитика. Но сразу возникает ряд вопросов:

• На каком процессе попробовать новый подход no-code?
• Какую работу передать аналитику, а что оставить разработчику?
• Чему нужно научить аналитика, чтобы он справился с no-code-разработкой и инструментом?

Давайте разбираться. Я участвовал в переводе внутренних процессов компании Directum на no-code и буду опираться на наш опыт.
 

Когда лучше No-code, а когда — Low

В Directum RX есть возможность использования как no-code, так и low-code-инструментов. Возникает вопрос: что лучше — быстрое решение или сложный, но глубоко автоматизированный процесс? Ответ зависит от конкретной задачи. Оценивайте каждую конкретную ситуацию и примеряйте инструмент к требованиям бизнеса.

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

Какую работу можно передать аналитику

В командах разработки обычно есть две выделенные роли:

• аналитик – ближе к заказчику и требованиям;
• разработчик – ближе к технологиям.

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

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

Подход no/low-code распределяет нагрузку. Аналитик ближе к бизнесу, более полно представляет конечные цели и требования пользователей. Может понять, что можно отложить, чтобы быстрее донести ценность продукта, а что принципиально важно реализовать. Это исключает «глухие» телефоны и позволяет избежать недоразумений в процессе разработки, повышает качество продукта.

Сложности первой настройки и рекомендации аналитику

Первое применение no-code-инструмента аналитику может показаться сложным. Я аналитик, и первый раз открыв редактор схем бизнес-процессов, у меня была масса вопросов!

1. Как работает инструмент?
2. Как использовать функциональность для правильности работы? Где и что нужно заполнять?
3. Что такое варианты процесса и как их использовать?
4. Как писать выражения? Что такое объект, и как выстроена логика их получения?

И так далее…

Но все эти вопросы преодолимы, ведь важно, что в этом подходе аналитик получает новые возможности: он может сделать готовое ИТ-решение от сбора требований до реализации и предоставления пользователям. А разработчик занимается своим делом – разработкой, которая становится тоже быстрее с low-code.

На основе нашего опыта, мы определили основные рекомендации аналитику для «мягкого» перехода к использованию no-code.

Опыт перевода и поддержки процессов компании

Перейдем к реальным примерам работы аналитика с инструментом no-code.

Настройка форм

В итоге это оптимально по времени разработки, а конечному пользователю будет удобно. Win-win!

Посмотрите, как это делается в коротком скринкасте настройки карточки справочника «Вакансии».

Настройка и оптимизация процесса

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

В примере это план работ и три бизнес-процесса: «Согласование плана работ», «Актуализация плана работ» и «Закрытие плана работ». Чтобы не делать тройную работу аналитик настроил один вариант. Добавил условия, которые определяют необходимые параметры и формируют изменения в отличиях:

• тема задачи /заданий/ уведомлений;
• инструкции к заданиям.

Перед вами скринкаст настройки дополнительного условия, которое было добавлено в процессе опытной эксплуатации процесса:

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

Заключение

Инструменты no/low-code в Directum RX постоянно развиваются. Появляется все больше кейсов, которые можно покрыть настройкой без привлечения разработчиком.

Активное привлечение аналитика к настройке бизнес-процессов, разделение сфер деятельности аналитика и разработчика позволяет ускорить внедрение новых решений.