Автор текста: Виктория Шевченко
Бизнес-аналитик, «Дар» (КОРУС Консалтинг)
Привет! Я Вика. Работаю в компании «ДАР» (КОРУС Консалтинг) бизнес-аналитиком. До КОРУСа работала бизнес-аналитиком в энергетической компании. Могу сказать, что любой опыт в этой роли – полезный. Бизнес-аналитик – это тот человек, который должен уметь подстраиваться под меняющиеся условия бизнеса, а бизнес может меняться очень быстро. В связи с чем возникает вопрос: кто, если не бизнес-аналитик, должен уметь адаптироваться к любой ситуации?
Есть мнение, что бизнес-аналитики – самые беззаботные участники проекта. Сюда подойдет мем:
Давайте разбираться, так ли это на самом деле.
Я не буду пытаться убедить вас в том, что мы самые страдающие ребята на проектах. Просто опишу реальные кейсы, с которыми мы, бизнес-аналитики, сталкиваемся повсеместно.
Эта статья для ребят, которые только начинают или планируют развиваться в этой роли. Ни в коем случае не хочу отпугнуть, только предупредить, что такое бывает. Просто нужно выработать сценарий действий для разных случаев. Не стоит этого бояться и не пробовать вовсе.
Примечание: эта статья задумывалась в том числе как элемент терапии 😂 Чтобы выговориться нам, а вам почитать и понять, что вы не одни такие.
Так что же такого в этой профессии, что может оттолкнуть новичков и вогнать в стресс мидлов? Об этом расскажем я и несколько других аналитиков, кто сталкивался со сложностями на своем пути.
Так вот…
Боль №1. Много пользователей в одной роли, но с разными потребностями
Первая боль будет из моей практики в качестве внутреннего бизнес-аналитика.
В моем опыте были задачи, связанные с созданием дашбордов в BI-инструменте, где пользователи находились в разных параллельных подразделениях на одной роли, но в силу обстоятельств могли иметь частично или полностью не совпадающие обязанности. Число подразделений варьировалось от 1 до 15, а численность людей могло достигать 20 человек, в зависимости от задачи. УГОДИТЬ НУЖНО БЫЛО ВСЕМ!
Предоставление информации предполагалось в виде «Главного экрана» с основными показателями и страницы с набором дашбордов по разным направлениям. Как оказалось, требования у заказчиков могли быть прямо противоположными. С таким набором информации общий главный экран не справлялся, а сделать разные главные экраны для каждого было очень трудозатратно. Заказчик упорно хотел уложить всю важную информацию на один дашборд, от чего он мог грузиться больше 5 минут (для пользователей это вечность). Итог: загрузка данных в 5 минут была неприемлемой, и мы начали искать выходы из ситуации совместно с заказчиком. Приняли решение, что оставим максимально пересекающуюся информацию, а то, что отличается отразим в виде простейших карточек с ссылками на более подробную информацию. Рекомендация: на этапе сбора требований важно выявлять основные требования и разногласия в них, собирать всех заинтересованных лиц и договариваться. Задача бизнес-аналитика оценить реалистичность требований и предложить оптимальное решение. Это может быть очень сложно особенно при столкновении с новой предметной областью, особенно новичку.
Боль №2. Когда заказчик приходит не с проблемой, а с готовым решением
Этой историей со мной поделилась коллега. Заказчик пришел с потребностью сделать рекомендательную систему для интернет-магазина. Он подробно описал все хотелки, как это должно работать с точки зрения data science, причем свободно применяя все термины из этой области. Из чего команда сделала вывод, что заказчик достаточно хорошо погружен в тематику. Команда упорно долгое время искала пути, как сделать все так, как описал заказчик, но работа не приносила результата. Когда моя коллега пришла к заказчику с предложением откатиться назад и попробовать пойти от проблемы, то выяснилось, что заказчик так уверенно орудовал умными терминами, потому что предварительно пообщался с ChatGPT по поводу рекомендательной системы. Именно ИИ и выдал готовое решение. Конечно, заказчик в своем запросе не указывал возможности своей системы, ее зрелость для того решения, который предложил ChatGPT.
Итог: постановка заказчика очень ограничила команду, что на первом этапе не позволило ей предложить более оптимальный вариант, решающий изначальную боль. Коллега предложила ему рассмотреть все варианты реализации его задумки в отрыве от предложенного им ранее решения. Они достаточно быстро нашли путь к решению проблемы заказчика, и команда успешно справилась с поставленной задачей. На демо заказчик сказал заветное: «Это то, что я хотел». Рекомендация: когда заказчик просит реализовать конкретное решение, стоит выяснить, почему именно его, как он пришел к такому решению и какие боли он этим решает. Это явление может привести к значительным трудностям в процессе разработки и реализации проектов, поскольку аналитики оказываются в ситуации, когда им необходимо адаптировать свои усилия к уже сформулированным, но зачастую неадекватным требованиям. Не каждое решение универсально и может подойти в конкретном случае.
Боль №3. Несколько заказчиков на одном проекте
Впервые я столкнулась с такой ситуацией недавно. Это был один из моих первых проектов в КОРУСе на аутстаффе. На первых встречах познакомилась с командой заказчика, которая погружала меня в предметную область. На следующих наших встречах могли присутствовать не все, и так, от встречи к встрече состав одних и тех же людей менялся. На одной из встреч, где присутствовали не все, мы определили приоритеты ближайших задач, о чем я отписалась в общем в чате. На это получила неприятный ответ, что приоритеты НЕ ТЕ.
На тот момент я поняла, что допустила большую ошибку. Я обсуждала приоритеты только с одним человеком из команды, предполагая, что это общая позиция команды. Как оказалось, мнение разнится, поэтому нужно обговаривать задачи со всеми.
Итог: каждую нашу встречу я стала заканчивать закреплением договоренностей. Плюсом, все итоги наших встреч я отправляла в чат, где подсвечивала приоритеты наших задач. Таким образом, каждый знал, о чем была встреча и о чем мы договорились, даже если не был на самой встрече. И в случае несогласия, мог оспорить приоритеты
Рекомендация: когда в команде заказчика несколько людей, стоит вовремя идентифицировать, кто за что отвечает, и за кем остается последнее слово. Это крайне важная необходимость в подобной ситуации. Каждое решение стоит фиксировать и согласовывать со всеми сторонами, принимающими решение, даже если их не было на встрече.
Боль №4. Погружение в предметную область
Для кого-то это боль, для кого-то обыденная задача. Но однозначно, погружаться в новую область – сложно, каждый раз это новый вызов. Скажу, что из моего опыта и опыта моих коллег, погружение в предметную область иногда дается очень сложно. Работая в одной похожей области с разными заказчиками, у них все может кардинально отличаться, и разбираться придется с нуля.
Работая более двух лет в одном бизнес-процессе, зная его от и до, я перешла в сферу, где необходимо погружаться каждый новый проект в новую область. Причем, чем быстрее это будет, тем быстрее ты сможешь разобраться во всех нюансах какой-либо определенной сферы. А без них, конечно же, никак. После перехода в КОРУС, теперь каждый проект — это выход из зоны комфорта, чему я одновременно рада и от чего я всегда очень переживаю.
В КОРУС я попала на проект с одним из крупнейших ритейлеров России. Первая встреча, созвон с заказчиком, и мои вопросы в голове: «Маржа? Сток? Много каких-то слов на непонятном мне языке. Что это все такое?». Далее – куча вопросов заказчику, изучение множества внутренних ресурсов с информацией, базы данных, повторные встречи и по кругу. Вот так и началось мое погружение в новую область.
Итог: я выбрала тактику, что после каждого объяснения или описания процессов, я проговариваю заказчику то, как я это поняла, и жду подтверждения правильности. Конечно, с первых встреч докопаться до всех нюансов не получилось, но по ходу того, как я изучала материалы, приходило понимание, куда нужно обратить внимание и что уточнить.
В рамках проекта, который почти завершился на момент написания статьи, мы получили положительную обратную связь по нашей работе. Могу сказать, что местами изучение давалось очень сложно. По ходу того, как шел проект, всплывали новые подводные камни, которые нужно было оперативно учитывать. НО МЫ СПРАВИЛИСЬ!
Рекомендация: что я поняла, так это то, что нужно задавать все вопросы (даже, если они кажутся глупыми), которые возникают и не опираться на предположения. Заказчик не расскажет про все нюансы, потому что для него они очевидны и уже давно понятны. Также, иногда бывает такое, что сам заказчик не всегда знает обо ВСЕХ нюансах, поэтому важно обращаться к стейхолдерам и будущим пользователям, если есть такая возможность. Они уж точно про свои боли много чего могут рассказать. Конечно, с первого раза сложно все учесть. Именно поэтому существует итеративный подход, где бизнес-аналитик после каждой встречи переваривает всю информацию и возвращается с новыми вопросами.
Боль №5. Психологическое давление
Пятая причина (боль), с которой мне бы не хотелось, чтобы кто-то столкнулся когда-либо. И это самое неприятное, что может произойти, как мне кажется, в работе. Этот случай из моей практики. Я не была тем аналитиком, который попал в такую ситуацию, но была участником проекта и наблюдателем. Первоначального исследования проекта не было, как и четко установленных ограничений для реализации. Соответственно, на старте проекта оказалось, что нет понимания всей концепции системы. Проект шел очень сложно, а сроки были очень сжатые. Информации много, требований тоже много, и к общей концепции мы так и не пришли. Мы были в условиях, где потребности заказчика динамически меняются, количество идей растет, а сроки те же. Часть данных, которые заказчик желал видеть в системе, отсутствовала в базах. В макеты вносили изменения в каждой итерации показа, а заказчик при этом негодовал, почему нельзя сразу все нормально сделать «грустный смайлик». В определенный момент стало ясно, что мы не справляемся с таким объемом задач. Сроки поджимают, а часть требований еще не утверждена. Конечно, это все отразилось на качестве проекта. Заказчик принял позицию, где мы виноваты, что система плохо работает. Такое отношение повлияло на общую атмосферу в команде, вогнала ее участников в стресс, что также влияло на продуктивность.
Итог: заказчик не принял предоставленный вариант системы. Таким образом, разработка затянулась еще на полгода. Спустя время нам удалось прийти к общей концепции. На данном этапе работа пошла быстрее и легче. В итоге проект был сдан.
Рекомендация: во-первых, в каждом проекте на старте необходимо установить реалистичные ожидания относительно сроков и результатов проекта, чтобы избежать разочарования со стороны заказчика. Во-вторых, в случае отсутствия начального исследования проекта, нужно подсветить риски, что возможны аспекты, которые не позволят реализовать те пожелания, которые высказывает заказчик. И самое главное – важно устанавливать четкие границы, поддерживать открытый диалог с заказчиком, четко аргументировать свою позицию, а еще, конечно же, не поддаваться на провокации.
Эта ситуация показывает, как важно управлять ожиданиями и вести бэклог задач: протоколировать требования, расставлять приоритеты, оценивать трудозатраты на выполнение задач, и не забывать задавать вопросы «а зачем это нужно, какую боль мы решаем и какую ценность получаем». Опять же, для новичка это может быть достаточно сложная задача, и он может не сразу понять, в какую яму закапывается. Да и сложно противостоять заказчику, не имея достаточного опыта. В таком случае нужно бежать к РП (если он имеется, конечно) или к старшим коллегам.
Заключение
Эти «боли» не единственные, с которыми мы сталкиваемся. Каждый заказчик, проект, процесс уникальны. Именно поэтому нужно быть готовым морально ко всему и уметь адаптироваться.
Работа бизнес-аналитика — это не только вызов, но и уникальная возможность влиять на успех проектов и организаций. Несмотря на множество трудностей, с которыми сталкиваются аналитики, их роль в создании эффективных решений и налаживании коммуникации между различными заинтересованными сторонами невозможно переоценить.
Понимание и преодоление «болей» профессии — это путь к профессиональному росту и личностному развитию. Каждый вызов, с которым сталкивается аналитик, может стать ступенькой к новым знаниям и навыкам. Важно помнить, что в мире бизнеса нет универсальных решений, и именно гибкость, умение адаптироваться и находить общий язык с людьми делают бизнес-аналитиков незаменимыми в любой команде.
Пусть эта статья будет не только способом поделиться опытом, но и напоминанием о том, что вы не одни в своих переживаниях. Каждый из нас сталкивается с трудностями, и именно в этом заключается суть нашей профессии — находить решения и двигаться вперед, несмотря на все преграды. Удачи вам на этом увлекательном пути!
Буду рада, если вы поделитесь в комментариях под текстом, с какими болями сталкиваетесь вы и какие решения находите :)
Tech IT Easy — телеграм-канал о карьере в ИТ от экспертов КОРУСа
