Что-то на айтишном: бизнес-аналитик

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

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

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

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

Популярные термины бизнес-аналитика

• «Сторя» (user story) — это пользовательская история, которая включает в себя описание функций продукта, желательно на простом и понятном языке. Она имеет определенный формат и должна соответствовать общепринятому набору критериев. Пример одного из критериев — это избежание двусмысленности. Одна и та же «сторя» должна восприниматься и быть понята разным людям одинаково. User story состоит из двух частей: основной части и acceptance критериев (критериев приемки). Основная часть — это структурное описание желаний пользователя. К acceptance критериям относятся условия, которым должен соответствовать продукт, чтобы быть принятым пользователем. Мы думаем не только о том, что пользователь может сделать, но и зачем ему это надо. Бизнес-аналитик следит за тем, чтобы разработка (разрабатываемая фича) была нужна и бизнесу, и пользователю. Одна из задач бизнес-аналитика — контролировать то, что уходит в разработку. Оно должно соответствовать бизнес-целям и пользовательским потребностям, не выходить за пределы скоупа (объем работ, которые нужно выполнить для достижения целей проекта) и решать проблему. Если к тебе приходит заказчик и говорит — хочу, чтобы у меня по сайту летал самолетик из левого в правый угол, нужно узнать, зачем, какую бизнес-цель он покрывает, какую пользовательскую потребность закрывает. В какой-то степени бизнес-аналитик — это вечно строгий человек, который все время задает много вопросов. Подробнее о том, как создаются «стори», можно почитать в статье Agile in IT: 8 методов декомпозиции задач.
• BA approach (бизнес-аналитический подход). Важно, чтобы бизнес-аналитик правильно выбирал инструменты в соответствии с задачами проекта. Для этого существует BA approach — он нужен, чтобы определиться, каким образом на проекте лучше всего вести документацию, поддерживать коммуникацию, по какому темплейту (привет, англицизм) оформлять юзер «стори» и документацию, как их систематизировать и хранить. Это инструкция к тому, как работать. Особенно это важно для джуниоров, которые только пришли на проект и не знают (да и не должны), в какой ситуации как действовать. Главное — уметь правильно пользоваться тем, что подготовили старшие коллеги.
• Стейкхолдер-менеджмент. Стейкхолдеры (заинтересованные лица) — это люди, чьи решения и действия влияют на продукт. Очень важно знать, откуда к бизнес-аналитику приходят требования. Бизнес-аналитик постоянно общается с бизнесом, поэтому необходимо понимать, какой человек за что отвечает и какими полномочиями наделен. Очень часто случается так, что у спонсора проекта нет времени погружаться в детали. Но есть ребята, у которых влияние на проект не высокое, а заинтересованность очень высокая, сюда же относятся конечные пользователи продукта. Здесь важно понимать, кто за что ответственен, по какому вопросу к кому идти, с кем и как часто коммуницировать. Частый кейс, когда пришел стейкхолдер 1 и говорит, что кнопка должна быть красной, а стейкхолдер 2 — что синей. Какие твои действия как бизнес-аналитика? Открываем документацию и смотрим, за что отвечает стейкхолдер 1, а за что — стейкхолдер 2, и кто из них несет полномочия в принятии этого решения.
• Риск-менеджмент. Этот термин знаком не только аналитикам, но и продуктовым и деливери-менеджерам. У всех есть свой перечень рисков, которые могут наступить. Риски могут быть как негативные, так и позитивные. По классике все обычно сфокусированы на негативных рисках. Для бизнес-аналитика один из самых популярных и обсуждаемых — риск тихого стейкхолдера, когда ты пишешь письма в никуда. Тебе нужно что-то уточнить, у тебя горят сроки, простаивает команда разработчиков, ты не можешь передать «сторю» в разработку без финального ОК или уточнить детали, а ответа нет. Поэтому подумать об этом заранее и разработать план действий к сложной ситуации точно не будет лишним. Кстати, данный риск тесно связан со стейкхолдер-менеджментом.
• Elicitation and gathering requirements (требования к выявлению и сбору информации). Бизнес-аналитику важно не придумывать свои требования к системе, а уметь грамотно узнавать у бизнеса, что же надо ему. И далеко не всегда на простой и понятный вопрос можно услышать такой же простой и понятный ответ. Чтобы найти истину, применяются разные техники: интервью, брейнштормы, опросы и другие способы. Очень важно правильно задать вопрос. Как ты задаешь вопрос, так тебе на него ответят. А лучший ответ для бизнес-аналитика — четкий, полный и недвусмысленный. Тебе нужно выявить все требования максимально полно для того, чтобы с ними дальше работать и передавать в разработку.
• Traceability management (управление отслеживаемостью). Этот инструмент предназначен для того, чтобы не выходить за рамки и не допустить каких-то пробелов внутри. Качественно проработанные цели в начале — залог успеха проекта. Далее важно создать последовательность от первоначального бизнес-требования до конечной юзер «стори». Так как путь долгий, то часто появляются требования, которых не было первоначально, или, наоборот, что-то теряется. И в какой-то момент понимаешь, что уже не понимаешь, зачем ты это делаешь. Мы соотносим бизнес-потребности с потребностями пользователя. Потом придумываем решение, дробим его на фичи, фичи на «стори». Это все можно представить в виде traceability матрицы — таблицы, где мы видим, как от источника проблемы мы доходим до конкретной «стори». Этот инструмент классно применять, чтобы в процессе не забыть, что, зачем и для кого мы делаем. В конце, когда ты понимаешь, что у тебя условно 30 user stories и многие из них не покрывают никакую из бизнес-целей, от них нужно отказаться, чтобы не делать лишнюю работу и не столкнуться с разочарованием заказчика.
• Бэклог. Бизнес-аналитик — один из тех, кто отвечает за бэклог продукта. Это место, куда складываются все задачи, которые нужно сделать. Дальше бизнес-аналитик с командой и владельцем продукта их эстимирует (оценивает) и приоритизирует (очень много про техники приоритизации можно найти здесь). Дать правильный приоритет задаче очень важно, ведь не стоит забывать про правило выжатого полотенца, или Принцип Парето, когда 80% результата приходится на 20% усилий. Эти 80% позволяют продукту работать и приносить определенную ценность. Часто случается, что те задачи, которые имели низкий приоритет, выходят из скоупа за ненадобностью или недостаточной ценностью.
  
