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

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

Роберт Шекли, «Координаты Чудес» (1968)

Всем привет. Меня зовут Святослав Щербатюк, я сотрудничаю с днепровским офисом ЕРАМ в роли Lead Business Analyst. В эту профессию я пришел четыре с лишним года назад из сферы юридического сопровождения инвестиционных проектов, которым занимался десять лет.

Закрываем позицию бизнес-аналитика // Бесплатный вебинар OTUS

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

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

Итак, по порядку

1. Английский язык. Одна из основных и наиболее существенных – недостаточное внимание к уровню своего английского языка. На собеседованиях нередко доводится сталкиваться с кандидатами с высоким уровнем знаний в предметной области и внушительным опытом работы, но слабым английским.

Необходимо учитывать, что большинство ІТ-компаний и проектов ориентированы на зарубежных заказчиков. Необходимость в свободном английском определяется местом бизнес-аналитика на пересечение продуктовой и инженерной команды (роль и место ВА в Scrum-команде — тема для отдельной holy war) и задачами, стоящими перед ним (эффективная коммуникация между этими командами).

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

2. Слепое следование фреймворку. Из вопроса эффективных коммуникаций вытекает еще одна достаточно серьезная ошибка новичков — догматичное следование подходам выбранного фреймворка. Необходимо учитывать, что ІТ – это динамично развивающаяся отрасль и секрет успеха в ней состоит в способности адаптироваться к быстроменяющимся обстоятельствам.

Все, что нужно знать о профессии бизнес-аналитика

Можно сколько угодно говорить команде, что «мы работаем по классическому Scrum/lean/Kanban», но если поставленные задачи и процессы ей непонятны или забирают больше времени и ресурсов, чем могли бы при использовании подхода, отличного от хрестоматийного, то смысла в этом нет. Было бы непрофессионально в таком случае сказать «это плохая команда, они неправильно следуют моему идеальному подходу к методологии». Задача бизнес-аналитика — изучить разные подходы и подобрать тот, который будет наиболее эффективен для конкретной команды в конкретном проекте. Отмечу, что за время моей практики мне не встречался ни один проект с абсолютно «книжными» процессами.

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

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

Так, к примеру, лучше не забывать, что представители азиатских культур не всегда могут прямо сказать «нет», а при работе с американцами или канадцами стоит уделить 5 минут беседе об успехах их местной спортивной команды. О том, что часто специалистов из восточноевропейской, славянской культуры представителями западной культуры воспринимают как грубоватых, мне доводилось слышать неоднократно (например, люди используют оборот “can you” вместо более мягкого «could you» и забывают добавить «please»). На одном из проектов стейкхолдер прямо спросил, за что его так ненавидит команда. В конце концов, выяснилось, что сложность кроется в различии культур и недостаточном уровне владения английским.

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

Чтобы улучшить навыки коммуникации с клиентами:

• пополняйте словарный запас тонкостями и синонимами;
• учите conditionals;
• работайте над произношением;
• изучите правила использования артиклей «a» и «the».

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

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

5. Отсутствие правильного roadmap. Одной из серьезных сложностей может стать отсутствие на проекте таких основных документов как vision и roadmap, основанных на клиентских планах продаж. Возможно, данный вопрос важнее для крупных проектов и относится к сфере обязанностей product-менеджеров, но бизнес-аналитик в любом случае может и должен инициировать и фасилитировать процесс создания таких документов. Если ВА планирует развиваться в направление product-менеджмента, это стоит учитывать.

В качестве примера из своего личного опыта могу привести ситуацию, когда группа ВА разрабатывала проект roadmap-а для дальнейшего его рассмотрения и утверждения product-менеджмент командой. Специалисты, в частности, анализировали функционал приложений потенциальных конкурентов, планы продаж компании на будущий год, планы развития связанных модулей, а также stories из бэклога, которые по каким-то причинам были давно отвергнуты product-менеджерами. На базе всех этих изысканий и родился roadmap, который заказчики утвердили.

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

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

