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

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

Основополагающая часть работы бизнес-аналитика это работа с людьми. Поэтому список необходимых soft skills довольно длинный:

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

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

Знание особенностей индустрии обязательно (например, геймдев, экономика, машиностроение и т. д.). В нашей индустрии необходимо иметь следующие технические знания:

• Теоретическую базу разработки ПО (вариации методологий — от Waterfall до Agile), для лучшей интеграции активностей анализа.
• Навыки системного анализа для холистического подхода к анализу систем над которыми бизнес-аналитик работает.
• Знания в области процессов разработки требований (поиск, документирование, верификация, поддержка изменений).
• Программная архитектура для четкого понимания того, как устроены IT системы.

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

• BABOK — самый известный стандарт роли бизнес-аналитика. Объемный, детальный и довольно абстрактный список задач и техник. Но знать про него и понимать основы основ должен любой уважающий себя бизнес-аналитик.
• PMBOK — стандарт проектного управления, содержащий руководство правильной организации требований.
• IREB — более предметный каркас процесса разработки требования с фокусом на разработку программного обеспечения.

Что должен знать/уметь аналитик и как этому научиться?

Читавшие упомянутую выше книгу «Путь аналитика. Практическое руководство IT-специалиста», особенно те коллеги, которые только начинают свою карьеру в ИТ, наверняка

прифигели

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

На мой скромный взгляд, там все-таки описан некий сферический аналитик в вакууме идеал, к которому можно (но не факт, что нужно) стремиться. Фанатичное стремление овладеть сразу всеми знаниями и навыками приведет, разве что, в Кащенко. Готов поспорить на бутылку Talisker 16 y.o., (с кем-нибудь одним, а то же, неровен час, найдутся Шелдоны (смайл)), что в природе нет ни одного человека, полностью соответствующего продвигаемому в книге образу (со всем описанным набором знаний и навыков), включая самого автора книги.

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

• о жизненном цикле ПО;
• о нескольких ключевых методологиях разработки (waterfall, RUP, что-то из Agile, лучше бы Scrum, для гос. заказчиков – ГОСТ 19 (на программы) и 34 (на автоматизированные системы));
• об основах системного анализа (Вигерс отлично подойдет);
• о нотациях и инструментах проектирования и моделирования (самые востребованные на рынке, пожалуй: Sparx Enterprise Architect и Rational Rose; и UML/Aris/IDEF0 и IDEF3);
• о теории реляционных БД;
• и т.д.

О необходимости владеть в совершенстве Word-ом или его аналогом даже не пишу (смайл). А вот о необходимости владеть хотя бы одним инструментом для проектирования макетов интерфейсов, стоит упомянуть. Выделенные интерфейс-дизайнеры – редкость, так что эта работа часто «падает» на аналитиков. Здесь кроме очевидного Visio могу посоветовать простой и удобный Evolus Pencil.

Плюс, некоторые личные качества, такие как ответственность, коммуникабельность и внимание к деталям, действительно стоит «прокачивать». Для этого есть специальные техники.

. «Power BI и Excel для продвинутых: DAX и Power Query»

Начать обучение

Кто проводит курс: онлайн-университет «Нетология».

Сколько длится: 2 месяца.

Что ты узнаешь и чему научишься из курса:

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

Твои навыки после прохождения курса:

• Знание продвинутых приёмов работы с Power Query и M
• Составление расширенных интерактивных отчётов
• Работа с архитектурой табличной модели
• Выполнение сложных выражений DAX в Power BI, Power Pivot
• Работа с текущим контекстом фильтра с помощью выражений DAX
• Изменение отображения итогов и промежуточных итогов
• Работа с иерархиями и связанными функциями
• Вычисление различных скользящих средних без использования функции Time Intelligence
• Работа с расширенными вычислениями с использованием итераторов
• Понимание работы Bidirectional фильтров
• What-if анализ. Глубокое погружение в CALCULATE()
• Динамическая безопасность на уровне строк

Стоимость:

27 900 19 530 рублей (2 325 рублей в месяц).

Отзывы:

Нюансы и особенности:

• По окончании курса ты получишь удостоверение о повышении квалификации установленного образца
• Можно оплачивать курс в рассрочку с помощью беспроцентного кредита от «Тинькофф» или «Сбербанк»

. «Excel Google-таблицы с 0 до PRO»

Начать обучение

Кто проводит курс: онлайн-университет SkillBox.

Сколько длится: 4 месяца.

Что ты узнаешь и чему научишься из курса:

Твои навыки после прохождения курса:

