Platformeco. Как делать задачи «вчера»

Platformeco. Как делать задачи «вчера»

Всем привет, я — Елена Южина, старший системный аналитик более 10 лет, видела многое, знаю, как надо, и удивить меня сложно. Сегодня хочу поговорить про No-Code/Low-Code системы и про мой опыт с Platformeco – наша отечественная API-платформа для разработки и управления микросервисами с мониторингами и кучей всяких космических плюшек. Предполагается, что я как системный аналитик смогу все сама, а программисты больше не будут нужны. Так ли это, давайте посмотрим:)

No-Code/Low-Code = no coders? Нет, не верю

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

  • No-Code/Low-Code системы не требуют глубоких знаний программирования
  • Бизнес-аналитики (почти все), системные аналитики (почти наверняка все) и другие специально выделенные (и почти не требующие специального обучения) смогут сами сделать почти все

Какое тут ключевое слово? Конечно, «почти». Я тоже читала статьи, слушала доклады и преисполнилась скепсиса о «почти» наступившем прекрасном будущем. И вдруг на одном проекте это будущее внезапно наступило.

Проект будущего в настоящем

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

Что было: классная идея бизнеса и архитектора блока, маленькая команда из Product Owner, двух backend-разработчиков с ведущим системным аналитиком Таней Тихомировой, которая благодаря своим идеям быстро стала системным архитектором в этой команде.

Мои мысли: Безумие! Это невозможно! В страховом бизнесе продукт от идеи до выхода в продажу разрабатывается в среднем от трех до девяти месяцев, а бывает и до полутора лет. А тут — один день! Идея, достойная этого канала, — надо строить космолет! И я решила, что тоже хочу участвовать, и сумела присоединить и предложить для автоматизации пилота свой проект с таким «макаронным» legacy, что вам и в страшном сне не снилось, честное слово! А ещё с многочисленными эксельничками, перепиской с клиентами в почте, мессенджерах и даже отправкой договоров Почтой России и курьерами. Не самый лучший выбор для пилота, ведь мы привыкли выделять простые MVP. Но какой-то MVP уже у команды в проде был, а системный архитектор требовал усложнения ситуации, чтобы «лучше понимать горизонт событий» и сделать любой продукт за 1 день. Это был вызов.

Самое смешное, что 1 день, как оказалось, позднее, когда все получилось, бизнес в постановке задачи называл условно, надеясь, что сроки не слишком разрастутся. Выпуска продукта за один день на самом деле никто не ждал, не думал, что это вообще возможно. Идеально было бы собирать продукт дней за пять, но и за десять было круто. Главное, не месяцы, как оно было. Но мы тогда не знали этого, и стремились сделать этот самый немыслимый для всех time-to-market в 1 день.

Реальный CJM длиною в 10 метров

Про CJM сейчас системного аналитика на каждом собеседовании спросят: что это? Есть ли опыт? Представьте: огромная аудитория, в ней человек 40, начиная с бухгалтерии и юристов, заканчивая курьерами котрагентов, и даже клиент, и огромная стена, обклеенная листами ватмана и стикерами.

CJM или Customer Journey Map — карта путешествий клиента — представляет собой комплексную работу по исследованию взаимодействия клиента с компанией от момента осознания потребности и до повторных коммуникаций.

Могу с уверенностью заявить, опыт есть! 24 листа и несчетное количество разноцветных стикеров потребовались для того, чтобы описать частично автоматизированный процесс, который потом был полностью автоматизирован на этом самом проекте будущего.

Архитектура и 1 день

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

И вот в один день заговорили о Platformeco как об одной из возможных составляющих процесса.

Platformeco

Platformeco — собственная разработка российской компании. Это API-платформа для разработки и управления микросервисами с функциями мониторинга, трейсинга, развертывания в облаке, масштабирования, алертинга, кастомизации и интеграции плагинов. Мощно, красиво и позиционировалось как просто и без разработчиков.

Бунт на корабле: слабоумие или отвага?

Собрались все системные и бизнес-аналитики нашего и смежных блоков, системные архитекторы и даже некоторые программисты посмотреть, что же это за «зверь» такой, Platformeco. И что мы увидели?

Конечно, разработка очень классная, ребята постарались. Примечательно, что UI/UX тут уделено серьезное внимание: не только возможно реализовать задачи, но еще и приятно в ней работать, если честно.

Но как это без разработчиков? Да где вы видели аналитиков, которые сами смогут спроектировать контракт и разработать в этой системе сервис?

В итоге, остались самые бесстрашные: я, да Таня. На том и порешили: пилотируем этот продукт, страшно, сложно, но это и интересно.

Как я работала в Platformeco: первые дефиниции и первый шок

Сервис (дефиниция) в Platformeco собирается как в конструкторе из кубиков. Ах, каких кубиков там только нет! Хочешь JSON на вход принимать? XML парсить? Хочешь с очередями работать? Я чувствовала себя, как ребенок в конфетной лавке! И собрала свой первый процесс за день: он был не слишком сложный, но все-таки подразумевал подключение к нескольким системам и базам данных и даже некоторые несложные преобразования. Как же было приятно увидеть в итоге, что да, оно работает!

А дальше сборка, и качу свой первый сервис на тестовый стенд. Чувствуешь себя почти программистом.«А вдруг они, правда, не нужны?»