В планировании общения важно учитывать не только саму суть вопроса, но и то, как он сформулирован. Часто бывает, что от постановки вопроса зависит и ответ клиента. Это крайне важно, когда бизнес-аналитику, как представителю команды исполнителя, нужно отстоять решения инженерной команды, в частности при проведении user acceptance testing и сдаче работ заказчику. Для построения рабочей матрицы влияния и заинтересованности можно распределить стейкхолдеров по четырем квадрантам. Хороший практический пример можно найти в этой статье на dou.ua.

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

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

8. Отсутствие visibility. Стоит отметить и формат ежедневных стендапов. Заказчику крайне важно иметь достаточный уровень visibility, знать куда и насколько эффективно были потрачены его деньги. Начинающим бизнес-аналитикам (хотя часто не только им ) не всегда удается кратко и информативно объяснить заказчику, какая работа выполнена.

Помните, что клиенту не понравится узнать, что, например, всю прошлую неделю кто-то из членов команды находился в блокере и ничего не делал. Я встречал ситуации, когда клиент на аргумент о том, что кто-то был заблокирован чем-то, спрашивал: «А что лично ты сделал для того, чтобы преодолеть блокер/чем занимался пока был заблокирован?». Используйте время, когда вы в блокере, для улучшения существующих процессов на проекте. Благо, такой работы (особенно на новых проектах) предостаточно. А когда будете рассказывать заказчику о завершенных задачах, исходите из позиции проактивности, думайте о том, какие встречные вопросы можете предвосхитить.

9. На детали тратится слишком много времени. В качестве ошибки начинающих можно выделить излишнюю фокусировку на деталях тикета и/или тонкостях имплементации при его описании. На долгосрочных проектах необходимо учитывать, что детали имплементации могут поменяться с переходом на новую технологию, при этом бизнес клиента останется тем же. Неправильно составленные acceptance-критерии со множеством деталей имплементации (например, описывающие конкретные методы или API request/response) приведут к тому, что продуктовый бэклог придется переписывать.

В противном случае с точки зрения регрессионного тестирования фактическое поведение системы будет отличаться от существующих требований: технически необходимо заводить баговый тикет, бэклог становится «outdated» (то есть описание состояния системы становится неактуальным). При этом формальных причин для переписывания требований нет, если бизнес-процессы клиента не изменились.

10. У вас нет видения всего проекта. Также типичной ошибкой для крупных, долгосрочных проектов может быть отсутствие понимания «большой картины», связи с другими элементами экосистемы и нехватка «helicopter view».

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

11. Вы идете от обратного. Связанной с предыдущей является ошибка написания требований «от обратного» — о том, что система не должна делать. В результате получается бэклог требований, из которого понятно, чего система не будет делать, но непонятно что же она делать будет. Это может быть связано с тем, что фокус на бизнесе клиента теряется.

Необходимо помнить, что ВА думает в первую очередь непосредственно о том, что делает система для решения бизнес потребностей клиента.

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

Пожалуй, наиболее действенным советом было бы ничего не бояться, но и не ручаться от имени команды за какие-то сроки и работы перед заказчиком/стейкхолдерами. Стоит шаг за шагом выполнять все действия, которые ожидаются от нового на проекте бизнес-аналитика. Не забывайте, что тот же BABoK содержит весь необходимый вам план действий. Это нормально, что в начале проекта ничего не понятно.

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

13. Страх ошибки. Он парализует и вместо того, чтобы начать действовать и по ходу движения проекта скорректироваться, начинающий бизнес-аналитик начинает долго «готовиться к действиям»: тщательно выписывать письма заказчику, зацикливаться на описании edge case сценариев, маловероятных workflow, которыми на первых этапах проекта, как правило, можно пренебречь. Ошибаться нормально: и Agile, и Scrum – это о том, чтобы ошибаться быстро и так же быстро отреагировать на ошибку.

Всем новичкам в ВА желаю не бояться ошибок и смелее двигаться вперед. Удачи!

• бизнес-анализ
• бизнес-аналитик
• тонкости профессии

• Блог компании EPAM
• Карьера в IT-индустрии

Источник: habr.com

Частые ошибки бизнес-аналитика

Всем привет! Я уже года 3 сижу на vc в качестве читателя. Думаю, пришло время опубликовать свою первую статью, к тому же мне есть, о чем вам рассказать.

