Как проходит день бизнес-аналитика

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

А вот зачем нужен человек с модной профессией Business Analyst (BA), никто почему-то не понимает. Со стороны может показаться, что он целый день пишет документацию и, порой, отнимает много времени, обсуждая какие-то решения с командой. Чем занимается бизнес-аналитик, если уже есть PM и технический писатель?

Кто такой бизнес-аналитик — очередная прослойка менеджмента или лучший друг разработчика? Объясним в этой статье.

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

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

Навыки бизнес-аналитика

Обязанности BA в команде могут варьироваться, но на всех проектах и во всех вакансиях бизнес-аналитика указаны 4 основные функции.

  1. Управление требованиями: их выявление, подготовка и детализация, разделение запросов на требования и «какие-то не очень важные хотелки».
  2. Стратегический анализ: во многих компаниях BA вместе с ТОП-менеджментом работает над стратегией развития компании и проекта, поскольку знает продукт лучше всего.
  3. Проектирование решений: подготовка документации и, порой, создание прототипов. Все, чтобы придумать и донести до команды, каким образом решения будут разработаны и имплементированы.
  4. Управление продуктом: коммуникация с дизайнерами, инженерами, стейкхолдерами, бизнесом и Product Owner-ами.

 

Зачем нужен бизнес-аналитик

Представьте ситуацию, заказчик присылает разработчику ссылку на конкурентов и говорит: «Мне нужен сайт! Точь в точь, как вот этот!» Программист: « Я не понимаю, что значит “точь в точь”, дайте ТЗ, меньше придется переделывать».

Заказчик идет к своему другу, по совместительству бизнес-аналитику, пожаловаться на программиста. Далее диалог между заказчиком и бизнес-аналитиком.

Заказчик: Вот ты мне скажи, ЧТО ТУТ НЕПОНЯТНОГО? Взять и сделать точно такой же сайт, неужели так сложно повторить?
Бизнес-аналитик (грустным голосом): Ну, вообще-то, я на стороне программиста. Непонятно в твоем запросе совершенно все. Сейчас докажу. Давай вместе посмотрим, что именно тебе нравится в этом сайте. Здесь есть кнопка «Сравнить», она тебе нужна?
Заказчик: Нет, не нужна.
Бизнес-аналитик: У этих ребят на сайте отдельная страница для доставки и еще одна — для оплаты, тебе точно нужно 2 верстать, или можно доставку и оплату объединить в одну страницу?
Заказчик: Можно совместить, мне и правда 2 страницы нечем заполнять.
Бизнес-аналитик: Видишь, уже получается не точь в точь, правда?
Заказчик: Я, наверное, имел в виду скорее визуальное оформление.
Бизнес-аналитик: А программист говорил о функционале.

Заказчик недовольный проектом

Этот кейс показывает, насколько по-разному можно рассматривать один и тот же продукт (в данном случае сайт). Выходит, BA — тот человек, который может спасти проект от «сделали, но не то». Поэтому привлекать бизнес-аналитика лучше до того, как команда столкнется с проблемами в коммуникациях с заказчиком.

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

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

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

Постойте, но это больше похоже на работу Project Manager-а, разве нет?
В каком-то смысле так и есть. Не во всех компаниях выделены отдельные люди на обе роли, а с требованиями работать нужно в любом случае. Однако, в средних и больших проектах и у бизнес-аналитика, и у PM-а работы хватает на целый день (еще и с овертаймами).

Один день бизнес-аналитика в IT

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

10:00 — 12:00 Помощь команде

Поддержка команды бизнес-аналитиком

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

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

BA организовывает митинг, на котором поясняет команде изначальную бизнес-потребность, и спрашивает, может ли команда предложить решение, которое займет меньшее количество времени и ресурсов. Если оптимальное решение находится, то бизнес-аналитик изменяет требования. Нет — самое время «порадовать» клиента новостью.

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

Что важно при работе с командами:

  • Быть на связи чуть ли не 24/7.
  • Фокусироваться на решении проблемы: выяснить, в чем суть, перевести разговор в позитивно-контструктивное русло и предложить альтернативное решение.
  • Эскалировать проблемы вовремя: не стараться все решить самостоятельно.
  • Проговаривать сложности, с которыми может столкнуться проект в случае изменений. Вовремя уведомлять стейкхолдеров.

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

