Бизнес-анализ от а до я: гид для начинающих

Второй момент, который хочу поделиться – я считаю, что есть такой навык, который можно назвать «создатель решений». Это не официальная роль или должность, а скорее навык, который формируется, когда вы, как БА, регулярно создаете решения различного масштаба. За последние 10 лет у меня накопился личностный набор характеристик и навыков, которые образуют этот увлекательный навык. Может показаться чрезмерно оптимистичным, но без оптимизма любая работа может превратиться в скуку и недовольство!

Внешние мотиваторы: как мир влияет на мою мотивацию?

Информатизация всего – особенно это ощущается сейчас, после того как человечество пережило ковид. Множество компаний, которые ранее уделяли мало внимания ИТ-проектам, теперь открывают департаменты и нанимают большие команды подрядчиков и сервисных компаний, чтобы автоматизировать, улучшить и цифровизировать все свои процессы, сервисы и продукты. Это, естественно, влияет на спрос на специалистов, и я вижу, что профессия БА сейчас очень востребована, хотя 8-10 лет назад многие клиенты даже не понимали, зачем нужны эти БА в командах по поставке решений. Осознание того, что БА востребованы в мире, конечно же, добавляет мотивации работать или стремиться работать в этой перспективной профессии.

Увеличение масштабов решений и требований к их качеству – с развитием ИТ-технологий, таких как 'облачные' решения, машинное обучение, 'большие данные' и аналитика, масштабы ИТ-решений у клиентов растут, и, соответственно, увеличивается процент возникновения дефектов. Бизнес-аналитики являются одними из ключевых участников проектных ИТ-команд, влияющих на качество решений. Это заметный мотиватор, особенно в сервисной компании, где я работаю. Когда я вижу проекты с 4-7 командами (20-40 человек), где набирают по 4-5 БА, клиенты и поставщики решений понимают, что каждая даже небольшая команда должна иметь БА, который полностью готовит требования и управляет их жизненным циклом для каждой части решения.

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

Давайте рассмотрим спрос на профессию бизнес-аналитика, опираясь на данные, которые я нашёл в LinkedIn. Я не буду приводить актуальную статистику текущего года, так как читатель может самостоятельно это проверить. Однако, в качестве примера, возьмем статистику за 2019 год, где уже был виден значительный спрос на эту профессию.

Примечание автора: данные на английском языке. Перевод:

Software engineer – Инженер-программист

Project manager – Руководитель проекта

Business analyst/ Data analyst – Бизнес аналитик / Дата аналитик

Solution Architect – Архитектор решений

UX Designer – Дизайнер Пользовательского опыта

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

Примечание автора: данные на английском языке. Перевод:

The Skill Companies Need Most in 2020 – Навыки компании нуждаются больше всего в 2020 году.

Top 10 Hard Skills – Топ 10 “жёстких” навыков.

Business analysis – Бизнес анализ.

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

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

Вторая история о том, как может выглядеть начало карьерного пути БА

Как обычно, начну с вводной части, описывающей, что и как будет происходить в этой истории. С точки зрения описания навыков обычного бизнес-аналитика, эта история будет содержать основное описание. Поэтому, я добавлю дополнительный уровень структуризации и декомпозиции описательной части внутри истории – шаги. Теперь у нас есть главы, внутри которых располагаются истории, и внутри историй – шаги как базовые элементы движения вперед. В этой истории шаги будут отражать моё поэтапное развитие как ИТ-бизнес-аналитика на уровне обычного регулярного БА.

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

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

Будет представлено четыре шага, чтобы равномерно распределить смысловую нагрузку:

– Первый шаг: Я опишу свой старт как БА в своей первой ИТ-компании, о чем я кратко уже упоминал в предыдущей истории. В это время я работал в роли помощника опытного БА, создавая небольшие фрагменты требований.

– Второй шаг: Здесь я расскажу о периоде, когда я уже 'набил руку' в работе с требованиями и начал действовать как самостоятельный БА, способный описывать и управлять требованиями по определенной функции системы.

– Третий шаг: В этом этапе я увеличил масштаб своей работы до уровня компонентов системы.

– Четвертый шаг: На этом этапе я уже работал как product owner, ответственный за компонент системы.