Меня зовут Виктор Дмитриев. Я родился и вырос в Липецке, последние 8 лет живу в Москве, переехав сюда в 2012-м, когда поступил в НИУ ВШЭ, но сейчас речь пойдет не об этом

Что важнее для нас сегодня, я последние 5-6 лет работаю в ИТ на должностях бизнес-аналитик / старший бизнес-аналитик / lead бизнес-аналитик. Кроме того, занимался проектным и продуктовым управлением, управлял ИТ-командами до 15-20 человек, запускал достаточно крупные корпоративные продукты на десятки тысяч пользователей, сейчас работаю в B2C продукте (финтех).

Но все-таки бОльшая часть моего профессионального опыта связана с бизнес-/системной аналитикой.

Работал в следующих компаниях:

• BCG
• Норникель
• Inframine
• KPMG
• Paybis

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

Чем занимается бизнес-аналитик

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

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

Сразу отмечу, что в мире принято различать понятия бизнес-аналитик (business analyst) и системный аналитик (system analyst).

Подразумевается, что бизнес-аналитик (тезисно):

• анализирует текущие бизнес-процессы заказчика (as is);
• взаимодействует с заказчиком, чтобы понять его болевые точки;
• моделирует бизнес-процессы заказчика «после» автоматизации (to be).

Системный аналитик, в свою очередь (тезисно):

• взаимодействует с бизнес-аналитиком, чтобы понять какой бизнес-процесс to-be необходим;
• описывает сценарии использования системы (use cases), требования к системе (функциональные и нефункциональные) и другие документы;
• проводит сессии с разработчиками и тестировщиками;

Таким образом, бизнес-аналитик больше взаимодействует с представителями заказчика, системный аналитик — с разработчиками.

Однако, в России эти понятия очень похожи, и часто бизнес-аналитик выполняет также и роль системного аналитика. Поэтому дальше я буду говорить про роль универсального бизнес-аналитика (для простоты буду также называть его просто аналитик).

Теперь, наконец, про ошибки)

Ошибка 1. Принимаем требования заказчика без уточнения его реальных потребностей

Ситуация: к вам приходит заказчик (например, металлургический завод) и говорит: «я хочу, чтобы вы настроили нам интеграцию нашей системы управления готовой продукции с системой отчетности, чтобы мы могли проводить ежемесячную инвентаризацию». Аналитик берет это требование как данность, уточняет детали по шаблону требований к интеграции и передаёт их в разработку. В результате, мы получаем не оптимальное решение с точки зрения потребностей заказчика и ресурсов разработки. Главная проблема, и вы должны ее запомнить — заказчик далеко не всегда знает, чего он хочет на самом деле.

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

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

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

Ошибка 2. Создали и продолжаем поддерживать систему-франкенштейн

Ситуация: в вашей компании на поддержке находится самописная система, которая выступает в роли и ERP, и CRM, и CMS системы. Такая монолитная система-франкенштейн (назовём ее система X). В очередной раз к вам приходит заказчик и говорит: «давайте добавим в систему X возможность создавать B2B заявки с новым набором полей.» Вы, конечно, можете взять это требование, оформить в виде ТЗ, передать разработчикам, а ваш заказчик получит результат. Но является ли это оптимальным решением?

Рекомендуемый подход:

• Соберите требование к желаемой функциональности как можно детальнее. Про то, как собирать требование, мы поговорим с вами в отдельной статье.
• Теперь у вас есть понимание того, что, действительно, нужно заказчику — его потребность (business need/requirement).
• Обратитесь к вашему корпоративному архитектору (в его отсутствие — к руководителю разработки), опишите ему ситуацию и попробуйте вместе найти решение.
• Возможно, в процессе анализа вы поймёте, что такая функциональность уже реализована в другой системе или ее стоит реализовать в другой системе.

Ошибка 3. Забыли обработать исторические данные

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

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

Рекомендуемый подход: на самом деле это ошибка может быть более глубокой — аналитик не продумал часть нового функционала, но часто я встречал ее именно в таком виде. Правило простое — если это имеет место быть, сразу уточняйте (и прописывайте), что внедряемая фича не повлияет/повлияет на исторические данные.

