Бизнес-аналитик. Кто, зачем и как ?

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

Роли бизнес-аналитика:

1. Связующее звено между бизнесом и IT — анализирует потребности бизнеса и передает их команде разработчиков.
2. Инициатор изменений — помогает находить и внедрять новые решения для повышения эффективности бизнеса.
3. Моделировщик процессов — создает схемы и модели бизнес-процессов для оптимизации работы компании.
4. Фасилитатор — организует и проводит встречи для обсуждения требований и проблем.
5. Аналитик решений — оценивает предлагаемые решения с точки зрения их соответствия потребностям бизнеса и реальной реализации.

Задачи бизнес-аналитика:

1. Сбор и анализ требований — определение потребностей бизнеса через общение с заказчиками и другими заинтересованными лицами.
2. Документирование требований — создание технической и бизнес-документации, включающей Use Cases, user stories, и модели процессов.
3. Разработка предложений по улучшению процессов — выявление проблем и возможностей для оптимизации бизнес-процессов.
4. Моделирование процессов — создание схем текущих и будущих процессов, анализ вариантов улучшения.
5. Оценка решений — анализ предлагаемых решений на соответствие требованиям, оценка их целесообразности и рисков.
6. Тестирование и контроль — участие в тестировании для проверки соответствия решения бизнес-требованиям.

Системный аналитик (SA) — это специалист, занимающийся анализом технической стороны проекта. Он фокусируется на проектировании информационных систем и их архитектуры, взаимодействует с разработчиками, проверяя совместимость решений с текущими системами. Основная задача — детализировать требования к системе, определить технические спецификации и интеграции.

Задачи системного аналитика:

1. Проектирование архитектуры системы — создание схем и описаний систем, включая базы данных, интерфейсы и взаимодействие между компонентами.
2. Технический анализ — изучение и анализ текущих информационных систем, их слабых мест и возможностей для улучшения.
3. Составление технической документации — создание технических требований, спецификаций и сценариев взаимодействия компонентов системы.
4. Интеграция решений — анализ взаимодействий между различными системами и обеспечение их корректной работы.
5. Работа с разработчиками — совместная разработка технических решений, участие в разработке прототипов и тестировании.

Отличия бизнес-аналитика от системного аналитика:

1. Фокус работы:
• Бизнес-аналитик сосредотачивается на понимании бизнес-процессов и решении проблем бизнеса.
• Системный аналитик фокусируется на технической реализации требований и проектировании систем.
2. Роль в проекте:
• Бизнес-аналитик чаще взаимодействует с заказчиком и представителями бизнеса, акцентируя внимание на улучшении бизнес-процессов.
• Системный аналитик взаимодействует с технической командой, ориентируясь на архитектуру системы и спецификации.
3. Тип требований:
• Бизнес-аналитик работает с бизнес-требованиями, создавая концептуальные модели процессов.
• Системный аналитик отвечает за детализированные технические требования, включая интеграцию систем.
4. Документация:
• Бизнес-аналитик создаёт высокоуровневую документацию, понятную бизнесу (диаграммы процессов, user stories).
• Системный аналитик пишет техническую документацию, ориентированную на разработчиков и системных администраторов (технические спецификации, схемы баз данных).

Первый артефакт Бизнеса-аналитика

Документ о концепции и границах проекта по методу Вигерса (Robin B. Wiegars) помогает определить основные цели, задачи и границы проекта для успешного управления требованиями. Вот более подробное описание основных элементов, которые должны быть включены в этот документ:

1. Цель проекта

• Описание проблемы: Что конкретно планируется решить с помощью проекта? Это может быть проблема бизнеса или необходимость в автоматизации процессов.
• Ожидаемые результаты: Четко формулируются конкретные результаты, которые должны быть достигнуты. Например, увеличение производительности, улучшение пользовательского опыта, снижение затрат.
• Обоснование бизнес-ценности: Каким образом проект приносит выгоду организации? Обосновываются инвестиции, которые делаются в проект.

2. Границы проекта

• Включенные элементы: Какие компоненты или функции точно будут частью проекта? Например, системы или процессы, которые будут автоматизированы или изменены.
• Исключенные элементы: Что не входит в проект? Важно указать, какие области не затрагиваются, чтобы избежать недопонимания и размытых ожиданий. Например, может быть указано, что поддержка определенных старых версий системы не предусмотрена.
• Функциональные и нефункциональные требования: Описываются основные функции, которые должны быть реализованы, а также нефункциональные требования, такие как производительность, безопасность и надежность.

3. Пользователи и стейкхолдеры

