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

Кто такой бизнес-аналитик

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

1. wikipedia.org: Бизнес-аналитик — специалист, использующий методы бизнес-анализа для аналитики потребностей деятельности организаций с целью определения проблем бизнеса и предложения их решения.
2. enjoy-job.ru: Бизнес-аналитик (Business Analyst) — специалист, задачей которого является детальное изучение структуры компании, выявление проблем и поиск путей их успешного разрешения.
3. itkeys.ru: Бизнес-аналитик — это человек, который анализирует бизнес-потребности организации, а также формулирует пути и схемы усовершенствования бизнес-процессов, осуществляет стратегическое планирование.
4. proforientator.ru: Бизнес-аналитика – изучение бизнес-процессов компании-заказчика для наиболее эффективного внедрения информационных систем.
5. consulting.ru: Бизнес-аналитик в информационных технологиях – это человек, выступающий в роли интерфейса между ИТ и бизнесом, который может говорить на одном языке с представителями обеих областей и может организовать совместную работу над предметной областью. Бизнес-аналитик в бизнесе – это человек, который умеет анализировать определенный вид бизнеса или процесса (непрерывное производство, розничный бизнес, управление проектами и т.п.) или круг задач в бизнесе (маркетинг, управление запасами, бюджетирование и т.д.).
6. BABOK v.3: Бизнес-аналитик — это любое лицо, которое выполняет задачи бизнес-анализа, описанные в руководстве BABOK, независимо от своей должности или организационной роли. Бизнес-аналитик отвечает за обнаружение, обобщение и анализ информации из разных источников в рамках компании, в том числе: инструментов, процессов, документации, а также заинтересованных лиц. Бизнес-аналитик отвечает за выявление реальных потребностей заинтересованных лиц (что часто включает в себя разбор и прояснения выражаемых пожеланий) для того, чтобы определить основные задачи и выявить мотивы. Бизнес-аналитики принимают активное участие в том, чтобы спроектированное и реализованное решение соотносилось с потребностями заинтересованных лиц.
7. iiba.org: Бизнес-аналитик является проводником изменений в организации. Бизнес-анализ является дисциплинированным подходом к внедрению и управлению изменениями в организации.

Что нужно знать и уметь бизнес-аналитику?

Для начала хочу описать как я понимаю профессию бизнес-аналитика. Лично я вижу специализацию бизнес-аналитика в двух плоскостях — в бизнесе и в сфере ИТ. На мой взгляд — это два принципиально разных по навыкам специалиста.

Бизнес-аналитик в сфере ИТ:

Бизнес-аналитик — это разносторонний специалист, который должен уметь:

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

Дорожные карты профессии бизнес-аналитика от IIBA.ORG

Онлайн-курсы

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

Business Intelligence

• Основы бизнес-аналитики
• Проектирование хранилищ данных для приложений систем деловой осведомленности (Business Intelligence Systems)

Business Modeling

• Визуальное моделирование: теория и практика

Data Mining

• Data Mining

Decision Models

• Теория и методы разработки управленческих решений

Project management

• Управление проектами в соответствии со стандартом PMI PMBOK
• Управление проектами с использованием Microsoft Project 2013

Software engineering

• Введение в программную инженерию

Другие курсы

• Анализ требований к автоматизированным информационным системам
• Информационные технологии в экономике
• ИТ-стратегия
• Модели жизненного цикла и методологии разработки корпоративных систем
• Мотивация персонала
• Основы объектно-ориентированного программирования
• Основы тестирования программного обеспечения
• Процессный подход к управлению ИТ
• Управление изменениями
• ITIL. IT Service Management по стандартам V.3.1
• Управление информационными системами
• Управление ИТ на основе COBIT 4.1

Советы по оформлению любой документации для бизнес-аналитиков

1. Всегда пишите документацию для непосвященных людей в концепцию и внутреннее содержание системы, поэтому:

• Включайте в документацию вводную часть о системе (либо ссылку на документ, который описывает систему)
• Включайте в документацию список сокращений
• Если используются узкоспециализированная терминология — добавьте словарь в документ, либо создайте отдельный документ и приложите ссылку на него
• Стремитесь сопровождать большие участки текста схемами, где показывается взаимодействие различных компонентов системы
• После написания инструкций или документации, представьте себя человеком, который ранее не работал с данной системой и прочитать инструкцию/документацию. Если что-то непонятно — перепешите/дополните

