Что такое бизнес-анализ. Разрушаем мифы о работе BA

Статья написана в соавторстве с Мэри Ротарь, CEO IAMPM.

Привет, меня зовут Кирилл Белявский. Сейчас я Lead Business Analyst, а 6 лет назад пришел в бизнес-анализ с широко открытыми глазами и собственными заблуждениями относительно роли ВА в IT. До этого я долго работал в финансовой сфере, занимался бюджетированием строительных проектов и финансовым анализом в крупной металлургической компании. Позже оптимизировал процессы в той же компании, курировал небольшие внутренние IT-проекты. У меня был хороший английский, я хотел получить интересную практику разных проектов, поэтому перешел в IT бизнес-анализ.

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

Миф 1. Бизнес-анализ — это просто

В бизнес-аналитику люди приходят в основном двумя путями. Первый — когда специалист внутри IT-компании решает сменить деятельность. Чаще всего так поступают тестировщики, которые рассматривают бизнес-анализ как перспективное карьерное направление.

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

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

Какие сложности возникают в работе ВА

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

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

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

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

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

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

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

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

Приходится часто отказывать. Бизнес-аналитик должен уметь говорить «нет», потому что на работе будет много просьб, предложений и прочих вещей от каждой стороны общения:

• девелоперы просят что-то поменять в требованиях, чтобы им было проще разрабатывать;
• тестировщики настаивают на проведении дополнительных тестов;
• клиент требует взять незапланированные задачи в спринт.

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

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

Миф 2. Все понимают, чем занимается бизнес-аналитик

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

Как проявляется непонимание:

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

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

Как работать с ожиданиями

Задавайте вопросы. На этапе рассмотрения вакансии либо на собеседовании как можно больше спрашивайте, чтобы понять ожидания от позиции ВА в компании. Зачем вам бизнес-аналитик? Что вы от него ожидаете? Как вы будете измерять успешность ВА на проекте?

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

Выясните ожидания РМ’а. Если вы уже работаете в компании и идете на какой-то проект, там тоже есть конкретные ожидания, в зависимости от продукта, клиента, команды, методологии. Прояснить их лучше всего через разговор с РМ’ом. Попросите его выделить 20 минут времени и сформулировать ожидания роли ВА. Желательно тезисно в записях: на бумаге или доске, где угодно.

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

Поработайте с ожиданиями. Когда поймете, чего от вас ждут, и сравните с вашим собственным пониманием, создайте правильные ожидания у команды и клиента. По-хорошему это должен сделать РМ, но иногда он может забыть или не успеть, ситуации бывают разные. Поэтому не стесняйтесь представиться самостоятельно. Можно попросить 15 минут на командном митинге и сказать: «Ребята, всем привет, я хотел бы пару слов рассказать о своей роли, чем я здесь буду заниматься».

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

Миф 3. Клиент знает, чего хочет

Клиент может формулировать решение примерно так: «Мне нужен Uber, только не совсем, который работает как Facebook, но для аграрного бизнеса».

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

Если клиент не очень разбирается в IT, ему бывает трудно правильно сформулировать запрос, поэтому заказчик пытается превратить свои мысли в какую-то форму знакомых ему приложений. Может, в Uber ему нравится дизайн, а в Facebook — звук входящего сообщения.

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

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

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

Миф 4. Клиент понимает, как устроена разработка

Часто клиенты из разных доменов приходят к нам, профессионалам в области IT, потому что их бизнес нуждается в digital-трансформации. Такие заказчики далеко не всегда понимают, как происходит разработка или как устроен SDLC.

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

Клиент рассуждал так: «Система работает у меня, значит я могу скопировать ее на компьютер для другой организации. И она мне за это заплатит деньги».

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

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

Миф 5. Писать User Story просто

Казалось бы, что тут сложного: написать «Я как пользователь хочу, чтобы там что-то было, чтобы из этого получить для себя value и какой-то набор критериев».

Моя первая User Story звучала так: «Я как пользователь хочу видеть данные про пациентов из одной системы в другой системе, чтобы я мог пользоваться этими данными в двух системах».

Я искренне не понимал, чего от меня еще хотят: работа сделана, User Story написана, я пошел пить кофе. Оказалось, не все так просто. Конечно, теперь я пишу требования чуть-чуть лучше, но все еще не могу сделать идеальную User Story, понятную абсолютно всем и не вызывающую вопросов.

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

Поделюсь, каким подходом я пользуюсь при работе с User Story:

1. Самое главное — понять business need, что эта функциональность должна закрыть для бизнеса, через какие функции приложения и какие действия пользователей с этим приложением.
2. Пишу основные критерии приемки (Acceptance Criteria), базово, особо не заморачиваясь о каких-то нюансах, не тратя времени на детальное продумывание.
3. Иду к команде, представляю User Story в черновом виде, получаю набор вопросов, предложений, дополнений. Conversation — это тоже важная часть работы над историей.
4. После разговора с командой я уже могу добавить подробностей. Я не трачу на старте время, чтобы написать что-то близкое к идеалу и только потом пойти к команде. Я пишу базовые вещи, сразу иду к ребятам и выслушиваю много предложений, вопросов, критики. После разговора у меня появляются основные критерии, понятные для разработчиков, потому что частично эти критерии исходят от них самих.

Дальше можно прояснить непонятные моменты с клиентом либо сделать review, но основной совет — не тратить слишком много времени на попытку написать идеальную User Story с самого начала.

Миф 6. Требования читают внимательно

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

Сейчас мы используем для работы с требованиями критерий definition of ready. Многие знают definition of done — показатели, по которым видно, что задача выполнена. Definition of ready показывают, что требования готовы к разработке:

• Requirements finalized — требования написаны, на все вопросы отвечено. Если приложение требует дизайна, то дизайн тоже закончен к этому моменту.
• Команда вместе с ВА проговорила и распределила бэкенд и фронтенд: какая работа нужна и кто что будет делать.
• Прописано, нужен рефакторинг или нет, потому что часто о нем забывают, а потом оказывается, что рефакторинг таки нужен. И это увеличивает эстимейт и усложняет User Story.
• Выяснили, как должны работать права доступа пользователей.
• Посмотрели, как требование повлияет на исторические данные, это актуально для приложений с какой-то историей работы, когда уже созданы информационные объекты, сущности, связи между ними. Исторические данные должны тоже поменяться либо остаться нетронутыми?
• Разработчики оценили наличие инфраструктурных changes.

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

Вместо вывода

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

Задача бизнеса — объяснить цели, заплатить деньги и получить результат. Лучший эксперт в своем домене — это сам клиент, а от ВА бизнес ожидает максимальной отдачи и ответственности за итог работы.