Будь бизнес-аналитиком

Как читать эту книгу?

Изучите содержание

Книга составлена из разных разделов. Каждый раздел уникален и не связан с предыдущим. Начинать чтение можно с любого раздела.

Пользуйтесь дополнительными материалами

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

Дисклеймер

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

В книге мы часто используем цитаты из основных источников знаний для бизнес-аналитиков.

BABOK (Business Analysis Body of Knowledge) – руководство к своду знаний по бизнес-анализу, содержащее набор общепринятых практик от Международного института бизнес-анализа IIBA® (International Institute of Business Analysis). Первая версия вышла в 2005 году, а последняя (3.0) – в 2015. Переведена на русский язык в 2021.

Карл Вигерс – гуру бизнес-анализа. Первое издание его книги «Разработка требований к программному обеспечению» вышло в 1990 году и считается библией бизнес-анализа для начинающих бизнес-аналитиков. Мы предпочитаем цитировать 3-е издание, бережно переведенное на русский в 2014 году издательством «Русская редакция» и БХВ- Петербург.

Что внутри?

Каждый раздел связан с различными этапами или спецификой работы бизнес-аналитика.

1. Раздел «Бизнес-анализ» мы включили, чтобы показать роль бизнес-аналитика в компании.

2. Содержание раздела «Требования» подскажет, как можно выявить основные пожелания всех стейкхолдеров и в понятном виде передать их на исполнение.

3. В разделе «Стейкхолдеры» рассказываем о том, как бизнес-аналитик может выследить, услышать и понять стейкхолдеров в привычной для них среде обитания.

4. Про анализ бизнес-процессов можно прочитать в «Процессах».

5. В «Продуктах» рассказываем про гибкую разработку и работу бизнес-аналитика в команде по созданию цифровых продуктов.

6. В разделе «Эффективность» агрегированы наиболее часто использующиеся метрики и показатели эффективности, которые не так просты, как кажутся.

7. Раздел «Soft Skills» содержит описание наиболее востребованных у бизнес-аналитиков навыков коммуникации.

8. В разделе «Групповая работа» собраны ключевые инструменты для успешной коммуникации при проведении бизнес-анализа.

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

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

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

Роль бизнес-анализа

Бизнес-анализ – это практика обеспечения изменений в контексте компании путем определения потребностей и рекомендации решений, которые приносят пользу заинтересованным сторонам. BABOK 3.0

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

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

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

Компаниям для увеличения прибыли приходится постоянно адаптироваться под меняющиеся условия: усиливается конкуренция, развиваются технологии, меняются вкусы потребителей и запросы акционеров. Такие процессы предполагают активное внедрение изменений. Если в компании есть место изменениям – значит, есть место и бизнес-анализу.

В чем польза бизнес-анализа для компании?

1) Снижение затрат

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

2) Предвидение кризиса

Бизнес-анализ готовит компанию как к хорошим, так и к плохим временам. Моделирование сценариев будущего помогает заранее понять и предвидеть кризис в компании или на рынке в целом.

3) Управление изменениями

Бизнес-анализ готовит компанию как к хорошим, так и к плохим временам. Моделирование сценариев будущего помогает заранее понять и предвидеть кризис в компании или на рынке в целом.

4) Внедрение ИТ-решений

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

Чем больше изменений внедряется в компании – тем сильнее потребность в бизнес-анализе. Больше всего изменений привносят ИТ-технологии.

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

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

В каких проектах сильнее всего ощущается эффект от привлечения бизнес-аналитика?

– У заказчика много пожеланий к продукту, но нет точного списка функций и требований для команды

– У проекта больше трех стейкхолдеров, которым сложно договариваться друг с другом

– Проект масштабный, сложный и высокорискованный

– Проект длится больше года

– Проект нужно будет документировать

По результатам исследований Национального института стандартов и технологии США, цена ошибки многократно увеличивается по мере реализации проекта.

Стоимость внесения исправлений на этапе планирования:

в 10 раз ниже, чем на этапе разработки;

в 50 раз ниже, чем на этапе тестирования;

Затраты на качественное планирование с использованием бизнес-анализа окупают себя уже на этапе внедрения.

Профессиональный подход к бизнес-анализу помогает значительно сократить сроки и повысить качество разработки. Компания по разработке ПО Andersen провела оценку реализации проектов с участием и без участия бизнес-аналитика.

MVP (Minimal Viable Product) – минимально жизнеспособный продукт[1]

