Почему я выбираю low-code конструктор без визуализации?

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

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

Начну с первого варианта - схематично, тут начинается самое интересное, конечно: как показать схему, если конструктор, на котором я работаю (Метабот24), не имеет красивой визуализации? Менять конструктор — подумают некоторые, ведь на рынке же полно предложений с простой визуальной сборкой, где сразу все видно, можно менять все местами и легко показать заказчику. Подумала я о таком подходе и даже попробовала другие конструкторы, но оказалось, что это (если коротко) абсолютно не командное решение.

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

В итоге было принято решение — оставаться на Метабот24 и сращивать его с крутой визуальной площадкой. Выбор пал на Miro — любовь с первого взгляда/касания/прокручивания. Плюсов море: безумно гибкий функционал (разные фигуры, шрифты, цветовые маркеры, стикеры, копирование ссылок, вставка картинок) , все интуитивно понятно (даже учитывая, что интерфейс на английском языке) , доступные тарифные планы для всего набора возможностей, невероятно дружелюбная и оперативная поддержка, а главное — это свобода в возможности создать свою уникальную структуру алгоритмов, внедрить базовые обозначения внутри команды и работать онлайн хоть в 20 рук одновременно.

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

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

Как итог: я смогла структурировать весь алгоритм бота в фигурках, дать доступ и легкую возможность к редактированию и контролю тем членам команды, которые не занимаются непосредственно разработкой + наглядно показать заказчикам за что они платят и какой результат получают, а еще это все можно было превратить в файлы для документации.

Второй вариант — текстовый документ. На разных этапах проекта это могут быть разные по структуре документы:

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

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

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

Так, ну вроде рассказала о том, как приспособилась ко всему этому сложному процессу разработки, а на вопрос в теме статьи, возможно, и не ответила…. Исправляюсь! Я выбрала low-code конструктор по причине того, что с ним можно создать свою программу, особо не программируя, используя готовые команды Метабот24, и в целом самостоятельно разработать методы для структурирования командной работы, что очень важно для корпоративных проектов. При этом также можно предлагать огромное количество решений, не зацикливаясь на базовом функционале конструктора, а напрямую привязывая его к любому возможному сервису, с помощью даже элементарного Javascript программирования. Чат-боты не должны быть простыми игрушками для следования моде, они должны быть автономными полезными организмами, способными сосуществовать в мире, где правят кастомные приложения. А организм можно сконструировать только на том инструменте, у которого нет границ возможностей.