12:00 — 14:00 Написание документации

Написание документации бизнес-аналитиком

У документации есть один минус: если она слишком большая, ее никто не читает.

Что делает бизнес-аналитик на этом этапе:

  • Создает спецификации.
  • Описывает user stories / acceptance criteria / use cases.
  • Формулирует нефункциональных требования — описывает условия, в которых система эффективна. Например: «Система должна быть отказоустойчивой и совместимой с Google Chrome…».
  • Моделирует бизнес-процессы.
  • Прототипирует решения.

Что важно при написании спецификаций:

  • Заранее определить необходимые артефакты.
  • Описывать требования ДОСТАТОЧНО детально: ни больше, ни меньше.
  • Понимать принципы usability.
  • Придерживаться нотаций в работе с диаграммами.

 

14:00 — 15:00 Обед

Бизнес-аналитик обедает

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

15:00 — 18:00 Коммуникация с клиентом

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

Рабочие совещания — это те встречи, на которых можно не просто узнать о требованиях, но и докопаться до истинной потребности клиента. Другими словами, ответить на вопрос «зачем нам это нужно?» и подумать, действительно ли решение оптимальное, или есть еще варианты. Чтобы общаться с заказчиком на одном языке, нужно разбираться в предметной области бизнеса.

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

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

18:00 — 19:00 Консультации с тех лидами

Коммуникации бизнес-аналитика

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

Из кого получается хороший BA

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

Роль BA в компании могут выполнять разные специалисты.

Sales Manager Специалист по продажам — первый, кто начинает выявлять требования и понимать, что же хочет клиент. Опытные сейлзы прокачивают необходимые навыки BA, чтобы грамотно собрать первую информацию о предполагаемом продукте.
Account Manager Аккаунт менеджер знает много о продукте и пожеланиях клиента, так что может сориентировать заказчика, куда развиваться.
Product / Project Manager В рамках работы PM-ам приходится доносить требования до команды и управлять ими, поэтому на более-менее серьезном проекте не обойтись без знаний бизнес-анализа.
Тим лид или самый опытный разработчик Девелопер может выполнять роль BA, если заказчик обладает хоть какой-то технической компетенцией. Эта модель чаще всего встречается в аутсорсинге.
QA инженер Тестировщик понимает, что именно команда должна разрабатывать. В ходе тестирования QA составляет тест-кейсы и эти кейсы — чуть ли не единственная документация, по которой работает команда в отсутствие BA. Это не лучшая практика, но, тем не менее, она имеет место быть. Кстати, QA-специалистам достаточно нескольких месяцев, чтобы освоить дополнительные техники необходимые для BA и уйти в бизнес-аналитику.
UI / UX дизайнер Дизайнеры много коммуницируют с клиентами и работают с обратной связью. Они могут рассказать команде, что и как должно работать. Поскольку дизайнер не разбирается в разработке, роль BA на таких проектах делится между дизайнером и командой.
Scrum master, Scrum team Если команда работает по модели Agile, эти специалисты могут брать на себя роль BA.

 

Как стать BA?

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

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

Чтобы вырасти в бизнес-аналитика, нужно:

  1. Понять роль бизнес-аналитика в своей компании, так как задачи от проекта к проекту могут сильно отличаться.
  2. Определить свои текущие компетенции и сравнить с матрицей компетенций BA. Иногда, одна компетенция (к примеру, хороший английский) может стать решающей.
  3. Выделить недостающие компетенции и пройти по ним обучение.
  4. Овладеть основными техниками и методиками BA. Внедрять полученные техники в работу и отслеживать результаты.
  5. Подать резюме на junior позицию с сопроводительным письмом. Важно написать, почему вы хотите работать в этой компании и почему они должны вас взять: что вы для этого сделали, какие курсы прошли и что умеете. Не бойтесь вместе с резюме подавать тестовые проекты, которые делали в процессе обучения — они станут отличным примером вашей первой работы.

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