Бизнес-аналитик – это основное лицо, отвечающее за выявление, анализ, документирование и проверку требований к проекту. К. Вигерс

Каждый проект подразумевает выполнение задач по бизнес-анализу.

Во многих крупных компаниях уже есть штатные бизнес-аналитики. Но что они делают, не всегда понятно остальным сотрудникам.

Важно четко определить зону ответственности бизнес-аналитиков внутри компании.

Работа бизнес-аналитиков включает в себя:

– понимание проблем и задач компании;

– анализ потребностей и решений;

– разработку стратегий;

– внедрение изменений;

– взаимодействие со стейкхолдерами;

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

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

До проекта:

Генерация идей – Предварительный анализ идей и обоснование экономической эффективности

Реализация проекта:

Бизнес-аналитик:

– Проводит оперативный мониторинг достижения КПЭ[2]

– Помогает руководителю проекта оценивать и контролировать объемы работ по проекту

– Помогает команде внедрения создавать обучающие материалы по проекту

Планирование – Определение задач бизнес-анализа вместе с руководителем проекта

Подготовка – Выявление требований у стейкхолдеров

Проектирование - Проверка предложенных ИТ-решений на соответствие требованиям

Разработка - Разъяснение требований стейкхолдеров разработчикам, трассировка требований

Тестирование - Разработка тестовых кейсов с тестировщиками

Развертывание - Согласование с разработчиками изменений в новые релизы

Техническая поддержка - Переход в обычный режим и передача ИТ-решения команде внедрения

После проекта:

Реализация ценности – Оценка результатов и степени удовлетворения запросов стейкхолдеров

Компетенции бизнес-аналитика

Бизнес-аналитик – это посредник между заинтересованными сторонами, который помогает понять структуру, политику и процессы организации, а также рекомендовать решения, которые позволяют организации достичь своих целей. Определение IIBA[3]

С практической точки зрения, бизнес-аналитик работает как связующее звено между компанией, технологией, поставщиками и регулирующими органами.

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

Базовые компетенции бизнес-аналитика включают в себя модели поведения, характеристики, знания и личностные качества, которые помогают выполнять задачи бизнес-анализа. BABOK 3.0

В версии BABOK 3.0 выделены 6 категорий базовых компетенций:

Бизнес-аналитик в проектах

Проекты в структуре изменений компании

Что делает бизнес-аналитик в проектах?

1) Взаимодействует со стейкхолдерами;

2) Моделирует и анализирует бизнес-процессы;

3) Выявляет и анализирует требования, в т.ч. в виде пользовательских историй;

4) Проводит оценку связности требований на предмет взаимных зависимостей, ограничений и целей, создает матрицу трассировки требований;

5) Составляет проектную документацию в части управления требованиями;

6) Разрабатывает финансово-экономическую модель проекта и готовит обоснование эффективности проекта для получения инвестиций;

7) Разрабатывает сценарии тестирования;

Существует достаточно много моделей разработки программного обеспечения. Для начинающего аналитика важно различать два подхода – классический и гибкий.

Проект с использованием гибких методологий

При высокой неопределенности целевого результата создание ИТ-продуктов реализуется с использованием гибких методологий.

Бизнес-аналитик может быть задействован на всех этапах реализации проекта вне зависимости от выбранной модели реализации.

Тогда сначала разрабатывается прототип приложения (который может быть даже не рабочим), чтобы убедиться, что продукт будет отвечать потребностям пользователей. Потом отбирается часть требований, и разрабатывается MVP – минимально жизнеспособный продукт. Он сразу передается пользователям для проверки гипотезы о востребованности. И затем продукт развивается дальше.

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

А после каждой итерации происходит актуализация требований и задач.

Взаимодействие с руководителем проекта

Роли

1. Заказчик

Формулирует запрос

2. Руководитель проекта

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

3. Бизнес-аналитик

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

Модель взаимодействия

В общем виде модель взаимодействия бизнес-аналитика и руководителя проекта выглядит так:

Особенности взаимодействия руководителя проекта и бизнес-аналитика

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

Следующий шаг приведет нас к главе, посвященной требованиям.

Все начинается с идеи. Например, такой идеи: «Хочу, чтобы холодильник сам заказывал продукты, когда надо». Такая «хотелка» к моменту итоговой реализации начинает обрастать другими «хотелками», как снежный ком при спуске с горы. Юристы хотят, чтобы пользовательское соглашение к холодильнику было размером с «Войну и мир». Продуктовые магазины хотят, чтобы холодильник заказывал у них только самые дорогие продукты. А пользователь хочет… вкусно поесть и не переживать за пустой холодильник. И чтобы было место для магнитиков.

