С этими сложностями сталкивается новичок любой специальности — разработчик, редактор или менеджер. Но ошибки на этапе проектирования продукта сильнее всего могут повлиять на всю работу, поэтому критичнее всего для аналитиков. Рассказывают Настя Романцова, старший бизнес-аналитик red_mad_robot, и ребята из её отдела. Поехали!
Роботы делают коммерческие проекты с 2010 года. За 12 лет мы научились их вести, поняли, для чего на проекте нужен бизнес-аналитик, какую роль он выполняет и какими навыками должен обладать. Этот опыт мы постоянно рефлексируем, анализируем и собираем в базу знаний, чтобы транслировать его новым сотрудникам.
В статье выведем топ-5 ошибок начинающих бизнес-аналитиков, разберёмся, почему они возникают и какие бывают последствия, а главное — как их избежать или, если избежать не удалось, исправить с наименьшими потерями. Материал будет полезен бизнес-аналитикам уровня джун и миддл, а также менторам этой специальности, которые работают с подопечными. В конце — бонус для тех, кто дочитал: полезные материалы по теме, которые могут помочь в трудоустройстве.
Ошибка № 1: страшно ошибиться
Часто у начинающих бизнес-аналитиков возникают опасения получить негативный фидбек от руководителя, более опытных коллег, клиента или самое страшное – ошибиться так, что все перестанет работать и компания рухнет.
Почему возникает
Проблема кроется в боязни выглядеть некомпетентным в глазах начальства, команды или другого авторитета в компании. А ещё — в ощущении, что результат всего проекта зависит только от одного человека.
Как лечить
Ключ к решению проблемы лежит в ответе на вопросы: как избавиться от страха и что делать, если ошибка допущена.
Решение № 1. Прояснить риски
Задайте вопрос прежде всего себе, а потом команде или руководителю: «Что самое катастрофическое произойдет, если я ошибусь?». Скорее всего… ничего. Над проектом работает целая команда, и ошибку всегда вовремя отловит менеджер, QA или разработчик, а для тебя это останется лишь полезным опытом, как делать не надо. Если последствия будут критичными, то команда подсветит риск и поможет разобраться.
Решение № 2. Разобраться, как делать
В начале проекта полезно спросить того, кто знает, как правильно выполнить поставленную задачу. У нас в Роботе новый сотрудник не остаётся наедине с задачами: всегда можно обратиться к старшему товарищу — участнику команды, ментору или руководителю. Или подсветить руководителю или менеджеру проекта, что задача незнакомая, а значит, потребуется помощь или дополнительное время на ее выполнение.
Как быть, если уже ошибся
Ошибки — это нормально. Не учёл что-то в требованиях, не прописал краевые состояния или не согласовал с клиентом артефакт — что теперь делать? В первую очередь важно заметить ошибку — обычно это происходит на этапе ревью артефакта или на демонстрации результата. Чем раньше ты поймешь, что ошибся и начнешь принимать меры, тем меньше будут последствия. Во-вторых — предупредить команду об этом, и продумать вместе правильное решение или план по исправлению.
На самом старте было жутко от мысли, что необходимо писать системные требования. Я считала, что для этого надо быть прокачанным разработчиком — и боялась ошибиться. Но ребята из команды QA и разработки у нас лояльные и деликатные, на груммингах (встречах по приоретизации и оценке задач) задавали правильные вопросы, подсвечивали риски для проработки требований. После пары таких встреч я поняла, что они видят задачу со своей стороны, а я со своей — и в этом месте случается синергия, каждый работает в рамках своей зоны ответственности и вкладывается в общий результат.
Помогли разговоры с ментором, которая сняла мои опасения, что на меня возложены неоправданно высокие ожидания. Ведь когда меня нанимали, то изучили мой опыт и скиллы, поэтому мой уровень всем понятен — ясно, с какими задачами я точно справлюсь, а до каких нужно дорасти.
Мой совет всем — помнить, что вы на проекте не одни. Учиться работать в команде, не бояться задавать вопросы и открыто говорить о сложностях с задачами. Ошибки будут у всех рано или поздно, с разным масштабом — это надо воспринимать как часть процесса обучения и становления классным специалистом.
Ошибка № 2: брать на себя больше, чем можешь сделать
Частая проблема для начинающих — и не только бизнес-аналитиков! — попытка взять на себя много больших сложных задач, да еще и в нереальные сроки. Не надо так.
Почему возникает
Чаще всего эта ошибка появляется по трём взаимосвязанным причинам. Первая причина — страх отказаться от поставленных сроков и неумение аргументировать отказ. Вторая — мало опыта в планировании и декомпозиции задач, а третья — переоценка своего реального опыта и навыков.
Как лечить
Решение 1. Учиться объяснять
Когда есть трудности с тем, чтобы отказать, то скорее всего они появляются из-за боязни испортить отношения или показаться грубым. Например, менеджер просит на этой неделе взять дополнительную задачу, а все уже спланировано и скорее всего успеть её не удастся. Что делать? Важно правильно аргументировать, почему нет: спокойно подсветить менеджеру, что загрузка уже распределена и ресурс уйдет на другие задачи, а также предложить перепланировать задачи в соответствии с приоритетами. Часто этого может быть достаточно, чтобы перенести задачу на следующую неделю или отказаться от какой-то текущей в пользу новой и более срочной.
Решение 2. Учиться декомпозировать
Если перегрузка возникает из-за того, что большую задачу сложно оценить — на помощь приходят правила декомпозиции. Нужно разбить новую задачу на подзадачи как можно детальнее, учесть все риски (например, не получишь необходимые доступы, не будет нужных вводных, много неопределенности или есть ещё загрузка) и только тогда оценивать сроки выполнения. Если этого не делать, то есть риск выгореть, потерять качество артефактов и умножить сроки работы вдвое из-за доработок. В таком случае желание зарекомендовать себя, как специалиста и успеть сделать всё, приведет к обратному результату — переработкам и потере качества работы.
Я работаю на банковском проекте, где мы развиваем приложение для юридических лиц.
Самой ощутимой ошибкой для меня было — брать на себя больше, чем могу сделать. Особенно остро это ощутила, когда лид аналитики отключился с проекта и мне пришлось закрывать его зону ответственности. Из-за недостатка опыта в планировании и желания сохранить качество аналитики я жестко овертаймила, но никому об этом не рассказывала. В тот момент еще не понимала приоритетность и объемы задач, поэтому брала все.
В итоге измотала себя и заболела. Проект, конечно, от этого не выиграл и мои мотивация с продуктивностью тоже просели.
Вывод: помни, что тебе нужен отдых, иначе работа перестанет приносить плоды. В моем случае можно было просто прийти к проджект-менеджеру и совместно расставить приоритеты.
Ошибка № 3: не разделять зоны ответственности
Иногда бывает, что ответственность и распределение ролей в команде размыты. Это приводит к сложностям на проекте и напряжению в команде.
Почему возникает
Понимание того, что делает бизнес-аналитик, в разных компаниях отличается, поэтому часто новый сотрудник не знает, как выстроены зоны ответственности в команде. Из-за этого бизнес-аналитики начинают перенимать работу QA, разработчика, дизайнера или менеджера, не имея полной экспертизы в этих областях. От этого страдает качество работы и артефактов аналитика, ведь времени на свои задачи не хватает, а область знаний размывается.
Как лечить
Решение 1. Договориться о зонах ответственности
У нас в red_mad_robot на старте проекта менеджер организует встречу, на которой проговариваются и закрепляются зоны ответственности — кто и за какой этап производства и результат отвечает. Эта встреча нужна, чтобы чётко договориться о том, что каждый из участников команды должен делать и за что быть ответственным. В нашей компании бизнес-аналитики не тестируют сборки, не рисуют дизайн, не пишут код и не строят план проекта. Мы четко закрепили роли, чтобы аналитик больше погружался в цели бизнеса и нужды пользователей, а также формулировал функциональные, нефункциональные, интеграционные и бизнес-требования.
Решение 2. Освоить процесс производства
Мы уделяем много внимания онбордингу: сотрудник во время испытательного срока изучает описанный производственный процесс, и рассказывает о каждой роли и этапе на проекте на промежуточных встречах. Здесь подключается и система менторства: ментор помогает изучить производство от начала до конца, подробно разобраться в задачах бизнес-аналитика и всей команды.
На консалтинговом проекте надо было провести дизайн-аудит всех цифровых сервисов компании. Сроки были очень сжатые, и я решила героически вписаться в эту задачу, чтобы помочь команде дизайна.
В последний момент лид практики объяснила, что это плохое решение: я не специалист в этой области, это не моя зона ответственности, и команда потратит больше времени на ревью и перепроверку моего аудита.
Пришлось честно признаться, что я не справлюсь, и мы быстро переделали план работ. Из последствий — только потраченное время команды на пересмотр плана. Совет: здраво оценивать свои силы и не смешивать зоны ответственности.
Ошибка № 4: не думать про цели бизнеса и пользователей
Часто новые бизнес-аналитики рассчитывают, что на старте проекта будет понятное техзадание, с которым и предстоит работать, но в продуктовой команде всё устроено иначе.
Почему возникает
Аналитики просто не знают, что можно предлагать решения по развитию продукта, а когда понимают, что такая возможность есть, то сталкиваются с пробелами в знаниях проектирования продукта — их нужно закрывать, набирая новые навыки.
Как лечить
Создавая продукт, важно закрывать как цели бизнеса, так и пользователей. Чтобы это делать, нужно постараться видеть картинку целиком, а не мыслить только одной стороной — техническими ограничениями, мнением пользователей или представлением бизнеса. Например, для этого мы используем на проекте паспорт продукта, — артефакт, где фиксируем цели, задачи и экономику бизнеса, целевую аудиторию, ее боли и потребности, а также миссию и цели продукта. Отдельно проводим технический брифинг с клиентом и узнаем про все технические ограничения, требования и возможности.
Чтобы посмотреть на задачу с разных сторон и развить критическое мышление, стоит восполнить пробелы в знаниях.
- Посмотреть простые курсы о том, как работает экономика
- Изучить стратегическое планирование и целеполагание по SMART-подходу, чтобы понимать, как ставит цели бизнес, и как это можно соотнести с продуктом.
- Изучить основы бизнес-моделирования — business canvas, lean canvas.
- Узнать, как работать с пользовательскими исследованиями: не приземляй на себя мнение о продукте (пользователь не всегда мыслит, как ты), изучи как правильно задавать вопросы пользователю (необходимо спрашивать про опыт пользователя, про его боли, никогда не спрашивай в лоб мнение о продукте).
В мой первый год в Роботе я работала над банковским проектом для юридических лиц. Было сложно перестроиться с предыдущего опыта и осознать, что я могу и должна разбираться в целях бизнеса и пользователей, а в этой сфере особенно важно опираться на функциональность для пользователей и на денежный импакт.
Это привело к тому, что мы сделали фичу, которая не пользовалась особой популярностью. Это демотивировало как меня и команду, так и клиента: для нас это была « работа в стол», а для клиента – лишние траты.
Впоследствии ментор помог мне понять, что важно задавать себе и клиенту уточняющие вопросы вроде «Зачем нам это нужно? На что повлияет реализация этой фичи? Какую проблему мы закрываем?». И чем больше таких вопросов я задам, тем больше будет понимания как у меня, так и у клиента, а продукт, над которым мы работаем – будет полезнее и качественнее для пользователей.
Совет всем начинающим: не думайте только о технической стороне вопроса — откуда взять данные, как их обработать и тд. Попробуйте представить, что вы – владелец продукта, над которым сейчас работаете. С такой позиции мышление немного перестраивается и у вас в голове возникнут вопросы, которые помогут.
Ошибка № 5: неправильно давать и получать обратную связь
Самая частая ошибка начинающего сотрудника — это сложность работы с фидбеком. С одной стороны, его сложно получить, а с другой — корректно дать. Разберем, почему так происходит, как исправить и почему это так важно в работе.
Почему возникает
Часто получить обратную связь сложно из-за предыдущего плохого опыта, страха критики и отсутствия в культуре и процессах компании практики регулярного фидбека. Дать фидбек бывает сложно, если есть убеждение, что это неприятный процесс, который может испортить отношения.
Как лечить
Решение 1. Если нужно взять обратную связь
Первое, что важно сделать — принять, что фидбек это хорошо. Только получая своевременный взгляд со стороны, можно скорректировать работу, исправить ошибки и прокачать навыки.
Но бывает, что фидбек от коллеги приходит в грубой форме. Так быть не должно и происходит из-за незнания правил того, как давать и просить обратную связь. Например, в Роботах мы сформировали несколько таких правил, вот некоторые из них: — точки роста лучше проговаривать лично, а вот сильные стороны можно подметить и при всей команде.- стоит внимательно выбирать время для фидбека, потому что человек должен быть в стабильном эмоциональном состоянии. — фидбек должен быть конструктивным и касаться только рабочих задач, но никогда не личности человек.
Стоит честно сказать коллеге про свои чувства, рассказать, как тебе комфортно принимать обратную связь и поделиться правилами, которые помогают эффективнее давать и получать ее. Если в компании в целом нет практики регулярного обмена фидбеком, стоит проявить инициативу и самостоятельно пойти к команде и попросить дать фидбек.
Решение 2. Если нужно дать обратную связь
Здесь тоже важно придерживаться правил выдачи обратной связи, понимать, что фидбек влияет на развитие человека, относись к другому человеку с эмпатией (так, как бы ты хотел, чтобы относились к тебе) и вовремя подсвечивать сильные и слабые стороны его работы.
Одним из моих первых серьезных проектов в Роботах был проект из сферы страхования, который предстояло спроектировать с нуля. Специфика сложная и большая часть работы лежала в проектировании интеграций со внешними сервисами. Раньше я не сталкивалась с такими сложными интеграциями, поэтому в конечном итоге мои функциональные требования не были детализированы на должном уровне.
Моей ошибкой стал страх запроса фидбека у разработчика. Правда, он и сам не приходил с обратной связью. На одном из ретро он подсветил неточную проработку с моей стороны. Постепенно ситуация накалялась, срок внесения правок в требования увеличивался и, соответственно – время разработки.
Решение проблемы заняло полчаса. Мы поговорили с разработчиком, договорились о взаимодействии и его видении требований. Все наладилось. Стоило лишь дать друг другу обратную связь.
***
Конечно, озвученные пять ошибок — не все, которые могут возникнуть на старте работы бизнес-аналитика. Но даже если начать проработку с них, мы уверены, что работа в команде станет эффективнее. Совершать ошибки — абсолютно нормально, это путь к совершенству, ведь мы постоянно на них учимся. Поделитесь, про решение какой проблемы в работе бизнес-аналитики вы бы хотели услышать в следующих статьях?
Полезные материалы
Бизнес-анализ
- Статья «Что такое бизнес-анализ»
- Александр Остервальдер «Построение бизнес-моделей. Настольная книга стратега и новатора»
- Александр Остервальдер «Разработка ценностных предложений. Как создавать товары и услуги, которые захотят купить потребители»
Интервьюирование пользователей, исследования и анализ рынка
- Гайд по проведению интервью «Алгоритм построения скрипта интервью»
- Книга: Роб Фитцпатрик «Спроси маму»
- Игорь Рызов «Я всегда знаю, что сказать»
- Рене Моборн «Стратегия голубого океана»
Soft skills
- Статья «Самая большая подборка по прокачке soft skills»
- Статья «Как «продать» технические задачи бизнесу»
- Статья «Problem Solving: как эффективно решать проблемы в команде?»
- Видео от TED про работу с фидбеком — The secret to giving great feedback | The Way We Work, a TED series
- Статья на Хабр «Как давать и получать обратную связь»
- Статья «Пять советов о том, как научиться спокойно принимать обратную связь на работе»
- Статья «Как устоять перед жесткой критикой»
- Книга: Нейл Фьоре «Легкий способ перестать откладывать дела на потом»
- Книга: Дэйв Креншоу «Миф о многозадачности. К чему приводит стремление успеть все»
- Дейл Карнеги «Как завоевывать друзей и оказывать влияние на людей»
***
Если понравилось, что генерируют наши нейросети, читай материал о том, чего стоит ждать до 2050 года от развития Human Augmentation.
Мы изучаем тему цифровизации со всех сторон и делимся наблюдениями и выводами на разных площадках. Чтобы ничего не пропустить, следи за развитием рынка цифры вместе с нами:
・VK
Да пребудет с тобой сила роботов! 🤖
Очень хороший материал, специально зарегистрировался, чтобы выразить респект.
Недавно устроился работать в новую компанию и одной из первых задач было как раз проанализировать работу одного продукта и указать точки роста, как можно увеличить конверсию.
Спустя несколько дней анализа я представил предложение руководителю и практически все они были утверждены, после чего было предложено начать их реализацию.
Несмотря на то, что сам алгоритм работы для меня не составлял труда, само направление было для меня новым и я всё-равно слабо ореинтировался, как быстро решать ту или иную задачу. В итоге начались те самые переработки в нерабочее время, чтобы закончить реализацию в разумные сроки.
Проект я конечно сдал, но практически сразу пришло понимание, что я так долго не протяну, если буду работать в таком же ритме. Поэтому теперь при реализации тех или иных задач, я как раз разбиваю одну крупную задачу на множестве подзадач и честно представляю руководителю, сколько это может занять времени по срокам у меня, с четкой аргументацией почему вот эта казалось бы огромная задача с учетом моих навыков решается очень быстро, а как-раз на второстепенную я потрачу слишком много времени. После чего, как раз совместно решаем, что стоит затраченных усилий, а что лучше выкинуть.
Ещё как раз было пару конфликтов с другим руководителем. Одной из моих задач, как раз является представление новых идей по развитию продуктов. Я стараюсь честно прописывать плюсы и минусы, тем не менее несколько раз получал отзыв, что дескать глупости это всё, зачем ты вообще это предлагаешь, причем совершенно без фидбека, что там собственно не так.
На третий раз пришлось лично обсудить с руководителем этот вопрос, что непосредственно вы мне и поставили вносить предложения для общего обсуждения. И если предложенное мною направление вам кажется ненужным или неуместными, то просто стоит конструктивно объяснить почему, а не отмахиваться на повышенных тонах рукой. Всё с тех пор стало вполне нормально, наконец-то стало возможно спокойно обсудить развитие, а полученный четкий фидбек (а не просто отмашка, что ерунду какую-то сделал) позволяет в будущем более четко понимать задачи.
На самом деле обсудить с начальство вопрос конструктивного фидбека стоит как можно раньше, если сталкиваетесь с такой проблемой. Иначе вы просто будете друг друга не понимать, вы будете считать начальника придурком, который сам не знает, что хочет, а он вас некомпетентным сотрудником. Фидбек и отзыв от руководителя это очень важный пункт, для качественной и комфортной работы.
Привет! Спасибо за обратную связь и за такие классные и подробные примеры: ваш комментарий — отличное дополнение к материалу)
Интересно и полезно.
Рады, что нашли для себя пользу!
Спасибо за статью
Спасибо, что читаете!
благодарю за статью!
чтобы поставить лайк и написать коммент не лень было восстановить пароль от vc
Отлично разжевано, примеры очень рабочие
За материалы в конце отдельное спасибо)
Дико извиняюсь, но это ошибки универсальны и подходят для любой профессии
Верно — с такими сложностями сталкивается большинство новичков, как раз об этом первый абзац материала :-) но на этапе проектирования эти ошибки могут стоить дороже всего, по нашему мнению.