Валерий Комсков: Введение в профессию бизнес-аналитика

© Комсков В.В., текст, 2025

© Оформление. ООО «Издательство «Эксмо», 2025

От автора

В книгах вроде «“Название профессии” пособие для начинающих» обычно много написано о том, как долго автор к ней шел, сколько статей написал, в каком университете преподавал и т. д. Так вот, ничего подобного у меня не было. Два года назад я не только не планировал, что буду писать эту книгу, но даже и не думал об этом. Но так получилось, что ко мне обратились две очаровательные девушки с просьбой научить их бизнес-анализу, поскольку на тот момент я был старшим бизнес-аналитиком нефтяной компании «Роснефть» и имел большой опыт работы в профессии в российских и зарубежной компаниях. По итогу я все зафейлил, собрав все преподавательские грабли, какие только было можно. Выяснилось, что нормальной литературы по профессии просто нет: она или в общих чертах рассказывает о том, чем занимаются бизнес-аналитики, какими они бывают и т. п., или рассчитана на тех, кто уже работает в этой области и понимает, что конкретно изучает этот специалист. Девушки, которые попросили меня научить их бизнес-анализу, были не только очаровательными, они оказались еще и крутыми преподавателями в своих сферах, причем со знанием и опытом не только из отечественного высшего образования. Поэтому родилась мысль исправить эту ситуацию, написав книгу и создав курс «Бизнес-аналитик». За время написания я успел побывать руководителем команд, которые разрабатывали и сопровождали несколько информационных систем федерального значения, и запустить собственный стартап в сфере финтеха. Это позволило добавить в книгу информацию по hard и soft skills, которые я ожидал увидеть от кандидатов на позицию бизнес-аналитика уровня джуниор. По возможности развернуто я разобрал проблемы, возникающие у новых сотрудников при вводе их в должности.

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

Благодарности

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

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

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

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

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

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

С уважением, Валерий Комсков

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

«…если бы среди философов установилось согласие относительно значения слов, то почти все их споры были бы прекращены»

Рене Декарт, XVII век

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

Но даже если мы возьмем конкретно бизнес-аналитиков, то выяснится, что есть два их вида:

• обычный (не IT) бизнес-аналитик – тот, кто работает в контексте бизнеса в целом. Такой специалист участвует в совершенствовании процессов, оптимизации издержек и т. д;

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

При этом IT – крайне снобистская сфера, и за пределами крупных корпораций о бизнес-аналитиках не из IT обычно никто не знает.

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

Я сознательно крайне путано написал эту главу, чтобы вы увидели атмосферу, в которой вам придется работать. Бизнес-аналитик – это не та профессия, в которой четко сказано, что «нужно копать отсюда и досюда». Вы постоянно будете сталкиваться с требованиями, которые зачастую противоречат не только друг другу, но и здравому смыслу, заказчики сами не будут знать, чего хотят, а вы нередко не будете знать, осуществимы ли в реальности их желания. Но вместе с тем бизнес-аналитик – одна из самых «инженерных» профессий, ибо все остальные члены команды реализуют то, что вы придумали и написали/нарисовали.

Говорят, девизом IBM в стародавние времена было утверждение: «мы продаем нашим заказчикам не то, что они хотят, а то, что им нужно». Уж не знаю, насколько это правда, но формулировка весьма показательна. Со временем, когда вы наберетесь опыта, вам нужно будет следовать этому девизу.

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

Основы разработки ПО

Роли в команде

Менеджер проекта (Project manager)

Проект – это временное предприятие, направленное на создание уникального продукта, услуги или результата.

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

Менеджер релизов – в реалиях российских Enterprise-компаний так называются руководители команд, управляющие процессом, когда IT-продукт из проекта уже превратился в сервис, но находится на доработке согласно запросам на изменения (ЗИ).

Менеджер продукта (Product manager)

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

Эти роли различаются тем, что product manager придумывает новые функции, которые можно добавить в продукт, а project manager ставит задачу подчиненным реализовать эти новые функции и сообщает о сроках, когда они будут готовы. Product manager решает, что сделать, project manager – когда и как.

Архитектор (Architect)

Архитектура ИС – это набор структурных элементов, организованных определенными способами для взаимодействия друг с другом, которые складываются в единый программно-аппаратный комплекс. Он выстроен для достижения конкретных бизнес-целей.

Архитектура – понятие глобальное, его можно разделить на несколько частей, переходя от общего к частному. В работе аналитика встречаются следующие виды «архитектур».

Архитектура предприятия / корпоративная архитектура (Enterprise Architecture) – высокоуровневая архитектура всего предприятия, покрывающая бизнес-потребности IT-способностями. Корпоративная архитектура фокусируется на определении потоков и бизнес-процессов, действий, функций, информации, данных и технологий предприятия, а также на вызовах, стоящих перед IT и необходимых для того, чтобы эффективно применить технологию в ответ на изменение бизнес-потребностей.

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

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

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

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

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

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

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

Каждым из видов архитектуры занимается соответствующий архитектор.

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

Архитектор решений (Solution Architect). Если EA решает, что делать, то SA – как делать.