Видишь себя больше системным или бизнес-аналитиком

System Analyst vs Business Analyst

Краткий ответ: Я себя вижу System Analyst, но с глубоким пониманием бизнеса. Это комбинация, которая, по моему мнению, создаёт наибольшую ценность.

Моё понимание разницы

System Analyst

Фокус: На технической архитектуре и интеграции систем.

Основные задачи:

• Проектирование архитектуры системы
• Анализ технических ограничений
• Интеграция разных компонентов/систем
• Определение нетехнических требований (NFR) — performance, scalability, security
• Работа с development team на техническом уровне

Инструменты/Навыки:

• UML диаграммы, BPMN, DFD
• Архитектурные паттерны (микросервисы, CQRS, Event-Driven)
• Знание технологий (DB, кешиование, очереди, облако)
• API дизайн

Вопросы, на которые отвечает:

• Как эти системы будут взаимодействовать?
• Какая архитектура выдержит миллион пользователей?
• Как обеспечить fault tolerance и resilience?
• Какие технологии выбрать для этой задачи?

Business Analyst

Фокус: На бизнес-процессах и требованиях.

Основные задачи:

• Понимание бизнес-целей и KPI
• Анализ текущих процессов (as-is)
• Определение желаемых процессов (to-be)
• Сбор требований от stakeholders
• ROI анализ и justification проектов

Инструменты/Навыки:

• BPMN (процесс-моделирование)
• User stories и acceptance criteria
• Метрики бизнеса (KPI, ROI, cost/benefit)
• Коммуникация с business stakeholders

Вопросы, на которые отвечает:

• Почему нам нужна эта система?
• Какой ожидается ROI?
• Какие процессы изменятся?
• Какие требования должны быть реализованы?

Почему я видю себя System Analyst

1. Мой основной интерес — технология

Меня больше привлекает "как это работает", чем "какой это даст доход". Я люблю:

• Проектировать масштабируемые архитектуры
• Решать сложные технические проблемы
• Выбирать оптимальные инструменты
• Работать с development team

Примеры из моего опыта:

• Выбор между монолитом и микросервисами ← System Analyst вопрос
• Нужна ли нам Kafka или хватит RabbitMQ? ← System Analyst вопрос
• Как спроектировать базу данных под 100K RPS? ← System Analyst вопрос

2. Мой background — разработка

Я начинал как разработчик Java, потом Tech Lead, потом System Analyst. Этот путь:

• ✅ Дал мне глубокое понимание технических реалий
• ✅ Позволяет мне говорить с разработчиками на одном языке
• ✅ Помогает писать реально implementable требования

Это преимущество System Analyst'а, а не BA.

3. Я отличаюсь от BA в практике

Хотя я знаю бизнес-процессы, но мой фокус остаётся на технологии:

Но я НЕ чистый System Analyst

Мой + ко мне бизнес-аналитические навыки

Я осознаю, что технические решения должны быть обоснованы бизнесом, поэтому я:

1. Понимаю бизнес-контекст перед тем, как предложить архитектуру

   • Зачем нам нужна эта система?
   • Какие проблемы она решает?
   • Какой ROI ожидается?

2. Могу говорить на языке business

   • Не просто "микросервисы" — "больше гибкости = меньше time-to-market"
   • Не просто "Kafka" — "сможем обрабатывать в 10x больше событий = масштабируемость"

3. Принимаю во внимание стоимость

   • Есть ли budget на этот инструмент?
   • Нужна ли нам сложная архитектура или MVP достаточно?
   • Total Cost of Ownership важен

Пример из проекта:

Business запрос: "Нам нужна система для обработки заказов"

Мой анализ:
1. Business context: 100K заказов/день, $10M revenue
2. Technical requirements: 99.99% uptime, <100ms latency
3. Architecture: Event-driven с Kafka (а не монолит)
4. Cost: $50K инфраструктура + $200K разработка
5. ROI: Сокращение downtime = +$1M в год
6. Decision: Архитектура justified и cost-effective

Это комбинация System Analyst (выбрал архитектуру) + Business Analyst (обосновал стоимость).

Идеальная роль для меня

Название: Lead System Analyst или Technical Architect

Что я делаю:

1. Анализирую бизнес-требования (BA навыки)
2. Проектирую техническую архитектуру (SA навыки)
3. Объясняю trade-offs и их влияние на стоимость и результаты
4. Работаю с обеими сторонами: бизнес-stakeholders и dev team

Мой value proposition:

• Вижу картину целиком (бизнес + технология)
• Предлагаю решения, которые work (не переусложняю)
• Могу обосновать любое архитектурное решение
• Говорю на языке всех заинтересованных сторон

Когда я работаю как BA

Есть ситуации, когда я беру BA роль:

1. Фазы анализа - собираю требования от бизнеса
2. Negotiation - обсуждаю scope и expectations
3. Metric definition - определяю KPI и success criteria

Но это часть моей System Analyst работы, а не основная роль.

Выводы

Я — System Analyst с бизнес-мышлением.

Почему это лучше, чем "чистый" System Analyst:

• ✅ Понимаю почему нужна архитектура, а не просто как её построить
• ✅ Могу обосновать решения перед business
• ✅ Минимизирую overengineering - знаю, что нужно реально
• ✅ Ускоряю разработку - даю clear requirements

Почему это лучше, чем BA:

• ✅ Вижу технические ограничения - не обещаю невозможное
• ✅ Знаю scalability и reliability concerns
• ✅ Могу вести архитектурные обсуждения с dev team
• ✅ Implementable требования - не просто wishlist

Мои идеальный проект: сложная system, где техническое решение напрямую влияет на бизнес-результаты (e-commerce, fintech, real-time systems). Там я могу полностью применить оба набора навыков.