Когда с головой уходишь в свои задачи, порой, не знаешь, что каждый день делает коллега за столом справа. Чтобы исправить эту ситуацию, будем разбираться с профессиями в IT. С девелоперами и тестировщиками понятно, они продукт создают. PM — спорный персонаж, но есть почти в каждой команде, так что с какими вопросами к нему идти все уже разобрались.
А вот зачем нужен человек с модной профессией Business Analyst (BA), никто почему-то не понимает. Со стороны может показаться, что он целый день пишет документацию и, порой, отнимает много времени, обсуждая какие-то решения с командой. Чем занимается бизнес-аналитик, если уже есть PM и технический писатель?
Кто такой бизнес-аналитик — очередная прослойка менеджмента или лучший друг разработчика? Объясним в этой статье.
Кто такой бизнес-аналитик
Бизнес-аналитик — это человек, который стоит между бизнесом и командой разработки. Он собирает и выявляет требования к будущему продукту или функциям системы, а затем переводит их на понятный для инженеров язык.
Обязанности BA в команде могут варьироваться, но на всех проектах и во всех вакансиях бизнес-аналитика указаны 4 основные функции.
- Управление требованиями: их выявление, подготовка и детализация, разделение запросов на требования и «какие-то не очень важные хотелки».
- Стратегический анализ: во многих компаниях BA вместе с ТОП-менеджментом работает над стратегией развития компании и проекта, поскольку знает продукт лучше всего.
- Проектирование решений: подготовка документации и, порой, создание прототипов. Все, чтобы придумать и донести до команды, каким образом решения будут разработаны и имплементированы.
- Управление продуктом: коммуникация с дизайнерами, инженерами, стейкхолдерами, бизнесом и 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?
Если после прочтения статьи вам показалось, что бизнес-анализ может стать следующей ступенью вашего карьерного роста — это хорошая идея. Даже если после обучения вы передумаете менять работу, знания бизнес-анализа существенно повысят вашу стоимость на рынке.
Чтобы вырасти в бизнес-аналитика, нужно:
- Понять роль бизнес-аналитика в своей компании, так как задачи от проекта к проекту могут сильно отличаться.
- Определить свои текущие компетенции и сравнить с матрицей компетенций BA. Иногда, одна компетенция (к примеру, хороший английский) может стать решающей.
- Выделить недостающие компетенции и пройти по ним обучение.
- Овладеть основными техниками и методиками BA. Внедрять полученные техники в работу и отслеживать результаты.
- Подать резюме на junior позицию с сопроводительным письмом. Важно написать, почему вы хотите работать в этой компании и почему они должны вас взять: что вы для этого сделали, какие курсы прошли и что умеете. Не бойтесь вместе с резюме подавать тестовые проекты, которые делали в процессе обучения — они станут отличным примером вашей первой работы.
Кому-то рабочий день бизнес-аналитика покажется скучноватым, кто-то решит, что это — работа мечты (спокойней, чем у проектных менеджеров, но, все равно много коммуникации и влияния на результат). В любом случае, знания бизнес-анализа с каждым днем становятся все более востребованными на рынке, поэтому, если вы хотите развиваться в IT, стоит прокачаться в работе с требованиями.