Ошибка 4. Принимаем слова руководителей за «чистую монету»

Ситуация: обратимся к нашему кейсу с металлургическим заводом. К вам приходит начальник отдела Сбыта и просит разработать модуль создания заявок на отгрузку продукции. Он утверждает, что очень давно работает в компании и знает все процессы своего отдела. Вы верите ему на слово, проводите сессии интервьюирований с ним, формируете ТЗ на основе этих знаний, отдаете в разработку, на выходе есть продукт, которым начинают пользоваться сотрудники отдела Сбыта. В результате, оказывается, что часть сотрудников не способны выполнять свои функции в новой системе, потому что почти всегда есть какие-то исключительные случаи (corner cases), которые одному человеку не продумать.

Рекомендуемый подход: тут могу дать два совета:

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

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

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

Оставшиеся ошибки я оставлю для второй части статьи.

Что дальше

Мне очень многое хочется вам рассказать. Конечно, если вам это будет интересно.

Потенциальные темы для обсуждения:

• Типичные ошибки бизнес-аналитика. Часть 2
• Прохождение собеседования на позицию аналитика
• Курсы для прокачки скиллов аналитика
• Hard и sofl скиллы аналитика
• Опыт прохождения Go Practice Simulator
• Как собирать и описывать требования
• Методологии моделирования бизнес-процессов
• Структуры вопросов для интервьирования заказчика
• Зарплаты аналитиков
• Опыт работы аналитиком в Европе

и многое другое.

Интересна для вас тема бизнес-аналитики?
Показать результаты
Переголосовать
Проголосовать
Мои контакты

Вы всегда можете связаться со мной в tg.

Я также являюсь ментором. Ко мне можно обратиться с техническими вопросами, интересными кейсами, поиском карьерных возможностей и помощью в подготовке к собеседованиям. Конечно же, в сфере бизнес-/системной аналитики. Если вам интересно, пишите также в tg.

Показать ещё
26 комментариев
Написать комментарий.

Статья крутая, спасибо!

И непонимание границы ролей бизнес и системных аналитиков это прям боль. Причем работающая в обе стороны, с одной стороны, раз аналитик работает в ИТ команде, то от него принято требовать быть «тру» айтишником. То есть не только бизнес опросить, но и API запросы раскурить.
С другой стороны, увидел допущение и в обратную сторону. В первых двух описанных ошибках от аналитика вроде как требуется побыть в роли Product/Project Manager и не просто повысить уровень условной автоматизации выделенных процессов, а подумать и выйти на уровень ценности ИТ решения.
Это не укладывается в тезисные описания обязанностей бизнес-аналитика в самой статье.

ИМХО. Нет ничего плохого в том, что бизнес-аналитик разбирает проблемы Заказчика и докапывается до ценности, которую хочет клиент. Но его ли это главная работа?
Обычно так случается, когда PM номинален и работает как администратор, бегая с бумажками. Если в такой команде будет сильный аналитик, он может взять на себя провисающие роли. Но хорошо ли это, вопрос.

Развернуть ветку

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

Источник: vc.ru

5 граблей junior бизнес-аналитика и как их обойти: основы бизнес-анализа для начинающих

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

Основные проблемы начинающего бизнес-аналитика с комментариями из BABOK®Guide

Если бы 10 с лишним лет назад, в начале моей карьеры бизнес-аналитика мне попалась подобная статья с практическими советами «бывалых мастеров», я бы сохранила много времени и нервов, пытаясь решить задачи, которые не разбирались в процессе обучения. Обычно высшее образование или профильные курсы фокусируются на методологиях, фреймворках, языках, техниках, приемах и прочих инструментальных аспектах, которые можно отнести к hard skills.

Однако, soft skills также важны в работе бизнес-аналитика. Как это связано с профессиональными компетенциями с точки зрения руководства BABOK®Guide, мы частично разбирали здесь. Но, поскольку это руководство по бизнес-анализу ориентировано, в основном на специалистов с опытом работы, начинающий аналитик может не знать особенностей всех областей знаний, которые описаны в BABOK. Поэтому новички в бизнес-анализе могут столкнуться со следующими трудностями, по крайней мере, в рамках своих нескольких первых проектов. Впрочем, BABOK – не лучший учебник для новичка с нулевым уровнем знаний и практики, о чем я рассказываю здесь.