Набор таких «хотелок» и называется требованиями.

Чтобы собрать и помочь воплотить в жизнь требования, компании нужен бизнес-аналитик.

Требования сосредоточены на понимании того, какую ценность можно получить, если требование будет выполнено. BABOK 3.0

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

Требования влияют не только на сам результат, но и на восприятие этого результата. Помните, что требования исходят от человека. А человеку свойственно радоваться от исполнения желаний (и требований).

Требования не равно цель

Важно понимать, что Цель и Требование – это разные понятия в рамках реализации проекта.

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

Требования – это формализованное описание потребностей (т.е. конкретные функции, свойства и атрибуты).

Цель. Строго связано с бизнес-показателями. Ставится 1 раз на весь период реализации проекта.

Пример: Повысить эффективность процесса обслуживания на 20%.

Требования могут ставиться многократно к разным объектам внутри проекта изменений.

Пример: Запускать процесс X ежедневно с 9 до 10 утра за исключением вторника и воскресенья.

Требования могут быть не только к ИТ-решению, но и к бизнес-процессам (о них будем говорить позже).

К ИТ-системе / к ИТ-решению

– Выбираем конкретную компоненту в ИТ-решении

– Описываем ее функциональность

– Описываем нефункциональные требования

Акценты на:

– атрибуты системы

– сроки осуществления операций

– использование справочников

К Бизнес-процессу

– Выбираем процесс или часть процесса (с учетом рамок процесса)

– Описываем требования к выполнению подшагов процесса

– Описываем условия выполнения подшагов процесса

Акценты на:

– сроках выполнения

– участниках и ответственных

– ограничениях процесса

– условиях процесса

Существует универсальная формула описания требований:

Пример 1

1.1. Требуется, чтобы будильник включался ежедневно с понедельника по пятницу в 7.00 и играл с повышением звука от уровня 1 до уровня 5.

1.2. В случае отсутствия реакции на будильник в течение 1 минуты, будильник производит паузу в течение 20 секунд и цикл п. 1.1 запускается заново.

Пример 2

2.1. Требуется автоматизированная отправка платежного поручения на адрес контрагента из системы N в момент осуществления транзакции К для каждой операции с меткой J.

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

Классификация

Сбор требований начинается с определения того, что требование должно из себя представлять. Разобраться в типах требований поможет общая классификация.

1. Бизнес-требования

Для чего это нужно нашей компании?

– Автоматизировать процессы

– Сократить затраты времени на этапах процесса

– Повысить качество продукции

– Оптимизировать принятие решений

2. Требования стейкхолдеров

Что хочет стейкхолдер?

– Рассчитать производительность и экономическую эффективность

– Получить отчеты в интересующих форматах и детализации

– Отправить запросы и получить актуальную информацию

3. Нефункциональные требования

Какие условия окружающей среды нужно учитывать и для чего?

– Создать условия для локализации

– Обеспечить юридическую, финансовую и аудиторскую прозрачность

– Сохранить конфиденциальность

– Написать документацию для пользователей

– Сохранить непрерывность бизнес-процессов

4. Функциональные требования

Что должно делать итоговое решение?

– Персонифицировать настройки

– Ограничивать доступ

– Обеспечить возможность поиска данных

– Предоставить возможность интеграции данных из других систем

5. Бизнес-правила

Что нужно сделать для соответствия внешним ограничениям?

– Выполнить условия нормативных документов

– Учесть все вводимые регулятором ограничения

– Получить лицензии и другие разрешения

6. Переходные требования

Что нужно для перехода из текущего состояния в будущее?

– Обучить пользователей из бизнес-подразделений

– Хранить документацию и данные при миграции из одной архитектуры в другую

– Разработать алгоритм ввода в эксплуатацию

– Оказать поддержку на этапе ввода в эксплуатацию

Пример: развитие персонала и обучающие приложения и порталы

Цель: Повышение эффективности производственных процессов на Х процентов за счет развития цифровых компетенций сотрудников

Бизнес-требование: Повышение численности сотрудников, прошедших курсы по ИТ, на 10%

Требование заинтересованных лиц (рядовой сотрудник):

– Доступность курса вне корпоративной сети