• Создание сводных диаграмм, спарклайнов, группировка и настройка вычислений
• Работа с функциями проверки данных
• Прогнозирование ситуаций и различных показателей
• Импорт и экспорт данных, работа с OLAP-кубами
• Работа с диапазонами
• Создание макросов для VBA
• Умение быстро фильтровать большие массивы данных

Стоимость:

30 000 18 000 рублей (1 500 рублей в месяц по рассрочке).

Отзывы:

Нюансы и особенности:

• Первым 20 участникам курса — скидка 40%
• Доступ к курсам — навсегда
• Бесплатная консультация для желающих приобрести курс
• По окончании курса ты получишь диплом
• Гарантия возврата средств — в течение 14 дней

Зачем нужны аналитики? (привет, кэп)

До сих пор от некоторых разработчиков (хотя сейчас уже очень редко) можно услышать, что аналитики (равно как руководители проектов, менеджеры по продукту и т.д.) не только не вносят полезный вклад в дело, но и просто «мешаются под ногами». Лезут, понимаешь, со своими процессами, бумажками и прочей бюрократией — не дают простому девелоперу спокойно работать (смайл).

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

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

Создать успешное мобильное приложение и заработать на нем понятные деньги сейчас (пока еще?) под силу одному человеку. Возвращаясь, собственно, к роли аналитиков. Чтобы не растекаться мыслью по древу, просто перечислю основные моменты, с которыми им приходится сталкиваться в реальных проектах:

• Выслушать заказчика. Иногда уже это бывает непросто – некоторые способны говорить часами буквально ни о чем, и не всегда легко удается перевести общение в конструктив. Тут ключевым является навык активного слушания.
• Понять иногда «птичий» язык заказчика и сформулировать его требования понятным языком, полно и без противоречий. Т.е. превратить поток сознания клиента в набор формализованных требований.
• В некоторых случаях, когда заказчик «сам не знает, чего хочет», предложить оптимальное решение или «подвести» к нему самого заказчика;
• Проанализировать влияния новых требований на существующую архитектуру и функционал. Здесь часто будут полезны консультации архитектора.
• Задокументировать требования в виде документа или набора документов в требуемом виде. Затем согласовать их и утвердить.
• Завести талоны в системе такс-трекинга и в дальнейшем отслеживать их нелегкую судьбу. Завести может и архитектор или dev. lead по ТЗ, но чаще это делает аналитик.
• Осуществлять верхнеуровневый контроль соответствия реализованного функционала требованиям.
• Управлять изменениями требований.
• Осуществлять все взаимодействие с заказчиками по вопросам требований.
• Часто – участвовать в сдаче продукта заказчику.

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

Краткое техническое отступление

Давайте сознательно прервем повествование и остановимся на самих требованиях. Что касается видов, атрибутов, характеристик, подходов к сбору и оформлению требований – пожалуй, большего «бардака» сложно найти. Состав и содержание документов с требованиями существенно различаются (взять, к примеру, наш ГОСТ и RUP, и имхо это не сравнение пушки и рогатки).

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

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

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

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

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

Сами варианты использования описывается в виде составляющих их последовательностей действий со всеми возможными пред/постусловиями и ветвлениями. Часто описание является текстовым (эта тема хорошо описана в книге Алистера Коберна ” Современные методы описания функциональных требований к системам “).

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

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

В этом же документе детализируются сценарии использования Системы (Требования пользователей), к которым обычно и привязываются функциональные требования.Пример функционального требования: «По клику на кнопке <Кнопка А> на форме <Форма Б> должно отображаться модальное диалоговое окно, содержащее <Содержание окна>».

По типу:Функциональные требованияОписывают непосредственно функционал, реализуемый Системой (пример приведен выше в описании классификации требований по их уровню в пункте «Функциональные требования»);

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

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

Описывать характеристики (непротиворечивость, полноту и т.д.) качественных требований и все их атрибуты (статус, источник и т.д.) здесь не буду, чтобы не раздувать пост. Если эта тема будет интересна, с удовольствием освещу ее в отдельной статье, хотя все это без труда гуглится.

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

1. Произойдет смешивание в одном документе результатов различных типов работ, выполняемых разными людьми (аналитиком и архитектором);
2. Срок сдачи технического задания будет увеличен, т.к. для его завершения потребуются некоторые результаты этапа проектирования.
   Результаты этапа проектирования эффективнее оформлять в отдельном документе, описывающем архитектуру Системы.

Однако некоторые отступления, такие как включение в «Техническое задание» спроектированных макетов интерфейса (без дизайна/оформления), допустимы, т.к. выполняются теми же людьми, которые разрабатывают само техническое задание.

