Влияние low-code инструментов на отдел разработки и его роль в компании

В последнее время много говорится о low-code — о том, как он облегчает процесс разработки и как важны становятся для компании citizen-девелоперы и аналитики. Часто маркетинг low-code продуктов произносит высокопарные фразы вроде "разработчики вовсе не нужны". Конечно же, это не так. Внедрение любых IT-продуктов невозможно без IT-департамента, если это не совсем какое-то примитивное решение. Как low-code инструменты влияют на IT-подразделения? Давайте разбираться.

Да, сегодня low-code – это новая реальность. Разработка становится быстрее, решения становятся гибче, их все легче поддерживать. В эти темпы и новые условия нужно влиться и адаптироваться, и поэтому low-code инструменты сегодня становятся неотъемлемой частью инструментария команд R&D (отдела разработки — research and development). По опыту нашей компании, R&D-отделы чаще всего как раз и возглавляют внедрение low-code инструментов. Бывает, что лидер внедрения находится не в отделе разработки, но это все-таки более редкий кейс, который предполагает технически подкованных специалистов.

Как появление инструментов low-code в компании влияет на отдел разработки

Разработчики занимаются архитектурой, а не программированием

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

Разработчики тратят меньше времени на рутинные задачи

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

Разработчики глубже погружаются в бизнес-контекст

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

В команде разработчиков выделяются приближенные к бизнесу специалисты

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

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

Часть разработчиков перестраивается, часть уходит

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

Возрастает роль адаптации и кастомизации

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

Резюме: low-code — это эволюция разработки корпоративного ПО

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

Роль R&D в команде при этом возрастает и становится более бизнес-ориентированной, в работе отдела становится меньше рутины и больше бизнес-аспектов и стратегических задач. При этом возрастают требования к soft skills — требуется больше коммуницировать, адаптироваться к высоким темпам. Параллельно требуется изучение новых технологий, продуктов, особенностей различных вендоров, поэтому внутри компании это изменение может потребовать некоторых усилий.