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

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

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

Сегодня вопрос роли бизнес-аналитика в проекте рассмотрен достаточно детально: известно, какими качествами он должен обладать, как ему лучше строить карьеру, какие навыки развивать. Достаточно воспользоваться поиском 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 – это о том, чтобы ошибаться быстро и так же быстро отреагировать на ошибку.

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