Порядок сбора самих требований:

1. Сначала выявляются цели создания Системы (бизнес-требования). Может сложиться впечатление, что фиксация данных требований не является обязательной для разработки. Но в этом случае у Исполнителя не будет возможности контролировать соответствие разработанной Системы тем целям, для которых она создавалась, а так же – возможности устанавливать семантические зависимости между целями разработки системы и сценариями ее использования;
2. Далее определяются роли пользователей Системы (как людей, так и других программных систем). После этого выявляются и описываются сценарии использования Системы каждой из данных ролей. Так формируются Требования пользователей.
3. Далее разрабатывается полный набор требований к функционалу Системы таким образом, чтобы данный функционал позволял выполнить все сценарии, описанные в Требованиях пользователей. Так же фиксируются ограничения для Системы и параметры среды ее функционирования.

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

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

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

• Исполнитель понимает, что требования не всегда могут быть сформулированы Заказчиком полностью и корректно на начальных стадиях проекта. Соответственно, изменения в требованиях по ходу проекта допускаются.
• Заказчик понимает, что изменение требований влечет за собой увеличение трудозатрат и сроков сдачи продукта.

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

• ко всем относящимся к разработке ПО материалам;
• ко всем ключевым носителям информации и лицам, обладающим требуемыми полномочиями

Во втором случае имеются в виду:

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

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

Кто есть кто?

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

Дата-аналитик — это человек, который работает с большим объемом информации. Основная обязанность заключается в том, чтобы извлечь нужные данные и проанализировать их для дальнейших решений. То есть этот специалист решает 3 основные задачи: сбор и анализ данных, а также разработка бизнес-решений на основе полученной информации. (wiki)

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

То есть классический бизнес-анализ — это реинжиниринг процессов. Например, если компания хочет изменить организационную структуру: из 1 департамента сделать 5.

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

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

Имеем процесс, но не имеем как таковой позиции. Это то, что было придумано исключительно на нашем рынке. Зачастую это означает смесь системного аналитика и product owner.

Product owner — связующее звено между заказчиком и командой. Главная его задача — создать и контролировать backlog. (источник)

Product manager — специалист, который работает с продуктом, исследует рынок, анализирует финансовую часть. Фактически этот человек выступает CEO продукта. (wiki)

Наша главная проблема — симбиоз, когда на 1 специалиста вешают задачи совсем других направлений. Но невозможно быть профи сразу в 10 областях.

Однако неопределенность — это реалии украинского рынка в мире IT. Здесь нет четких различий между специалистами. Границы очень размыты. В одной компании от вас требуют одни скиллы, в другой — совершенно иные. Если вы планируете работать на украинском рынке, то будьте готовы к тому, что ваши задачи не ограничатся только обязанностями бизнес-аналитика.

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

Кто такой бизнес-аналитик и как помогает компаниям быть на шаг впереди

Нетология: продуктовая аналитика – перейти на сайт

Информация о курсе

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

Чему вы научитесь:

• Строить систему метрик для конкретного товара/продукта/услуги;
• Организации аналитического подхода;
• Масштабированию аналитики для больших проектов;
• Визуализации полученных данных;
• Составлению отчетов для руководства;
• Работать с базами данных;
• Построению юнит-экономики продукта.

Преимущества:

• Подходит для новичков;
• Демо-доступ на 7 дней;
• Работа над реальными проектами;
• Свой центр развития карьеры.

Недостатки:

• Скидка на обучение действует до 8.12.20;
• Задержки обратной связи от авторов.

Мой рейтинг – 5,0

• Цена – 5
• Программа – 5
• Преподаватели – 5
• Ценность сертификата – 5
• Трудоустройство – 5

Информация о курсе

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

Чему вы научитесь:

• Оптимизации бизнес-процессов;
• Анализу и описанию экономики бизнеса;
• Расчёту экономического эффекта от внедрения стратегических решений;
• Находить потенциал для развития или оптимизации бизнеса;
• Структурировать решение текущих задач;
• Расчету экономического потенциала.

Преимущества:

• Помощь с трудоустройством;
• Диплом об окончании обучения;
• Создание портфолио во время учебы;
• Обратная связь от преподавателей;
• Доступна рассрочка платежей.

Недостатки:

• Скидка на курс только до 8.12.20;
• Долгие проверки домашних заданий.

Мой рейтинг – 5,0

• Цена – 5
• Программа – 5
• Преподаватели – 5
• Ценность сертификата – 5
• Трудоустройство – 5

Рейтинг лучших курсов бизнес-аналитики

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