13 причин, по которым ИТ-директора беспокоятся о гражданских разработчиках, создающих корпоративные приложения

13 причин, по которым ИТ-директора беспокоятся о гражданских разработчиках, создающих корпоративные приложения

Источник · Перевод автора

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

Одно из средств устранения этого узкого места, которое в последнее время привлекло к себе много внимания, – это переложение усилий по разработке приложений с ИТ на бизнес-пользователей. Эти так называемые «гражданские разработчики» создают приложения для себя или других, используя инструменты, которые активно не запрещаются ИТ-подразделениями или бизнес-подразделениями. Хотя это может показаться отличной идеей, помните о проблемах, вызванных теневым ИТ, когда люди, не являющиеся ИТ-специалистами, приносили в свои организации устройства, программное обеспечение и услуги, которые не принадлежали ИТ-специалистам или находились под их контролем. Shadow IT нанесла серьезный ущерб организациям, когда сотрудники установили MS Access на свои рабочие столы и создали свои собственные базы данных.

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

Две популярные технологии, которые гражданские разработчики используют для создания новых приложений, – это роботизированная автоматизация процессов, RPA, и платформы приложений с низким кодом, LCAP. RPA помогает автоматизировать задачи, обычно с использованием технологии записи и воспроизведения на основе пользовательского интерфейса, устраняя необходимость интеграции систем в рабочий процесс. Пользовательский интерфейс – это уровень интеграции, поэтому пользователи могут обойти системные подключения, требующие ИТ. LCAP позволяют бизнес-технологам создавать приложения за пределами ИТ-контроля. Оба инструмента позволяют гражданским разработчикам создавать новые приложения или нанимать сторонние фирмы, чтобы избежать задержек и задержек с поставками ИТ.

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

Пока ваши гражданские разработчики не взаимодействуют с ИТ-системами и не производят данные, требующие корпоративной безопасности и управления, вашему ИТ-директору не о чем беспокоиться. Но если это изменится, все очень быстро усложняется.

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

  1. Ученичество потеряно

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

  1. Развертывание платформ и управление ими ничем не отличается

Как только рассматриваемое приложение получает доступ к критически важным или конфиденциальным данным, ИТ-отдел должен распространить свои процессы управления изменениями на эту платформу. Это означает среды разработки, среды тестирования, среды интеграции, среды тестирования производительности и другие. Мы берем на себя ответственность ИТ-специалистов за целостность системы и данных; таким образом, эти шаги необходимы. По сути, ваши гражданские разработчики будут создавать приложения в соответствии с теми же процессами, которым следует ИТ-отдел.

Таким образом, эти приложения подвержены тем же задержкам в разработке, что и ваши ИТ-приложения. Большинство задержек происходит из-за среды и доступности тестовых данных и управления ими. Если этот аспект развития будет таким же, развитие граждан не будет быстрее, чем развитие традиционных ИТ.

  1. Разделение обязанностей

В разработке программного обеспечения существует четкое разделение обязанностей. Строгое управление не позволяет разработчикам проводить собственные проверки качества, поэтому ошибки выявляются до начала производства (будем надеяться!). После нескольких неожиданных проблем «sev 1» процесс гражданской разработки будет вынужден отражать существующие практики ИТ-разработки, чтобы гарантировать, что требования будут правильно зафиксированы, код будет протестирован независимыми специалистами по обеспечению качества, а изменения будут внедряться осторожно.

  1. Экономика

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

  1. Обеспечение безопасности

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

  1. Контроль и управление

Управление ИТ сочетает в себе правила, положения и политики, которые определяют, контролируют и обеспечивают эффективную работу ИТ-отдела. Демократизация технологий и предоставление возможности сотрудникам, не связанным с ИТ, создавать приложения, могут привести к появлению данных и процессов, которые ослабят управление и централизованную отчетность по рентабельности инвестиций. Это особенно актуально, если данные, созданные в приложении, созданном гражданами, недоступны для корпоративных отчетов и информационных панелей. Отсутствие надлежащего управления проектами гражданского развития либо резко ограничивает их объем, либо представляет собой опасную деятельность, которая должна находиться под той же структурой контроля, что и другие инициативы в области ИТ.

  1. Граждане не хотят этого делать

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

  1. Ориентация на задачу – противоположность общей картины

Как правило, гражданские разработчики автоматизируют лишь частично шаги, которые они предпринимают в процессе, а не конечный результат бизнес-процесса.

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

  1. Усложняет трансформацию

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

Жесткое программирование того, как задачи выполняются сегодня, часто не приближает вас к трансформированному результату. Как нам сократить шесть шагов до 2 или даже до 1? Это не цель большинства платформ с низким кодом, и это не цель, которую ставят перед собой гражданские разработчики.

  1. Сбои в производстве сложно отсортировать

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

  1. Большинство инструментов с низким кодом переоценивают возможности

Многие LCAP заявляют, что разработка приложений с использованием их платформ проста и соответствует модели гражданского разработчика, но «низкий код» не означает «без кода». Когда дело доходит до интеграции с другими системами, они следуют так называемой модели «вставьте сюда свой код». Один разработчик LCAP заявил в Gartner Peer Insights: «Процессы, требующие бизнес-логики, выходящей за рамки того, что уже построено и доступно в готовом виде, требуют профессиональных разработчиков. Я лично работал над разработкой более 50 приложений и не смог бы разработать ни одно без поддержки профессиональных разработчиков ».

Чтобы преодолеть проблему нехватки навыков, требуется в среднем 101 день обучения, наставничества или повышения квалификации гражданских разработчиков. Просто перейдите на свою любимую доску объявлений о вакансиях и ознакомьтесь с требованиями к вакансиям с низким / без кода платформой. Вы увидите, что им требуется пять лет опыта в Java и три года опыта в SQL! В чем разница между этими публикациями и типичными публикациями ИТ-разработчиков?

  1. У компаний уже слишком много приложений

Это действительно меня заводит. Здесь мы, как отрасль, очень стараемся сделать создание новых веб-приложений быстрее и быстрее. Но какой бизнес-лидер когда-либо сказал: «Моей команде нужно больше приложений, с которыми нужно иметь дело!»

Компании уже перегружены растущим списком приложений на рабочем месте. В среднем на предприятии используется 397 приложений. Эти приложения имеют отдельные пользовательские интерфейсы и терминологию, функциональные возможности, стоимость лицензий и / или группу разработчиков, у которой есть накопившиеся изменения и запросы на поддержку. Среднестатистический сотрудник, пытающийся управлять процессами с помощью всех этих приложений, переключается между 35 критически важными приложениями более 1100 раз в день. Больше приложений увеличивает расходы и разочаровывает сотрудников.

  1. Продуктивный «гражданин-девелопер» – это «девелопер»

Обратите внимание, сколько из вышеперечисленных проблем сводится к тому, что «гражданские разработчики должны делать то же самое, что уже делают ИТ»? Если они делают то же самое, что и разработчик в ИТ, они тоже разработчики. К тому времени, когда вы добьетесь продуктивного и безопасного участия гражданского разработчика, вы можете отказаться от слова «гражданин».