• Целевые пользователи: Кто будет непосредственно пользоваться системой? Описываются их роли и задачи, которые они выполняют с помощью системы. Например, операторы, менеджеры, конечные клиенты.
• Заинтересованные стороны: Кто влияет на проект и принимает ключевые решения? Это могут быть руководители, технические специалисты, клиенты или регуляторы. Каждая заинтересованная сторона может иметь свои ожидания, которые нужно учитывать.

4. Основные функции проекта

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

5. Ограничения и предположения

• Ограничения: Внешние и внутренние факторы, которые могут ограничивать проект. Это могут быть временные рамки, бюджетные ограничения, доступность ресурсов, технические ограничения (например, ограничения инфраструктуры).
• Предположения: Основные предположения, на которых основан проект. Например, что определенная технология будет доступна или что заинтересованные стороны будут активно вовлечены. Эти предположения необходимо документировать, так как их изменение может существенно повлиять на проект.

6. Критерии успеха

• Метрики для оценки: Какие показатели будут использоваться для оценки успешности проекта? Это могут быть показатели производительности, уровень удовлетворенности пользователей, соблюдение сроков и бюджета.
• Критерии завершенности: Что означает успешное завершение проекта? Например, все ключевые функции реализованы, система работает без ошибок, удовлетворены требования всех заинтересованных сторон.

7. Риски и способы их минимизации

• Идентификация рисков: Описываются возможные риски, которые могут возникнуть в ходе реализации проекта. Это могут быть технические риски, организационные, финансовые или внешние (например, изменения в законодательстве).
• Планы по управлению рисками: Как планируется управлять рисками? Описываются конкретные меры, которые будут предприняты для минимизации рисков или для реагирования на них, если они возникнут. Например, резервирование ресурсов, привлечение экспертов, регулярные проверки прогресса.

8. Подход к управлению изменениями

• Процессы изменения требований: Описывается, как будут управляться изменения в требованиях по ходу проекта. Важно иметь механизм для оценки и согласования изменений, чтобы они не приводили к "расползанию" границ проекта.
• Участие заинтересованных сторон: Кто будет вовлечен в процесс принятия решений по изменению границ проекта? Как часто будут проводиться встречи или обсуждения для пересмотра требований?

9. Коммуникация в проекте

• Каналы и частота коммуникаций: Как будут взаимодействовать члены команды и стейкхолдеры? Определяются основные каналы (встречи, электронная почта, чаты) и частота отчетов о прогрессе.
• Ответственность за коммуникации: Кто отвечает за информирование команды и стейкхолдеров о прогрессе, изменениях или проблемах?

Выявление требований

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

1. Интервьюирование стейкхолдеров

• Описание: Один из наиболее распространенных способов сбора требований — проведение интервью с ключевыми стейкхолдерами проекта. Это позволяет получить глубокое понимание ожиданий и задач каждого участника.
• Процесс:
• Подготовка вопросов заранее.
• Прямые встречи с ключевыми пользователями, заказчиками или техническими специалистами.
• Использование открытых вопросов для выявления детализированных требований.
• Преимущества:
• Возможность выявить скрытые потребности или проблемы, о которых стейкхолдеры могут не знать.
• Формирование отношений с участниками проекта, что помогает в будущем взаимодействии.
• Важно:
• Необходимо документировать все ответы, чтобы избежать неточностей.
• Важно привлекать все ключевые стороны, чтобы не пропустить важные требования.

2. Мозговые штурмы (Brainstorming)

• Описание: Этот метод используется для сбора идей и предложений от группы людей в процессе обсуждения. Он помогает быстро генерировать множество идей, включая нестандартные решения.
• Процесс:
• Собирается команда, включающая представителей всех заинтересованных сторон.
• В течение короткого времени высказываются идеи без критики или анализа.
• На следующем этапе проводится фильтрация и уточнение идей.
• Преимущества:
• Генерация большого количества идей за короткое время.
• Участники могут предложить неожиданные и творческие решения.
• Важно:
• Необходимо четко фиксировать все высказанные идеи и их интерпретацию.
• Требуется фокусировать обсуждение, чтобы не уходить в сторону от ключевых вопросов проекта.

3. Анкетирование и опросы (Surveys and Questionnaires)

• Описание: Анкеты или опросы используются для получения информации от большой группы людей. Этот метод удобен для проектов с большим количеством пользователей или стейкхолдеров, когда невозможно лично опросить всех.
• Процесс:
• Создание списка вопросов с возможностью как открытых, так и закрытых ответов.
• Рассылка анкет или организация онлайн-опроса.
• Анализ полученных данных для выявления общих потребностей и ожиданий.
• Преимущества:
• Возможность охватить большое количество респондентов.
• Экономия времени при сборе ответов от множества участников.
• Важно:
• Вопросы должны быть четкими и не содержать двусмысленностей.
• Необходимо обеспечить высокий процент ответов, чтобы получить точные данные.