– Как слушателю курса, мне необходимо иметь возможность проходить курс с любых устройств в удобное время, чтобы не привязываться к РМ в офисе

Функциональное требование: Система позволяет пользователю просматривать видео-курсы с мобильного устройства, подстраивая разрешение под размеры экрана

Нефункциональное требование: Система должна стабильно работать при нагрузке не менее 1000 пользователей, одновременно работающих с видео-контентом

Свойства, которыми должны обладать требования легко запомнить по мнемоформуле: 4П-НОСОК.

Какими должны быть требования?

Полными: Представлена вся необходимая информация. Включено даже то, что может показаться общеизвестным и понятным

Приоритезированными: Требования отсортированы по важности, стабильности, срочности. Важность влияет на успех проекта. Стабильность защищает от внесения изменений. Срочность показывает насколько быстро требование должно быть реализовано

Проверяемыми: Есть возможность сформулировать измеримый критерий выполнения данного требования

Понятными: Описание сформулировано так, чтобы все участники проектной команды однозначно понимали требование

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

Осуществимыми: Обеспечена технологическая и финансовая возможность реализации требования к нужному сроку

Согласованными: Требование не должно противоречить самому себе, а также другим требованиям и реализованному функционалу

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

Корректными: Это свойство не выполняется, если нарушено хотя бы одно из вышеперечисленных свойств

Этапы работы с требованиями

Процесс работы с требованиями осуществляется поэтапно. С некоторыми оговорками. В реальности требования постоянно корректируются и изменяются. Иногда приходится возвращаться на предыдущие этапы, чтобы уточнить смысл требования. Иначе реализация требования не приведет к желаемому результату.

Перед тем, как приступить к этапу «Выявление», убедитесь, что у вас и ваших собеседников одинаковое понимание термина «требования».

Методы выявления

Традиционные

– Интервью

– Воркшопы

– Фокус-группы

– Анкетирование

– Анализ системных интерфейсов

– Анализ пользовательских интерфейсов

– Анализ документов

Дополнительные:

– Обратная связь от сотрудников

– Наблюдение за пользователями

– Наблюдение за разработчиками

– Анализ обращений в службу поддержки

– Обзор систем конкурентов

– Прототипирование

– Проверка концепции

Как выбрать метод выявления требований

1) Доступность информации

2) Количество источников информации

3) Бюджет проекта

4) Другие ограничения

Для того, чтобы собрать наиболее полные требования, рекомендуем комбинировать несколько методов.

Важно не только выбрать корректный метод сбора требований, но и качественно пройти все этапы метода.

Матрица выбора методов выявления требований

Такой тип матрицы для помощи в выборе методов выявления требований предложен К. Вигерсом.

В матрице собраны методы выявления требований для разных типов проектов разработки.

Методы анализа

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

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

Какие компоненты входят в анализ требований?

1. Понимание: Фиксируем описания в доступных для понимания терминах, со всеми деталями

2. Моделирование: Применяем моделирование процессов и данных для отображения вносимых изменений

3. Верификация: Проверяем соответствие требований критериям качества

4. Управление: Обеспечиваем исполнение и внесение изменений в подтвержденные требования

Виды моделирования при анализе требований

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

Моделирование процесса

Отображение взаимодействия между разными людьми и задачами в виде последовательности операций

Моделирование данных

Предоставление структуры и формата данных, которые используются для решения

Моделирование предметной области

Визуализация предложений в форме взаимосвязей различных предметов (документы, данные, люди и т.п.). Каждый предмет описывается в виде набора параметров

Моделирование интерфейса

Отображение структуры или дизайн-концепции интерфейса

Диаграммы потоков данных

Отображение потока движения данных: ввод, хранение, обработка, вывод

Диаграммы последовательности

Моделирование последовательности взаимодействия между объектами внутри одного сценария использования

Формализация

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

Одним из вариантов необходимого набора документов для формализации требований является:

– Концепция проекта (бизнес-требования)

– Презентация об архитектуре решения

– Техническое задание

– Технический проект

Способы формализации требований

Приоритизация

Приоритизация – это процесс определения относительной важности объекта (информации, задачи, требования и пр.) на основе предварительной оценки его значения, рисков, сложности реализация или других четких критериев. BABOK 3.0

Бизнес-аналитик должен понимать реальные потребности бизнеса, чтобы помочь всем заинтересованным сторонам расставить собранные требования по приоритетам.

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

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

Для приоритизации требований разработан целый арсенал методов.