Как умение программировать помогает аналитику точнее описывать бизнес-процессы и разрабатывать требования к ИС: зачем погружаться в код и архитектуру.
5 причин, почему аналитик должен уметь программировать
Сегодня на рынке труда наблюдается интересная тенденция: граница между бизнес-аналитиком и системным аналитиком стремительно стирается. Хотя профессиональные стандарты РФ разграничивают эти роли, позиционируя бизнес-аналитика как специалиста по организационному развитию, а системного аналитика как исследователя и проектировщика информационных систем. Я часто говорю, что лучшие бизнес-аналитики получаются из экспертов предметной области, а системные аналитики – из бывших разработчиков. Хотя хороший разработчик не бывает бывшим). Поэтому, как бывший разработчик, которому комфортнее в плоскости анализа и проектирования систем, нежели в их непосредственной реализации, считаю, что умение программировать на любом языке и понимание архитектуры информационных систем – необходимая компетенция для системного аналитика и вот почему:
- повышается точность функциональных требований. Например, в сценариях вариантов использования аналитик фиксирует каждый шаг, который должна выполнить проектируемая система, поскольку понимает, что программа работает согласно заданным инструкциям.
- подробно прорабатываются нефункциональные требования, т.к. аналитик знает, какие компоненты программной архитектуры обеспечивают ее надежность, доступность, производительность, быстродействие и защиту данных, имея представление об инструментальных средствах, которыми это реализуется. Сюда же можно отнести требования к мониторингу и журналированию системных событий, которые позволяют наблюдать за состоянием системы во время ее эксплуатации.
- упрощаются задачи трассировки и приоритизации требований, благодаря тому, что аналитик понимает их технические зависимости друг от друга. Например, понимание того, как реализуются процессы регистрации и аутентификации, позволяет аналитику корректно построить UML-диаграммы последовательности взаимодействия сервисов по веб-API с авторизационным JWT-токеном в заголовке HTTP-запросов. Также, благодаря представлению о внутренней реализации, аналитик не пропускает этап проектирования, а трассирует требование «UC-1 Добавить товар в каталог» с актором Менеджер в несколько компонентов решения: функция регистрации пользователя в системе, функция аутентификации и функция добавления нового ресурса. Потом эти компоненты решения трансформируются в задачи на разработку, причем сперва должна быть выполнена задача реализации функции регистрации, а затем – задача поиска зарегистрированного пользователя в базе данных и генерации временного JWT-токена, который будет записываться в заголовок POST-запроса к маршруту /product.
- становится проще понимать оценку трудоемкости, которую выставляют разработчики на реализацию требования. Например, почему простая, на первый взгляд, задача добавления RBAC-политики доступа к данным в уже реализованной системе может занять столько времени. После того, как самостоятельно потратишь пару часов на поиск нужной версии определенной библиотеки, настройку инфраструктуры или отладку ошибок в чужом коде, вопросы «Почему так долго?» задаются все реже.
- наконец, понимая, какими концепциями оперирует разработчик при реализации требований, аналитик точнее моделирует бизнес-процессы, не пропуская на BPMN-диаграмме промежуточные события, генерируемые или изменяемые данные. Также аналитик начинает точнее находить и описывать крайние случаи, т.е. возможные отклонения от happy path, счастливого пути процессного потока, когда пользователь вводит текст вместо цифр, изменяет предполагаемый порядок действий и т.д. Аналогично при моделировании структур и потоков данных: понимание того, как компилятор/интерпретатор будет обрабатывать инструкцию по манипуляции с каким-то объектом, предупредит некорректное определение сущности в ER-диаграмме или класса на UML-схеме.
DDD, ООП и UML для аналитика
Код курса
BUML
Ближайшая дата курса
9 декабря, 2024
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.
Таким образом, системному аналитику для выполнения своих прямых обязанностей, т.е. разработки требований к ИС и их проектирования, действительно необходимо умение программировать на каком-либо языке, а также понимание принципов работы современных программных архитектур. При этом аналитик не становится «трушным» разработчиком из-за отсутствия большого практического опыта и профессионального владения профильными инструментальными средствами, такими как мощные IDE и специализированные фреймворки. Кроме того, структура кода, используемые приемы и программные конструкции у опытного разработчика будут намного чище, лаконичнее и изящнее.
Впрочем, даже если умение аналитика разрабатывать код соответствует этой картинке, он все равно может посмотреть на предмет анализа и проектирования со стороны разработчика, чтобы поставить коллегам из команды реализации более полный и точный артефакт. Также можно самостоятельно проверить какую-либо гипотезу или получить необходимые для анализа и проектирования данные.
В конце концов, с предпринимательской точки зрения аналитик и разработчик – это всего лишь ресурсы для достижения бизнес-цели. И эффективность узкой/широкой специализации этих ресурсов по-разному проявляется в зависимости от масштаба компании. В крупной корпорации работа построена по принципу конвейера, которым проще управлять, разделив участников процессов по выполняемым обязанностям. Так можно точно и точечно контролировать поставляемый результат в любой момент времени, глубоко погружаясь в конкретный профиль. В стартапе или небольшой компании лучше работает кросс-функциональный подход, когда один человек сочетает в себе несколько ролей для достижения конечного результата.
Тем не менее, даже при умении программировать, аналитику стоит трезво оценивать свои способности в разработке кода, которых хватит на проверку гипотезы или прототипирование, но не на промышленный надежный продукт. При этом аналитик и проектировщик ИС должен иметь общее видение продукта с пониманием принципов его работы и реализации. Именно на это направлен мой курс по основам архитектуры и интеграции информационных систем, разработанный специально для аналитиков, чтобы повысить ценность их артефактов для разработчиков.
Основы архитектуры и интеграции информационных систем
Код курса
OAIS
Ближайшая дата курса
20 января, 2025
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.
Узнайте больше про архитектуру и технологии интеграции информационных систем на моих курсах в Школе прикладного бизнес-анализа на базе нашего лицензированного учебного центра обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