• Бизнес-процессы. Бизнес-аналитики могут рисовать, как путешествуют данные, но в большей степени разбираются с бизнес-процессами — последовательностью действий, результатом которой является создание продукта. Тут помогает BPMN диаграмма (вообще существует много разных нотаций, но это одна из основных). Основная задача разобраться с процессом AS IS (как сейчас все работает). При визуализации часто становится понятно, где в процессе «болит». Второй этап — создание диаграммы TO BE (какой должен быть процесс, чтобы не «болело»). Далее на ее основании идет работа по разработке и реализации новой фичи или улучшения уже реализованной.

Подробнее с BPMN нотацией можно ознакомиться здесь.

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

— Soft skills — это must have для бизнес-аналитика. Как ни крути, основой является общение — найти общий язык с бизнесом и разработчиками. Создание артефактов не менее важно. Но это идет как результат коммуникационной части работы. Поэтому важно уделять внимание таким скиллам, как problem solving и conflict management, и командной работе. Сегодня можно обладать очень крутыми hard skills, но если ты не умеешь общаться, то ничего не получится.

Важны и технические знания, хотя бы на уровне понимания. Помните про общение с коллегами-разработчиками.

Без знания английского тоже никуда. Всю литературу рекомендую читать на английском. Если сложно сразу читать на английском, то можно прочитать материал сначала на родном языке, а потом его же — на английском.

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