Comments 8
Если брать базовую задачу по автоматизации Excel файлов, то решение для бизнес-разработчика и технического специалиста будет сильно отличаться.Решение бизнес-разработчика, вероятно, будет хорошо работать с файлами небольшого размера, это даст быстрый profit, но что произойдёт, если файл увеличится с нескольких десятков строк до нескольких тысяч
а у среднестатистического пользователя excel в бизнесе, и так в эфеселе обычно несколько тысяч строк. Как минимум в тех файлах, где интересна какая-то автоматизация.
И что такое "небольшой размер"? файл в 15 мегабайт это много или мало? а я такие встречал еще лет 20 назад.
Опять таки, "быстрый профит" это наверное как раз то, что нужно в бизнесе. Потому что пока будут писать автоматизацию, поезд уйдет и бизнес поменяется.
Если потребуется запускать бота сотни или тысячи раз в месяц?
А, недочитал конец вашей фразы. Каким образом бизнес превратился в запуск бота сотни или тысяч раз в месяц...
Статья ни о чем..
Побуду занудой, но слоган "просто добавь воды" был популярен в 90х и то у напитков. Так что ваш поезд о сферических бизнесах в вакууме не то что ушёл, вы ещё и не на тот маршрут сели.
Обычно в бизнесе проблема не в том, что эксель файл размером в сотни тысяч строк, и не в том, что макрос надо запускать сотни раз на дню, а в том, а в том, что эксельки приходят извне, и раз в какой то период их формат и логика наполнения немножко меняется.
Как правило менять код макроса надо не сильно, но быстро, т.к. данные нужны обработать "уже вчера". А проходить всю процедуру обращения в IT департамент, написания ТЗ и согласования работ просто некогда. Поэтому программирование - вторая грамотность.
Если честно, то автор приводит ряд доводов, которые не выдерживают никакой критики.
Централизованное IT-подразделение необходимо, по большому счету в любой организации, вне зависимости от того, какие технологии используются в ней. И любой, даже гениальный разработчик натворит делов в ситуации, когда все работает как попало на костылях и заплатках. Точнее, до него-то мысль о централизации и приведении всего в порядок дойдет достаточно быстро.
Как правильно заметили в комментариях, Excel на несколько десятков строк никакой автоматизации не требует. А рост объемов данных - вещь неизбежная, если бизнес работает хорошо.
И тут встают два вопроса: правильный подбор решения для автоматизации и правильный подбор тех самых бизнес-разработчиков. Такой разработчик - это не левый человек с улицы, который только в ворде форматирование менять умеет. Таких людей пытаться обучать бизнес-разработке - идея заранее дохлая. Это должен быть человек, который понимает, как система работает, в идеале, выпускник/старшекурсник технического ВУЗа, возможно без реального опыта работы. Идея low-code не в том, чтобы посадить первого встречного, а чтобы снизить порог входа. Условно, помочь джунам, которых огромная куча на рынке, найти свое место, и, возможно, пойти дальше, или остаться на этой технологии, если ему будет интересно
Согласен со всем перечисленным, однако, реклама и подход рекламируется именно такой, что можно посадить любого сотрудника, у которого просто есть желание, что у владельцев бизнеса создаёт неверное представление о технологии
Ну, тут важно отделить зерна от плевел. Чаще всего такой маркетинговый подход направлен именно на привлечение внимания, как один из инструментов лидогенерации. Правда, это уже несколько лет как не работает. Все, кто мог, уже обожглись.
Самое важное - насколько честно и на каком этапе вендор скажет, кто именно нужен в качестве бизнес-разработчиков. И здесь есть две крайности:
1. Можно попытаться дать low-code или no-code реальным разрабам. В этом случае крайне высока вероятность отторжения в дуже "нафига мне эти игрушки, я кодом в сто раз быстрее и понятнее запилю"
2. Взять реально людей с улицы, не проверив их скилл (особенно, если вендор не готов помогать в подборе) и облажаться тогда, когда будет слишком поздно.
Чтобы всего этого избежать нужно пощупать систему самостоятельно или запросить настройку какого-то небольшого кейса. Там будет понятно, что внутри, как это работает, какие навыки нужны.
Мне кажется, что ошибка сразу в начале, прмя в заголовке. "Почему вам не нужны Citizen-Developers". А именно в слове "вам".
Citizen-девелоперы - это по сути сам бизнес. Т.е. я "бизнес" - делаю деньги и нуждаюсь в технической поддержке этого замечательного со всех сторон процесса. Это важная исходная точка. Бизнес первичен, деньги у него. решаея задачу технической поддержки, бизнес может прийти к:
своему "квалифицированному" ИТ
внешнему ИТ
своим ресурсам
Это очень в общем конечно, но надо понимать, что это тоже важно. Бизнес заказчик и он имеет важное право голоса, так как в конечном итоге - ему платить. Конечно в больших организациях есть "законы", которые не позволяют иметь такую свободу, граничащую с анархией, но все ж базовой сути причинно-следственных связей это не отменяет.
Почему бизнес не всегда идет к своему ИТ. Да просто. Оно имеет ограниченный ресурс, он о часто не эффективно, и это еще мягко сказано. А деньги плати. Получается такой себе "монополист" локального масштаба.
Почему бизнес не идет к внешнему подрядчику? Часто это дорого и сложно, да и там нарваться на плохое качество можно. В больших организациях еще всплывет задача интеграций, поддержки этого всего ... короче, тоже не "silver bullet".
Low-code выглядит соблазнительно, так как могу делать сам, когда захочу, что захочу.
-----------
В реальной жизни любой кейс уникален. Где-то может быть "сильный" бизнес, способный реально решать часть своих технических вопросов, где-то вменяемое свое ИТ. А где-то вообще ИТ на аутсорсе. Но нельзя говорить, что один подход лучше другого в общем. В частности да, но надо знать все эти частности.
Почему вам не нужны Citizen-Developers в RPA разработке