Если говорить о временных рамках моего становления как регулярного БА, то это примерно 1.5 года, с марта 2013 года до конца 2014 года. Затем последовал период, когда я еще не был официально старшим БА, но уже выполнял его функции. Это продолжалось еще 4-6 месяцев до второй половины 2015 года. Таким образом, мне потребовалось около двух лет, чтобы стать хорошим начинающим старшим БА или просто отличным БА.

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

Теперь немного о уровнях в рамках позиции 'регулярный БА'. Первый и второй шаги я отнес к первому уровню БА, который я бы описал как 'стабильный и уверенный создатель требований'. Регулярный БА на этом уровне может свободно определить и задокументировать требования к конкретной функции системы – это его основная задача и требование к уровню. Я намеренно привязал два шага развития к этому уровню, поскольку на начальном этапе карьеры БА важно сосредоточиться на ключевом навыке – умении 'правильно' задокументировать требования. Что значит 'правильно', я объясню подробнее в описании этих шагов 1 и 2.

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

Третий уровень отражает уже зрелого регулярного бизнес-аналитика, который, возможно, уже частично выполняет обязанности старшего БА и готов к переходу на новую позицию или должность. Такой аналитик работает также как владелец компонента системы. Он понимает и может заниматься оценкой своих времени и трудозатрат, а также знает, как оценки проводятся на уровне проекта. Этот аналитик разбирается в плюсах и минусах различных методологий, является доверенным лицом проектной команды и клиентов. Кроме того, такой БА хорошо разбирается в подходах к выявлению требований, включая знания о фазе discovery, умеет адаптироваться к изменениям в требованиях и эффективно планировать своё рабочее время в соответствии с приоритетами задач. Уточню очень кратко термин 'Дискавери фаза' (Discovery phase), так как я буду использовать его довольно часто, хотя подробно мы коснемся этого только в конце книги. Простыми словами, Дискавери фаза – это обычно активность в специально выделенный временной промежуток для выявления самых первоначальных целей проекта или продукта, требований и границ планируемого решения. Это, как правило, самый первый этап любого проекта или продукта.

Зачем я написал про эти уровни внутри регулярного БА? Для меня важно показать с помощью этого относительного подхода к их определению, что нельзя просто рассматривать кого-то как обычного БА с конкретным набором навыков и опыта. Мы должны понимать, что уровни владения и виды навыков могут быть различны. Я использую 'относительный подход', потому что каждый может выбрать собственный способ разделения, и это всего лишь один из возможных вариантов. Один БА может только начинать писать качественные требования, в то время как другой уже полностью управляет жизненным циклом требований для конкретного компонента и фактически является почти старшим БА.

Итак, я описал, о чем будет эта история, из чего она будет состоять, и как я понимаю подуровни регулярного БА. Теперь мы погрузимся в самое главное и полезное – это те навыки, которые использует бизнес-аналитик. Единственное, что осталось уточнить перед этим – это определение навыка, типы навыков, связанные с ними активности и масштаб их использования в контексте бизнес-анализа.

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

Существует несколько типов навыков. В контексте бизнес-анализа мы в основном используем два типа: Hard skills (жесткие навыки) и Soft skills (мягкие навыки).

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

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

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

Шаг 1 – начинающий БА

Мой путь в профессии бизнес-аналитика начался в марте 2013 года, когда я устроился в свою первую ИТ-компанию NetCracker, занимающуюся разработкой ИТ-продуктов для телекоммуникационных провайдеров. Сразу после присоединения к компании, я был включен в команду, создающую многокомпонентную систему поддержки бизнеса клиента. Благодаря моему опыту как конечного пользователя в области операционных систем и управления взаимоотношениями с клиентами (CRM), я начал работу над соответствующим компонентом под руководством ведущего бизнес-аналитика, который уже некоторое время занимался этим компонентом.

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

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

Мы регулярно проверяли прогресс моих задач – иногда один-два раза в день, но обязательно на следующий день. Это важный принцип, который я по-прежнему использую в своей работе: никогда не ждать финального результата задачи для проверки качества. Обязательно нужно проводить промежуточные проверки, чтобы своевременно определить отклонения от ожидаемого результата, обсудить их и внести коррективы. Чем позже обнаруживается отклонение, тем дороже обходится его исправление – 'дороже' в любом смысле: в деньгах, времени, ресурсах.

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