2. Как документировать скрипты системы (если это требуется):

• В документе должно находиться общее концептуальное описание последовательности запусков тех или иных скриптов
• Можно представить карту вызова скриптов из компонентов системы, можно сделать некую «карту» по скриптам (mindmap)
• Сами скрипты в документе описывать не надо. Скрипты должны быть самодокументируемыми, т.е. в коде должны быть комментарии, которые заполняются разработчиками (в том числе для разъяснения бизнес-смысла скрипта)

3. Всегда стремитесь к балансу между картинками и текстом. Отсутствие или избыток картинок — не самые лучшие варианты оформления документации

Отношения с подчиненными

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

Как устроиться работать бизнес-аналитиком

1. Открываем HeadHunter;
2. Находим 20 вакансий по бизнес-анализу;
3. Выписываем из них главные пункты, которых ожидают от бизнес-аналитиков;
4. Составляем список 7 наиболее важных (общих для всех вакансий), которыми Вы не владеете;
5. Изучаем быстро за неделю;
6. Идем на собеседование (получаем обратную связь);
7. Учим дальше;
8. Повторяем цикл пунктов 6-7-6-7-… до тех пор, пока не устроитесь;
9. Сначала идите на совеседование в те компании, устроиться в которые Вы не хотите (чтобы не потерять шанс при плохом исходе собеседования).

Полезные презентации для бизнес-аналитиков

Лекции Технопарка:

Natalya Sveshnikova:

Natalia Zhelnova:

Младший аналитик

Необходимые специальные, лидерские и управленческие навыки:
1. Выявлять заинтересованных лиц (ЗЛ).
2. Управлять ожиданиями ЗЛ.
3. Проводить собрания.
4. Проводить интервьюирование.
5. Проводить анкетирование.
6. Проводить «мозговые штурмы».
7. Уметь определять границы системы.
8. Уметь выделять подсистемы и определять их границы.

9. Уметь выявлять требования типов:

• ответы и собранная информация;
• запросы заинтересованных лиц;
• глоссарий;
• стандарты и ГОСТы;
• характеристики аналогичных/наследуемых систем;
• бизнес-требования;
• бизнес-правила;
• концепция создания и развития продукта (B VISION);
• ограничения и допущения;
• концепция системы (T VISION);
• пользовательские требования;
• функциональные требования;
• функции системы/варианты использования/прецеденты (Use Cases);
• нефункциональные требования;
• требования к пользовательскому интерфейсу;
• требования к взаимодействию с внешними системами.

10. Выявлять функции системы (Use Cases), моделировать поведение системы.
11. Уметь строить трассировки/прослеживать требования.
12. Понимать основные принципы тестирования.
13. Знать английский язык на уровне, достаточном для чтения технической литературы

Аналитик

Необходимые специальные, лидерские и управленческие навыки:
Все навыки младшего аналитика, а также:

• знать, что такое ПУТ (план управления требованиями), и уметь его разрабатывать;
• понимать, какие модели существуют и где их место в разработке ПО;
• уметь создавать модель анализа;
• строить Robustness- и Sequence-диаграммы, понимать, зачем их вообще надо строить;
• уметь читать программный код;
• иметь навыки проведения презентаций

Старший/ведущий аналитик

Необходимые специальные, лидерские и управленческие навыки:
Все навыки аналитика, а также:

• иметь детальное представление о жизненном цикле проекта и продукта;
• знать, что такое ПУД (План Управления Документами проекта), и уметь его создавать;
• уметь создавать логическую модель и модель данных;
• уметь создавать простой программный код (этот навык нужен для умения читать программный код — ведь никто так не поймет разработчика, как другой разработчик, и если вы хотите говорить с разработчиками на одном языке, вам придется освоить программирование в минимальном объеме);
• уметь профессионально проводить презентации;
• проводить выученные уроки по практикам разработки и управления требованиями;
• быть наставником для аналитиков;
• уметь предотвращать и разрешать конфликты в проектах;
• уметь выявлять риски и управлять ими.

Начальник отдела анализа

Необходимые специальные, лидерские и управленческие навыки:
Все навыки аналитика, а также:

