Pull to refresh

Comments 10

Я тоже когда-to примерно также развлекался, видел очень успешный проект по "роботизации" когда на 20 виртуалках что-то типа селениума кнопки в интерфейсе нажимало и вместо 250 человек осталось 70 на все подразделение.
Так скажу вам, что вся эта "роботизация" не от хорошей жизни, либо архитектура приложения не позволяет нормально сделать, или никто не хочет заниматься. Реализация путем написания кода приложения куда более эффективная и с более широкими возможностями.

Технологии не стоят на месте. Сейчас RPA платформы имеют очень продвинутый инструментарий. Тут и распознавание текста из изображений (OCR), и AI модули уже в коробке, и многое другое. Причём вся разработка полностью в No Code.
Понятно, что всё можно сделать кодом и в некоторых местах даже оптимальнее.
Алгоритм робота это тоже по сути код, просто упакованный в стандартные кубики конструктора.
Одно из основных преимуществ RPA, это когда бизнес-пользователь без навыков программирования спокойно может собрать себе программную приложуху и избавить себя от многих часов рутины.
Особо стоит отметить что наше RPA очень любят безопасники. Один раз проверяется код платформы, а потом десятки роботов на этой платформе в принципе не имеют возможности внедрения вредоносного кода, так как каждый кубик действий зашифрован.
В случае с кастомными программными скриптами шут ногу сломит, что они на самом деле делают.

Было бы интересно посмотреть на статистику применения RPA по направлениям. На каких направлениях они наиболее востребованы? Про распознавание текста вы писали, а есть ли распознавание речи?

Спор о том, нужна ли программная роботизация идет с момента ее появления на рынке. Хотя на самом деле функционал RPA никак не конкурирует с классической автоматизацией. RPA начинает работать там, где заканчивается автоматизация с помощью эффективных приложений с широкими возможностями. Страхи по сокращению персонала тоже понятны. Однако, к примеру, не слышал о сокращении персонала в РЖД, а у них сейчас работает более 2000 программных роботов. Все зависит от стратегии и подходов к процессам роботизации. С другой стороны, было бы бессмысленно отрицать классическую автоматизацию (написание кода приложения), ибо тогда не было бы работы для RPA. :)

Тут главное хорошо понимать – где RPA применимо, где пока не очень. Сам работаю в этой области, не раз сталкивался с примерно таким видением от клиентов возможностей роботизации: «робот пошел туда, не знаю куда, взял то, не знаю что». В общем, часто представление о возможностях робота примерно как из фильма «Интерстеллар» и пр.

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

При этом стоит отметить, что RPA-технологии развиваются на глазах, беря на вооружение современные технологии ИИ (AI). Так что лет так через 10 возможно и увидим реального ТАРСа из вышеупомянутого фильма. Прошу не кидать в меня сразу камнями, прекрасно понимаю отличия программного робота от андроида, но все же взаимосвязь между ними есть, в части блока управления.

А что с зарплатами у RPA разработчиков?

С зарплатами в RPA разработке всё норм) Может быть, конечно, не так всё шоколадно как в классической разработке, но выше среднего.
Но вот совершенно точно, что для обычных бизнес пользователей, овладение этой технологией существенно повышает производительность и ценность сотрудника в глазах работодателя. Шанс нормально так поднять ЗП.

Это вы о citizen developers? Согласен, что это потенциально хороший метод повышения зарплаты. Хотя мне, например, зарплаты не повышали. Руководству было наплевать.

Но, я этим по другой причине интересуюсь. Ближайшие по специализации к RPA -- разработчики UI тестов, т. е. QA Automation Engineers. Им стоит переходить в RPA разработку? Или овчинка выделки не стоит?

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

Раз уж вы отвечаете так уклончиво, придется сделать анализ самому. Идем на HH.ru находим две вакансии RPA разработчика с указанной зарплатой: "170 т. р." и "100 - 200". Смотрим медианные зарплаты для всех QA: https://clingon.pythonanywhere.com/ на данных того же HH. Чтобы получить зарплаты QA Automation надо прибавить 10%-15%, после чего становится очевидно, что даже для middle QA Automation такой переход невыгоден. Больше вопросов не имею.

Sign up to leave a comment.