Основы бизнес-аналитики и науки о данных

Деятельность бизнес-аналитика. Часть 1

В материале раскрывается роль бизнес-аналитика, проходящая красной нитью через весь жизненный цикл продукта: от появления бизнес-идеи до сдачи в эксплуатацию. Логика изложения строится от общего к частному. Сначала описываются четыре ключевых этапа деятельности — определение концепции, сбор требований, их анализ и проектирование системы. Затем формулируются фундаментальные принципы работы: поиск коренных причин, фокус на улучшении бизнеса, приоритет креатива над шаблонами, скорость развертывания и постоянные переговоры. Далее раскрываются конкретные обязанности, связанные с коммуникацией, документированием и контролем, и завершается картина перечнем необходимых hard и soft skills.

Основные мысли

В результате изучения лекции слушатель будет способен:
1. Описывать место бизнес-аналитика в жизненном цикле создания программного продукта и перечислять основные этапы его работы.
2. Объяснять назначение каждого этапа деятельности бизнес-аналитика и формулировать их ключевые результаты.
3. Идентифицировать и интерпретировать базовые принципы бизнес-анализа в контексте разработки ИТ-решений.
4. Анализировать различия между бизнес-требованиями и техническими требованиями, а также роль аналитика в их согласовании.
5. Оценивать влияние новых требований на существующую архитектуру и аргументировать решения о включении или отклонении изменений.
6. Систематизировать перечень ключевых hard и soft skills, необходимых бизнес-аналитику для успешного выполнения обязанностей.
Показывать лекцию целиком
Краткое изложение

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

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

Этапы работы бизнес-аналитика

1. Определение концепции продукта

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

2. Сбор требований

На этом этапе взаимодействуют с заказчиком и будущими пользователями. Требования рассматриваются с обеих сторон: заказчик описывает желаемый функционал, который затем становится требованием к пользователю. Аналитик ищет баланс между ними и выделяет наиболее важные функции, чтобы сформировать MVP (Minimum Viable Product, минимально жизнеспособный продукт). MVP содержит минимально необходимый функционал, достаточный для вывода на рынок и закрытия основных потребностей пользователей без избыточной разработки.

3. Анализ требований

Собранные требования структурируются, устраняются дубликаты и противоречия. Цель — получить четкий список неповторяющихся требований. Здесь применим принцип Парето в ИТ-формулировке: 20% функционала покрывают 80% сценариев использования. Например, у почтового ящика множество дополнительных возможностей (календарь, пометки, карточки контактов), но основные сценарии пользователей — получение и отправка писем. Принцип позволяет для первичного вывода продукта заложить только критически важные функции, сэкономив бюджет и сроки.

4. Проектирование системы

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

Ключевые принципы бизнес-анализа

Ищем коренные причины, а не симптомы. Нельзя лечить симптомы, нужно найти и устранить истинный источник проблем. Аналогия с хирургом: удаляется причина болезни, а не маскируются её проявления.
Улучшаем бизнес, а не просто внедряем ИТ-системы. Продукт должен целенаправленно улучшать ключевые показатели бизнеса (прибыль, рыночную стоимость, оценочную стоимость стартапа). Внедрение ради факта наличия системы недопустимо.
Креатив важнее шаблонных решений. Шаблонные решения проще реализовать и их риски известны, однако простота не должна быть главным аргументом. Аналитик обязан кастомизировать подходы для максимальной эффективности в конкретном случае.
Реализуемые требования, а не навязывание системой своих ограничений. Внедряемая система должна подстраиваться под бизнес-процессы, а не наоборот. Тяжелые корпоративные решения часто требуют компромиссов, но современные технологии и отвязка от платформ позволяют гибко настраивать продукт под заказчика.
Полный жизненный цикл, а не только проектирование. Создание продукта — лишь часть работы. Важно сопровождать его при внедрении и поддержке, так как на этих стадиях могут выявиться нерешенные изначально задачи.
Переговоры вместо избегания конфликтов. Взаимодействие заказчика и исполнителя — центральный фактор успеха. Заказчик мыслит бизнес-категориями, исполнитель — техническими. Бизнес-аналитик обязан перевести бизнес-требования в технические, донести до заказчика реальную картину того, что будет и что не будет сделано, и найти компромисс.
Скорость развертывания. Стремление к совершенству затягивает сроки, а идеал недостижим. Быстрый вывод продукта, даже с незначительными недочетами, ценен тем, что реальная эксплуатация выявляет проблемы, невидимые на стадии разработки.

Обязанности бизнес-аналитика

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

