Пять ошибок начинающего бизнес-аналитика, которые не дадут перейти на новый уровень

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

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

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

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

Проблема кроется в боязни выглядеть некомпетентным в глазах начальства, команды или другого авторитета в компании. А ещё — в ощущении, что результат всего проекта зависит только от одного человека.

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

Задайте вопрос прежде всего себе, а потом команде или руководителю: «Что самое катастрофическое произойдет, если я ошибусь?». Скорее всего… ничего. Над проектом работает целая команда, и ошибку всегда вовремя отловит менеджер, QA или разработчик, а для тебя это останется лишь полезным опытом, как делать не надо. Если последствия будут критичными, то команда подсветит риск и поможет разобраться.

В начале проекта полезно спросить того, кто знает, как правильно выполнить поставленную задачу. У нас в Роботе новый сотрудник не остаётся наедине с задачами: всегда можно обратиться к старшему товарищу — участнику команды, ментору или руководителю. Или подсветить руководителю или менеджеру проекта, что задача незнакомая, а значит, потребуется помощь или дополнительное время на ее выполнение.

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

Частая проблема для начинающих — и не только бизнес-аналитиков! — попытка взять на себя много больших сложных задач, да еще и в нереальные сроки. Не надо так.

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

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

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

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

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

У нас в red_mad_robot на старте проекта менеджер организует встречу, на которой проговариваются и закрепляются зоны ответственности — кто и за какой этап производства и результат отвечает. Эта встреча нужна, чтобы чётко договориться о том, что каждый из участников команды должен делать и за что быть ответственным. В нашей компании бизнес-аналитики не тестируют сборки, не рисуют дизайн, не пишут код и не строят план проекта. Мы четко закрепили роли, чтобы аналитик больше погружался в цели бизнеса и нужды пользователей, а также формулировал функциональные, нефункциональные, интеграционные и бизнес-требования.

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

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

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

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

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

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

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

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

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

Стоит честно сказать коллеге про свои чувства, рассказать, как тебе комфортно принимать обратную связь и поделиться правилами, которые помогают эффективнее давать и получать ее. Если в компании в целом нет практики регулярного обмена фидбеком, стоит проявить инициативу и самостоятельно пойти к команде и попросить дать фидбек.

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

***

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

***

Если понравилось, что генерируют наши нейросети, читай материал о том, чего стоит ждать до 2050 года от развития Human Augmentation.

Мы изучаем тему цифровизации со всех сторон и делимся наблюдениями и выводами на разных площадках. Чтобы ничего не пропустить, следи за развитием рынка цифры вместе с нами:

・Redmadnews

・Facebook

・Instagram

・LinkedIn

・VK

Да пребудет с тобой сила роботов! 🤖

#businessanalyst #businessanalytics #бизнесаналитика #junior #middle #redmadrobot #red_mad_robot