• знать модель зрелости процессов компании CMMI 1.2. в областях: RD, REQM, DAR, TS, PI, VER, RSKM, PP, PMC, IPM, VAL, QPM, SAM;
• уметь анализировать эти области на предмет требуемых улучшений и несоответствий с моделью;
• разрабатывать методологию системного анализа для компании;
• проводить тренинги и семинары;
• иметь четкое представление об управлении проектом/программой проектов;
• уметь строить и развивать команду аналитиков в проектах;
• проводить выученные уроки по результатам выполненных работ/проектов;
• участвовать в совершенствовании процессов;
• разрабатывать процедуры, регламенты, рабочие инструкции;
• создавать функциональную стратегию своего направления;
• планировать развитие отдела, вовлекать топ-менеджеров в решение стратегических и тактических вопросов;
• выстраивать эффективное взаимодействие с другими подразделениями;
• разрешать конфликты на всех уровнях;
• быть способным управлять проектом;
• профессионально развивать подчиненных;
• уметь проводить аттестацию сотрудника;
• курировать создание базы знаний отдела;
• управлять совершенствованием процессов в области анализа, разработки и управления требованиями;
• управлять формализацией процессов и созданием системы менеджмента качества отдела.

Что такое план управления требованиями?

План управления требованиями — это контракт между аналитиком и менеджером проекта на выполнение аналитических работ. ПУТ фиксирует какие требования будут разрабатываться в проекте, как и кто будет ими управлять и как будут проводиться согласование и утверждение требований.
Ниже приведен возможный состав ПУТ:

1. Введение.
2. Общее описание методологии анализа, разработки и управления требованиями в проекте.
3. Системный анализ и моделирование.
   • Обзор основных моделей системного анализа.
   • Управление артефактами (моделями) системного анализа.
4. Разработка требований.
   • Типы требований.
   • Типизация нефункциональных требований.
   • Атрибуты требования.
5. Управление требованиями.
   • Методология управления.
     • Атрибуты требований.
     • Полномочия по работе с требованиями.
     • Обсуждение требований.
     • Согласование требований.
     • Утверждение требований.
   • Жизненный цикл требований.
     • Запросы заинтересованного лица.
     • Все остальные типы требований.
   • Трассировка требований.
6. Управление изменениями в требованиях.
   • Обработка запроса на изменение.
   • Базовые версии требований (baselines) в проекте.
7. Спецификации требований.
8. Управление процессом анализа и разработки требований.
   • Список основных артефактов и деятельностей по управлению требованиями.
   • Передача знаний бизнес-аналитику.
   • Обучение и передача знаний системному аналитику.
   • Постоянные улучшения процесса анализа и разработки требований.

Что такое техническое задание?

Техническое задание (ТЗ, техзадание) — исходный документ для проектирования сооружения или промышленного комплекса, конструирования технического устройства (прибора, машины, системы управления и т. д.), разработки информационных систем, стандартов либо проведения научно-исследовательских работ (НИР).
ТЗ содержит основные технические требования, предъявляемые к сооружению, изделию или услуге, и исходные данные для разработки; в ТЗ указываются назначение объекта, область его применения, стадии разработки конструкторской (проектной, технологической, программной и т. п.) документации, ее состав, сроки исполнения и т. д., а также особые требования, обусловленные спецификой самого объекта либо условиями его эксплуатации. Как правило, ТЗ составляют на основе анализа результатов предварительных исследований, расчетов и моделирования.

Что такое План управления документами (ПУД)?

План управления документами (ПУД) — описывает, какие проектные артефакты на каком этапе проекта в каком состоянии должны находиться, какие роли являются согласующими лицами для каждого артефакта, какие роли входят в команду утверждения, какая роль является ответственной за артефакт, даты готовности артефактов и т. д. и т. п.

Что такое Спецификация требований программного обеспечения?

Спецификация требований программного обеспечения (Software Requirements Specification) — законченное описание поведения системы, которую требуется разработать. Включает ряд пользовательских сценариев (Use cases), которые описывают все варианты взаимодействия между пользователями и программным обеспечением.
Пользовательские сценарии являются средством представления функциональных требований. В дополнение к пользовательским сценариям спецификация также содержит нефункциональные требования, которые налагают ограничения на дизайн или реализацию (такие как требования производительности, стандарты качества или проектные ограничения).
В более широком смысле спецификация требований — документ с требованиями или моделями, который используется в процессе разработки и управления требованиями в проекте.

