Аналитик vs разработчик: кого предпочтет бизнес

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

Что не так во взаимодействии аналитика и разработчика при классической разработке?

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

И здесь аналитик становился «заложником» программиста: нужно было ждать, когда код будет написан, протестирован и выдан. Даже если это небольшие изменения — добавить поле, изменить условие перехода по этапам и т.д.

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

И это не единственная проблема. Например, представьте, аналитик рисует схему процесса в некой программе для моделирования. А реализовывать ее нужно в совершенно другом инструменте. Разрыв между проектированием процесса и реализацией снижает эффект участия аналитика. Конечная схема может сильно отличаться от задуманной и потерять смысл.

Что изменяется с применением no/low-code? Можно ли говорить, что аналитику дали большую свободу?

Благодаря появлению ИС с no-code-слоем, аналитик может собирать бизнес-процессы из готовых блоков прямо в системе и сразу же тестировать их без дополнительных переносов. Последовательность процесса и формы для заполнения можно сразу показать заказчику или конечному пользователю как MVP и согласовать с ним.

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

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

В чём основной эффект изменения ролей аналитика и разработчика?

Главный эффект в том, что существенно сокращаются сроки и трудоёмкость адаптации, куда входит и настройка, и разработка. Например, благодаря множеству блоков, встроенных в no-code-слой Directum RX, мы можем собирать готовые процессы сразу при внедрении. Это делается непосредственно аналитиками, и в результате получается гораздо быстрее, чем, допустим, дополнительная разработка по ТЗ заказчика. Исключаются глухие телефоны между аналитиками и разработчиками. Меньше времени тратится на взаимодействие, передачу информации от одних другим, обмен разработками. То есть по сути сам сделал, сам проверил, сам отправил дальше в продуктив.

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

Каждый отвечает за свое направление. То есть внятное разделение обязанностей, возможность не распыляться, прокачиваться в определенном профессиональном векторе — это тоже важно для людей.

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

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

Насколько бизнес готов к такому разделению ролей? Доверяют ли компании настройку процессов аналитикам?

Далеко не каждая компания может позволить себе иметь в штате отдельного специалиста-аналитика.

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

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

Встроенные инструменты no-code дают возможность любому заинтересованному сотруднику подключаться к оптимизации процессов, т.к. не требуют каких-либо знаний в программировании. И даже в случае использования инструментов Directum RX не нужно глубокое погружение в методику BPMN, так как моделирование процесса значительно упрощено. Настройка интуитивно понятна.

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

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

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

Может ли разделение ролей аналитик-разработчик решить проблему кадрового голода на рынке?

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

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

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

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

Станут ли в будущем все специалисты в итоге «разработчиками» — кто-то с кодом, кто-то без кода?

Нет конечно. В англоязычных публикациях применяют термин «гражданский разработчик», в России он меньше используется. Мы обычно говорим аналитик или «ведущий пользователь».

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

Но специалисты, которые понимают финансовый, производственный процесс, потребности рынка и клиентов и т.д. никуда не денутся. Без них не будет бизнеса. При этом no-code дает им возможность роста в сторону диджитал, оставаясь профессионалом в своем базовом направлении.

 

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

Сергей Скурыгин
руководитель направления разработки Directum

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

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