1. Непонимание истинной конечной цели проекта

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

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

В этом случае «местечковый» менеджер старается «протолкнуть» свое решение, чтобы повысить ROI от уже вложенных инвестиций и продолжить получать финансирование. А «центр» стремится унифицировать процессы и инструменты, попутно сокращая источники затрат. Таким образом, бизнес-аналитик сталкивается с разносторонним пониманием потребности (Need).

Напомним, потребность входит в модель базовых понятий бизнес-анализа (Business Analysis Core Concept Model™, BACCM™), которая является ключевой идей руководства BABOK и образует понятийный каркас бизнес-анализа. Именно потребность как проблема или возможность улучшения может инициировать изменения, побуждая стейкхолдеров к действиям. Поэтому корректное и полное понимание потребности является исходной точкой бизнес-анализа. С этим связаны следующие «грабли», на которые может наступить начинающий бизнес-аналитик.

Основы бизнес-анализа: вход в профессию для начинающих

Код курса

INTRO

Ближайшая дата курса

29 мая, 2023

Длительность обучения

24 ак.часов

Стоимость обучения

50 000 руб.

2. Недостаточное сотрудничество и/или отсутствие поддержки

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

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

Даже если старший sales-менеджер не будет использовать будущую систему, степень полноты и корректности требований к решению зависит от вовлеченности лидера. Таким лидером может быть как официальный руководитель, так и неформальный лидер – рядовой член рабочего коллектива, который пользуется всеобщим уважением. Ответственное и серьезное отношение такого человека к бизнес-анализу как к важной деятельности, а не фактору отвлечения от основной деятельности, будет распространяться на весь коллектив. Это поможет аналитику решать задачи области знаний «Выявление и сотрудничество» (Elicitation and Collaboration), а также взаимодействовать со стейкхолдерами в рамках прочих работ по бизнес-анализу по BABOK®Guide, например, при оценке эффективности внедренного решения (Solution Evaluation), анализе стратегии изменений (Strategy Analysis) и пр.

3. Незнание предметной области

или контекста бизнес-среды (Context), который также входит в BACCM-модель базовых понятий бизнес-анализа. Согласно BABOK, понимание предметной области относится к профессиональной компетенции «Знание бизнеса» (Business Knowledge). Разумеется, невозможно за короткий срок в рамках проекта по бизнес-анализу освоить все отраслевые особенности. Однако, аналитику следует иметь представление об основных процессах и продуктах рассматриваемого домена, их участниках и ключевых результатах, стратегических и тактических целях, а также показателях их достижения. К примеру, без понимания основ банковской деятельности невозможно участвовать в проекте ее оптимизации. «Ликвидировать безграмотность» поможет изучение отраслевых стандартов, внутренних регламентов, профессиональные учебники и прочие методические материалы, а также консультации экспертов предметной области – Subject Matter Expert (SME), как их называет BABOK.

4. Недостаточно плотная работа со SME-стейкхолдерами

из-за стеснения или боязни отвлекать их от основной деятельности. По сути, эти грабли являются следствием предыдущих проблем, а также связаны с отсутствием или недостаточным уровнем soft skills у бизнес-аналитика. BABOK®Guide подчеркивает важность этих профессиональных компетенций, описывая их в коммуникативных навыках (Communication Skills) и навыках взаимодействия (Interaction Skills) для эффективного обмена информацией со стейкхолдерами и умением бизнес-аналитика выстраивать продуктивные отношения, сотрудничать и общаться с разными людьми. Практика показывает, что уровень застенчивости аналитика обратно пропорционален его опыту, а настойчивость, дотошность и внимательность к деталям являются залогом качественно выполненной работы. Поэтому не стоит стесняться отвлекать от прямых обязанностей потенциальных пользователей решения, Заказчика, Спонсора и прочих стейкхолдеров, которых затронет будущее изменение – они вместе с аналитиком участвуют в проекте бизнес-анализа и тоже влияют на его результат.

Источник: babok-school.ru