Ключевые функции:
Активное взаимодействие с заказчиком. Преобразует «поток сознания» и размытые пожелания в формализованные, полные и непротиворечивые технические требования. Если заказчик не может сформулировать запрос, аналитик, опираясь на опыт, предлагает оптимальное решение или подводит к нему.
Анализ влияния новых требований. Когда в процессе реализации поступает новое бизнес-требование, аналитик оценивает, как оно повлияет на архитектуру и сроки. Он может согласиться на изменение, аргументировав необходимые компенсации и сложности, либо доказать нереализуемость на первый взгляд простого пожелания.
Документирование требований. Формирует ТЗ в нужном формате, согласовывает и утверждает его.
Внедрение требований в разработку. Ставит задачи в тикет-систему (ticketing system), отслеживает их исполнение и отвечает на вопросы команд разработки на концептуальном уровне, работая скорее с группами, чем с отдельными исполнителями.
Верхнеуровневый контроль соответствия. Отслеживает, насколько реализованный функционал соответствует заявленным требованиям на этапе до передачи на тестирование, учитывая будущие тестовые сценарии.
Управление изменениями требований.
Анализ рынка и конкурентов. Изучает рыночные решения, сравнивает конкурентов, проактивно предлагает новые фичи (features).
Подготовка документации и участие в сдаче продукта.
Консультирование по техническим вопросам. При работе с корпоративными или менее массовыми продуктами может отвечать на запросы пользователей напрямую.
Подготовка аналитических отчетов и предоставление информации руководству.
Принятие решений и роль арбитра. Так как цель аналитика — успех продукта в интересах заказчика, он возвышается над внутренними конфликтами команд-исполнителей и выступает третейским судьей, разрешая споры для достижения результата.

Навыки бизнес-аналитика (Hard skills и Soft skills)

Hard skills:
• Понимание современных технологий разработки.
• Знание предметной области продукта.
• Работа с требованиями (выявление, анализ, документирование).
• Моделирование и оптимизация бизнес-процессов.
• Проектирование интерфейсов.
• Навыки решения проблем.
• Грамотная устная и письменная речь, умение работать с текстами.

Soft skills:
• Аналитические способности и системное мышление.
• Коммуникативность (ведение переговоров, модерация).
• Ответственность.
• Проактивность.
• Широкий кругозор.

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

Краткие итоги

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

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

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

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

Обязанности, связанные с оценкой влияния новых требований, демонстрируют аналитическую глубину роли. Умение проследить, как внешне простое пожелание заказчика повлияет на архитектуру, сроки и стоимость, превращает аналитика в арбитра, принимающего взвешенные решения о компромиссах. Это уже не просто посредник, а специалист, управляющий scope проекта и рисками. Перечень hard и soft skills, завершающий материал, логично вытекает из всех предыдущих блоков: многогранность деятельности требует не просто эрудиции, а сплава технических знаний, методологической подготовки, коммуникативных способностей и системного мышления. Именно эта интегральная природа делает бизнес-аналитика незаменимым участником продуктовой разработки, чья ценность прямо пропорциональна способности удерживать баланс между бизнес-целями, технологическими возможностями и человеческим фактором.
Роль и этапы работы

Бизнес-аналитик задействован на всех стадиях жизненного цикла продукта. Его деятельность делится на четыре основных этапа:
1. Определение концепции продукта.
Ведется диалог с инвестором (выгодоприобретателем), обсуждаются маржинальность, возврат инвестиций и другие аспекты. Формируется видение продукта. По итогам анализа может быть принято решение не запускать продукт, если экономический эффект не оправдает вложений.
2. Сбор требований.
Осуществляется работа с заказчиком и будущими пользователями. Требования рассматриваются двусторонне: заказчик определяет функционал, который затем становится требованием к пользователю. Аналитик выделяет наиболее важные функции для MVP (Minimum Viable Product, минимально жизнеспособный продукт) — версии с минимальным набором функций, достаточным для запуска и покрытия ключевых потребностей.
3. Анализ требований.
Требования структурируются, исключаются дубликаты и противоречия. Применяется принцип Парето: 20% функционала обеспечивают 80% сценариев использования. Это позволяет заложить в первый запуск только критически важные функции, сэкономив бюджет и сроки.
4. Проектирование системы.
Утверждается окончательный перечень функций и задач. Результатом становится техническое задание (ТЗ), описывающее поведение продукта и требования к разработке. В дальнейшем ТЗ будет расширяться.

Ключевые принципы бизнес-анализа

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

Обязанности бизнес-аналитика

