Post #862

Рискну поднять холиварную тему: где границы ролей BA и SA? На тренинге опять возник этот вопрос. И, кажется, есть немалое число компаний, в которых есть принятое разделение между этими ролями. Принятое, но, однако, недостаточно чёткое. И я, честно говоря, не видел чёткого и признанного определения. У нас есть профессиональные стандарты, в которых весьма конкретно определена разница: BA — специалист по организационным изменениям и оптимизации; SA — специалист по проектированию и координации создания информационных систем. Это чёткие определения, но они мало признаны. Обычная реакция — а, профстандарты! Разве они имеют какое-то отношение к жизни? Вот BABoK! (В этом своде знаний, кстати, системные аналитики упоминаются лишь один раз вскользь. Но и для BA работа с ИТ-системой там описана как частный случай) В реальной жизни я чаще вижу другой подход (видимо, сложившийся естественным путем): BA — тот, кто может поговорить с пользователями и записать их требования(!), проанализровать и описать их деятельность, и сформулировать концепцию ИТ-решения, а иногда и достаточно детальные постановки (BRD), но всё ещё понятные бизнес-заказчикам. А SA в такой конфигурации — эксперт по устройству систем. Он осуществляет распределение требований и задач на системы и их элементы, переводит концептуальные и логические модели в физические, проектирует схемы данных, API и брокеры, описывает технические моменты типа журналирования, метаданных, ретраев и т.п. То есть, смотрит на систему не как на черный ящик, а уже хорошо разбирается в её устройстве. И останавливается только перед непосредственным прораммированием. И тут я у вас хочу спросить -- где, по-вашему, граница ролей и деятельности? До чего в пределе может дойти BA, а что для него уже перебор? Чтобы структурировать обсуждение, предложу рассматривать следующие аспекты: 1. Цели бизнеса / создания системы 2. Модель деятельности (процессы, юзкейсы, сценарии) 3. Модель данных, состояний 4. Пользовательские, функциональные и системные требования 5. Интерфейсы пользователя и API 6. Отчеты, метрики, дэшборды 7. Нефункциональные требования 8. Архитектура системы Насколько далеко в каждом направлении может/должен продвинуться BA, а где ему придется остановиться?