4. Анализ существующей документации

• Описание: Этот метод предполагает изучение уже имеющихся документов, таких как бизнес-планы, существующие спецификации, отчеты, стандарты или законодательные акты. Это помогает выявить требования на основе анализа уже существующих решений и процессов.
• Процесс:
• Анализ текущей системы и ее процессов.
• Изучение требований, описанных в прошлых проектах или связанных документах.
• Идентификация недостатков или улучшений.
• Преимущества:
• Быстрый доступ к уже существующей информации.
• Возможность избежать ошибок, допущенных в прошлом.
• Важно:
• Необходимо критически анализировать информацию, так как она может быть устаревшей или не полностью соответствовать текущим задачам проекта.

5. Наблюдение за пользователями (Observation)

• Описание: Этот метод предполагает наблюдение за тем, как пользователи работают с существующей системой или выполняют свои задачи в текущих условиях. Наблюдатель может выявить проблемы и потребности, которые пользователи не всегда осознают.
• Процесс:
• Анализ реальных действий пользователей в их рабочей среде.
• Сбор данных о том, как они взаимодействуют с системой, какие задачи выполняют, с какими проблемами сталкиваются.
• Преимущества:
• Позволяет увидеть реальные рабочие процессы и проблемы, которые могут не быть очевидными для пользователей.
• Обеспечивает понимание контекста использования системы.
• Важно:
• Наблюдение должно быть ненавязчивым, чтобы не нарушать естественный процесс работы.
• Необходимо комбинировать наблюдение с другими методами, чтобы понять полную картину.

6. Моделирование процессов (Process Modeling)

• Описание: Визуализация текущих и желаемых процессов в виде диаграмм или схем. Этот метод помогает лучше понять рабочие процессы и выявить места для улучшения.
• Процесс:
• Создание диаграмм бизнес-процессов, отображающих действия и решения, принимаемые пользователями.
• Моделирование будущих процессов для анализа возможных изменений.
• Преимущества:
• Упрощает понимание сложных процессов.
• Позволяет легко идентифицировать узкие места и возможности для улучшения.
• Важно:
• Модели должны быть понятными для всех участников проекта.
• Необходимо регулярно обновлять модели по мере изменения процессов.

7. Рабочие семинары (Workshops)

• Описание: Семинары предполагают проведение групповых встреч с ключевыми участниками проекта для совместного обсуждения и уточнения требований. Это помогает обеспечить участие всех заинтересованных сторон и достичь общего понимания целей.
• Процесс:
• Организация встреч с участием различных групп стейкхолдеров.
• Совместное обсуждение требований и анализ предложений.
• Фасилитатор помогает структурировать обсуждение и фиксирует результаты.
• Преимущества:
• Обеспечивает активное участие всех ключевых стейкхолдеров.
• Помогает согласовать разные точки зрения и выработать единые требования.
• Важно:
• Важно четко планировать повестку дня и управлять временем встречи.
• Фасилитатор должен обеспечивать баланс в обсуждении и помогать разрешать споры.

8. Прототипирование (Prototyping)

• Описание: Прототипы создаются для визуализации будущей системы или продукта. Это могут быть интерактивные макеты, чертежи или даже действующие модели, которые помогают пользователям понять, как будет выглядеть конечный продукт.
• Процесс:
• Создание первоначальных версий интерфейсов или функций системы.
• Демонстрация прототипов стейкхолдерам и получение обратной связи.
• Постепенное улучшение прототипов на основе комментариев.
• Преимущества:
• Помогает пользователям визуализировать будущую систему и предоставить точную обратную связь.
• Уменьшает риск недопонимания требований.
• Важно:
• Прототипы должны быть гибкими для внесения изменений на основе обратной связи.
• Необходимо контролировать ожидания, чтобы пользователи не путали прототип с финальной системой.

9. Анализ конкурентов (Competitive Analysis)

• Описание: Этот метод заключается в изучении существующих решений конкурентов для понимания их сильных и слабых сторон, а также для поиска вдохновения для улучшений.
• Процесс:
• Сравнительный анализ аналогичных продуктов на рынке.
• Идентификация функций и возможностей, которые могли бы быть полезными для вашего проекта.
• Преимущества:
• Позволяет понять, что уже существует на рынке и какие функции необходимы для конкуренции.
• Может ускорить процесс принятия решений за счет использования проверенных решений.
• Важно:
• Анализ конкурентов должен быть систематическим и включать как успешные, так и неудачные аспекты их продуктов.