Аналитик является центральной коммуникационной прослойкой между всеми стейкхолдерами (stakeholders) — спонсорами, заказчиками, пользователями, архитекторами, разработчиками и другими участниками. Его ключевые функции:
• Превращать размытые пожелания заказчика в формализованные, полные и непротиворечивые технические требования; при необходимости помогать сформулировать запрос.
• Оценивать влияние новых требований на архитектуру, сроки и бюджет. Аргументировать принятие изменения с компенсациями либо невозможность реализации.
• Документировать требования в виде ТЗ, согласовывать их.
• Внедрять требования в разработку через тикет-систему, отслеживать статус, отвечать на вопросы команд.
• Проводить верхнеуровневый контроль соответствия реализованного функционала требованиям до передачи на тестирование.
• Управлять изменениями требований.
• Анализировать рынок, конкурентов, проактивно предлагать новые фичи.
• Участвовать в подготовке документации, сдаче продукта, а при необходимости — консультировать пользователей.
• Готовить аналитические отчеты и быть арбитром в конфликтах, руководствуясь интересами успешного продукта.

Навыки

Hard skills:
• Понимание современных технологий.
• Знание предметной области.
• Работа с требованиями (выявление, анализ, документирование).
• Моделирование бизнес-процессов.
• Проектирование интерфейсов.
• Навыки решения проблем.
• Грамотная речь и работа с текстами.

Soft skills:
• Аналитические способности и системное мышление.
• Коммуникативность и умение вести переговоры.
• Ответственность и проактивность.
• Широкий кругозор.

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

Выводы

1. Бизнес-аналитик участвует на всех стадиях жизненного цикла продукта, от формулирования идеи до передачи в эксплуатацию и сопровождения.
2. Работа начинается с определения концепции и экономической целесообразности продукта, на этом этапе может быть принято решение о нецелесообразности запуска.
3. Сбор требований требует баланса между пожеланиями заказчика и потребностями пользователей, а его практическим итогом становится MVP — минимально жизнеспособный продукт.
4. При анализе требований применяется принцип Парето: 20% функций закрывают 80% сценариев использования, что позволяет оптимизировать бюджет и сроки.
5. Проектирование завершается созданием технического задания, которое служит эталоном поведения продукта и может дополняться в следующих циклах разработки.
6. Одна из центральных задач — не борьба с симптомами, а поиск и устранение коренной причины проблем.
7. Ключевой критерий успеха — реальное улучшение бизнес-показателей, а не сам факт внедрения ИТ-системы.
8. Креативный подход и кастомизация решений важнее бездумного копирования шаблонов, даже несмотря на кажущуюся простоту последних.
9. Бизнес-процессы первичны по отношению к внедряемой системе: недопустимо деформировать бизнес под коробочный функционал.
10. Быстрый вывод продукта в эксплуатацию выявляет скрытые проблемы, которые невозможно обнаружить на стадии разработки, и ускоряет общее улучшение.
11. Переговоры и постоянное взаимодействие с заказчиком — центральный элемент успеха, позволяющий конвертировать бизнес-пожелания в реализуемые технические требования.
12. Бизнес-аналитик сочетает широкий спектр компетенций: от технической грамотности и работы с требованиями до коммуникабельности, проактивности и системного мышления.

Вопросы для самопроверки

1. Какие четыре этапа деятельности бизнес-аналитика выделены в лекции и чем завершается каждый из них?
2. Почему определение концепции продукта может закончиться решением не запускать его в разработку?
3. Как принцип Парето помогает сформировать минимально жизнеспособный продукт (MVP)?
4. В чем различие между работой с симптомами и поиском коренных причин? Приведите пример, соответствующий описанной аналогии.
5. Что означает принцип «Улучшаем бизнес, а не просто внедряем ИТ-системы» и как его применить на практике?
6. Почему креативная кастомизация решений предпочтительнее простого копирования шаблонов, несмотря на риски?
7. Объясните, почему переговоры названы центральным элементом успеха при взаимодействии заказчика и исполнителя.
8. Как бизнес-аналитик должен действовать, если заказчик не может четко сформулировать свои требования?
9. Какие факторы должен проанализировать бизнес-аналитик, когда поступает новое требование посреди разработки?
10. Перечислите не менее пяти групп стейкхолдеров, с которыми взаимодействует бизнес-аналитик.
11. В чем состоит роль арбитра у бизнес-аналитика при конфликтах внутри команды исполнителей?
12. Какие hard skills и soft skills формируют портрет компетентного бизнес-аналитика?
Вернуться к учебному плану