Трассировки — что это такое?

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

Обычно трассировки строятся от одного типа требований к другому, далее к третьему, четвертому типам — пока не дойдем до «конечных» типов требований. «Конечным» типом требований обычно выбирается «вариант использования» или «функциональное требование» и «нефункциональное требование». Вся информация о трассировках, их назначениях и «конечных» типах требований фиксируется в ПУТ.

Рисунок «Соответствие модели системы и требований к системе. Концептуальная модель системы и Technical Vision»:

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

Решение о том, делать или не делать трассировки и если делать, то какие именно трассировки делать, принимает менеджер проекта совместно с системным аналитиком и тест-менеджером.

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

Рисунок «Проверочные трассировки требований»:

Какие виды «архитектур» встречаются в работе аналитика?

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

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

Информационная архитектура: Определяет структуры данных и описывает все потоки данных, которые используются для поддержки бизнес-архитектуры. Такие операции, как идентификация, систематизация, категоризация, хранение данных, относятся к информационной архитектуре (Information Architecure). Может представляться в виде модели данных (Data Model).

Архитектура решения: Архитектура программного обеспечения, которое реализует функции бизнес-архитектуры (Business Architecture).

Технологическая архитектура: Описывает архитектуру IT-окружения, которое используется для поддержки информационной архитектуры (Information Architecture) и архитектуры решения (Solution (System/Application) Architecture).

Системная архитектура: Это представление системы, которое показывает реализацию функциональных возможностей системы аппаратными средствами и компонентами программного обеспечения, устанавливает связь архитектуры программного обеспечения и архитектуры аппаратных средств, а также регламентирует взаимодействие пользователя с этими компонентами. Существуют и другие определения системной архитектуры (System Architeture), например: ряд взаимосвязанных шаблонов (паттернов), которые структурируют модули и данные и обеспечивают требуемое поведение системы (см. определение Data Architecture). Системная архитектура (System Architecture) является составной частью архитектуры решения (Solution Architecture).

Архитектура программного обеспечения: Является составной частью системной архитектуры (System Architecture). Описывает организацию системы с точки зрения программных компонентов, из которых она состоит, и связи между компонентами.

Архитектура данных: Является составной частью системной архитектуры (System Architecture). Описывает структуры данных и логические связи между данными.

Методологии, с которыми работают аналитики

• Capability Maturity ModelIntegration (CMMI) — набор моделей (методологий) совершенствования процессов в организациях. Capability Maturity Model Integration (CMMI) — набор моделей (методологий) совершенствования процессов в организациях разных размеров и видов деятельности. CMMI содержит набор рекомендаций в виде практик, реализация которых, по мнению разработчиков модели, позволяет реализовать цели, необходимые для полной реализации определенных областей деятельности.
• SWEBOK (Software Engineering Body of Knowledge) — документ, подготавливаемый комитетом Software Engineering Coordinating Committee, в который вовлечено сообщество IEEE Computer Society. Назначение SWEBOK — в объединении знаний по инженерии программного обеспечения (разработке программного обеспечения).
• Rational Unified Process — унифицированный процесс разработки ПО компании Rational с однозначно выраженными рекомендациями по разработке ПО, включающими в себя перечень всех необходимых деятельностей, выполняемых проектными ролями на каждой итерации, и шаблонов артефактов.
• Microsoft Solution Framework (MSF) не является методологией разработки ПО. MSF предлагает подходы, основанные на определенной совокупности принципов, моделей, дисциплин, руководств и методик для проектов различной степени сложности, ориентированных на поставку решений.
• Iconix — Процесс разработки программного обеспечения с использованием ограниченного количества UML моделей и диаграмм, состоящий из небольших шагов, ведущих к цели.
• Спиральная разработка Barry W. Boehm (spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.
• Agile — Гибкая методология разработки программного обеспечения.
• Экстремальное программирование (англ. Extreme Programming, XP) — одна из гибких методологий разработки программного обеспечения. Авторы методологии — Кент Бек, Уорд Каннингем, Мартин Фаулер и др.

Риски и вероятные причины наступления рисков

Риски качества конечного продукта:

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

Вероятные причины наступления риска:

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

Используемая литература для подготовки статьи

• А. Перерва, В. Иванова — «Путь Аналитика»