Дальше я испытала почти шок, если честно. Помните, сколько времени уходит на обсуждение, какие мониторинги, алертинги нам нужны? А сколько времени от разговоров до реального результата? И сколько времени ты гадаешь: что не так у команды, которая твой сервис пытается «дёрнуть»? И что Platformeco? Всё это поднялось сразу вместе с сервисом на тесте.

И я сразу видела, что подключившаяся к сервису команда делает не так, и комментарии «мы все делаем, как у вас в документации написано, но почему-то не работает, посмотрите почему» не выбивает всю команду из рабочего процесса. Мне потребовалось 2 минуты, чтобы сказать, что не так и что надо сделать.

С отвисшей челюстью я смотрела на будущее уже здесь и сейчас.

Игра в бисер и результаты

Я считаю, что системный аналитик — говорящая профессия: ты обязан разобраться в любой системе, поэтому страх других системных аналитиков пробовать работать в Platformeco мне было странно наблюдать. Наоборот, всё новое и самое сложное должно вызывать наибольший интерес. Так что мы, как первопроходцы каждый раз. Конечно, тут система не простая, нужно понимание процессов, в том числе CI/CD. Но если ты смелый, передовой и продвинутый, то точно разберёшься, а разбираться стоит!

Вот почему:

  • Platformeco позволила самостоятельно построить API-оркестраторы для решения бизнес-задач заказчика
  • Сократить время на постановку задач и их объяснение разработчику, поскольку сбором информации от участников процесса и созданием так называемых дефиниций самостоятельно занимался аналитик
  • Сразу предоставлять командам потребителям моего сервиса документацию в формате Swagger, потому что (браво, разработчикам!) она тоже Platformeco генерируется автоматически
  • Видеть все логи, мониторинги и настраивать аллерты в моменте –– сократить время, требующееся для выявления проблемы

В этом проекте, в котором нам с Таней удалось, поработать совместно, Platformeco во многом была интересной составляющей архитектуры. Было здорово собирать новые «ручки» уже в процессе сбора требований от бизнеса. Какой там почти?! Чувствуешь себя аналитиком уровня бог, когда говоришь: «Коллеги, ок, зафиксировались, а теперь у нас есть десять минут от встречи, давайте проверим, как процесс УЖЕ работает на тесте». Надо было видеть лица бизнеса! Это просто невозможно передать, потому что после их первого шока ты, да, реально получаешь в их глазах god-level грейд. И, конечно, я отмечала в конце таких встреч: «Коллеги, вы знайте, так круто еще и потому, что у нас разработчики умеют микросервисы писать. Они тоже используются, без иллюзий, пожалуйста. Но, да, это круто, вместо спринта сделать сервис за час во время разговора с вами».

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

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

Розовые мечты бизнеса vs реальность

Я считаю, что разработчики Platformeco максимально честно позиционируют возможности продукта и требуемые навыки для работы с этим инструментом.

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

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

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

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

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

Конечно же есть и минусы, работы в подобных системах: придется работать над своими пробелами в понимании процесса разработки в целом, разобраться в паттернах проектирования и других тонкостях. Мне, к примеру, пришлось немного в JavaScript разобраться, потому что в версии Platformeco, с которой довелось поработать, что-то приходилось кодить самой. А еще надо постоянно думать, как сделать результат лучше. Да, думать, придётся, но такая уж у нас работа.

Я пока не работала с этим продуктом и знаю о нем только понаслышке (Таня рассказала) и по тому, что увидела на официальном сайте. Честно сказать, я довольно скептически отношусь к Low-Code технологиям (дизайн-система — один из примеров). На суровой практике всё разбивается о быт: например, выясняется, что даже небольшие UX-фичи нужно дорабатывать долго и дорого. Причем часто более объёмная часть — это бэк, а не фронт и не дизайн. И в такой ситуации часто приходится под этот самый бэк подстраиваться, потому что его уже спроектировали именно так, а на изменение потребуется уйма времени и не в этом году. Кстати, именно в таких условиях я сейчас и работаю :) И если в Platformeco действительно можно за встречу накидать бэк и творить систему на лету, это сократит массу ситуаций, когда система ограничивает UX.

Я считаю, не для всякой enterprise-разработки применение No-Code/Low-Code возможно. Там, где цена ошибки, человеческая жизнь, я бы не стала внедрять подобные системы. Только, как правильно пишет Лена, для проверки гипотезы, и то не на бою. Например, в разработке хирургических роботов или авиастроении. Хотя, с другой стороны, сейчас панели управления космическими ракетами уже написаны с использованием JavaScript, так что время покажет, как скоро мой комментарий устареет.

Наш Telegram-канал Проектируем космолеты

1717
3 комментария

Я, будучи разработчиком, этого восторга не разделяю и удивляюсь как автору удалось так легко и просто реализовать проект в Platformeco. Ведь там куча неочевидных нюансов и проблем, начиная от нестрогой типизации и неявного преобразования типов при работе с БД , заканчивая багами в коннекторах. Я поработал немного с Platformeco, реализовал два процесса в ней, но честно говоря, лучше б мне дали это закодить самому, получилось бы раз в пять быстрее, проще и приятнее.

1
Ответить

Как то скоренько от «как делать вчера» перешли к рекламе

Ответить

Комментарий недоступен

Ответить