Мой рабочий день был разделен на две основные активности: коммуникация с ведущим БА и работа с требованиями. Также была третья дополнительная активность – изучение систем и стандартов компании и продукта, которой я занимался лишь эпизодически, и в основном в контексте текущих проектных задач. Я последовательно придерживаюсь одного подхода на протяжении последних десяти лет – приоритет отдаю реальным задачам, переходя к изучению нового только после того, как уверен в выполнении всех своих обязанностей в срок.

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

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

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

Первым делом я всегда проверяю свой ежедневник, где перечислены все текущие задачи и их статусы. Мониторинг и планирование задач – это ключевой инструмент эффективной работы и управления временем. Я осматриваю задачи, требующие внимания, и определяю, какой из них я займусь в первую очередь. Проверяю наличие потенциальных препятствий или блокеров для выбранной задачи, которые могут требовать вмешательства других лиц. Если такие препятствия существуют, я стараюсь запланировать обсуждение с моим БА в удобное для него время. Я делаю это сразу, не откладывая до тех пор, пока не столкнусь с трудностями из-за блокирующих задач. Эффективное планирование звонков и ключевых активностей занимает всего 5-15 минут, но позволяет мне спокойно работать дальше, зная, что важное совещание уже запланировано

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

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

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

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

Перед тем как подробно описать, что такое 'документирование дизайна функционального требования', я кратко определю, что такое функциональное требование. Не углубляясь в технические детали, которые будут подробно разобраны в конце этого раздела, функциональное требование – это определенное свойство системы, позволяющее удовлетворять запросы пользователя. В большинстве случаев под 'пользователем' мы подразумеваем живого человека, который взаимодействует с нашей системой. Существуют, конечно, специфические технические проекты, где 'пользователем' может быть другая система или модуль системы, использующий функции другой системы, но эти сценарии мы пока рассматривать не будем. Когда пользователь взаимодействует с системой, она реагирует на его запросы и действия определённым образом. Ожидания от реакции системы на использование определённой функции и называются функциональным требованием. Поскольку сначала создаётся система, а затем пользователь начинает пользоваться её функциями, мы называем это функциональным требованием. Это требование к тому, как должна работать функция системы, иначе система не будет нужна пользователю, если она не соответствует его функциональным требованиям.

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

Почему акцент на документировании дизайна? Всё просто. Основная цель бизнес-аналитика почти всегда заключается в подготовке документа или артефакта для команды разработчиков, чтобы они могли создать систему именно так, как её планирует использовать пользователь. Наличие только функционального требования без дизайна не даст разработчикам необходимой информации о том, что именно нужно создать. В моей 10-летней практике я не встречал случаев, когда было бы иначе. Хотя в интернете можно найти мнения, что в рамках некоторых 'гибких' методологий разработки, продукты создаются именно так – разработчикам передаётся только требование, и они каким-то образом создают то, что нужно.

Процесс документирования дизайна может занимать различное время и объем работы. Одно требование может быть оформлено на полстраницы формата А4 и занять 30 минут для написания. Другое требование может распространяться на 10 страниц и требовать неделю работы. Существуют различные форматы и подходы к дизайну, выбор которых зависит от множества факторов и контекста проекта. В эти дни и недели такая активность занимает примерно 80 процентов моего рабочего времени.

Я документировал дизайн простым и надежным способом – в обычном текстовом документе (MS Word). Никаких специальных дополнительных программ не требовалось. Этот документ был доступен онлайн для моего ментора, который проверял мои дизайны и оставлял комментарии прямо в файле, на которые я затем делал правки. Это был непрерывный процесс документирования, комментирования от ментора и соответствующих обновлений с моей стороны.

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

Скучно ли это – создавать дизайн требований с утра до вечера, неделями? Для меня это было чрезвычайно интересно, так как а) я создавал! Это один из главных двигателей моей удовлетворенности от работы, и я буду часто это повторять на протяжении книги. Ощущение, что ты что-то создаешь, невероятно приятно. Важно прослеживать, даже если только в своем воображении, как твоя деятельность влияет на финальный итог. Допустим, я описал обычную кнопку, которая активирует функцию в системе. Я представляю, как после разработки и тестирования, эту систему предоставят клиенту, который в свою очередь сделает её доступной своим пользователям. Пользователи, например, продавцы в магазине, будут использовать функцию, созданную по моему дизайну, для обслуживания клиентов. Хоть это и ИТ система, программа, но в 99% случаев они нужны для внедрения в бизнес-процессы, а это значит, что я упрощаю повседневную жизнь кого-то.