Источник правды: как аналитик учит менеджера и разработчика работать вместе
Гости нового выпуска подкаста «Сушите вёсла» Вероника и Катя — бизнес-аналитики Redmadrobot. Они рассказали об особенностях своей профессии, различиях между видами аналитиков и назвали самый главный скилл, необходимый для достижения успеха.
Разработчики Redmadrobot Артём Кулаков и Рома Чорыев исследуют различные стороны создания ИТ-продуктов, делятся опытом и «вытягивают» из своих гостей самые ценные секреты профессии.
Прикладываем подкаст и ответы на несколько волнующих кровь вопросов.
Тайминг:
Откуда обычно приходят в эту профессию? — 1:13
Чем занимается аналитик? — 3:32
Какие бывают аналитики? — 7:50
Типичный день аналитика — 11:40
Где выучиться на аналитика? — 17:00
Специфика российского рынка — 20:37
Куда расти аналитику? — 24:55
Что почитать на вхождении в сферу? — 30:45
«Боли в профессии» — 36:20
Важность навыка общения — 40:00
Аналитик-фрилансер — реальность? — 45:48
Мифы о профессии — 50:40
Аналитик: как, зачем и почему
Аналитик связывает менеджмент, клиента и разработчиков, общаясь с каждым их них на понятном языке. Например, разработчик не мыслит показателями бизнеса вроде KPI, а бизнес не оперирует методами или архитектурами. Именно этот коммуникационный барьер заполняет аналитик.
Если коротко, аналитик — это специалист-универсал, который общается с дизайнерами, разработчиками, менеджерами или тестировщиками. У нас, к примеру, бизнес-аналитик еще и может отстаивать позицию наравне с менеджером или взаимодействовать с дизайнером.
Как правило, в аналитики приходят с дипломом по бизнес-информатике или программной инженерии, много ребят из ВШЭ. По словам гостей Вероники и Кати, у таких специалистов есть базовое понимание бизнеса и языков программирования, а также того, «как все это должно работать».
Из книг наши гостьи посоветовали Руководство к Своду знаний по бизнес-анализу (BABOK), а также труды Карнеги и Гоулмана для прокачки навыков общения.
Кстати, о «гуманитарщине». Несмотря на технический уклон, в аналитику идут и люди из непрофильных профессий: например, проектные менеджеры. Бывают и более экзотические варианты: сфера IT привлекает людей из многих сторонних отраслей.
А есть ли специализация в профессии?
Как объяснили гости подкаста, нельзя мешать все процессы в одну кучу, поэтому аналитики тоже могут придерживаться определенной специализации:
- Бизнес-аналитик опирается, скорее, на бизнес-подход: напрямую работает с KPI, больше проводит времени на встречах.
- Системный аналитик работает на уровне нескольких систем и их интеграций между собой.
- Продуктовый аналитик, скорее, математик. Он отслеживает, как развивается продукт с точки зрения цифр, коммуницирует больше с product-owner, но общается в том числе и с разработчиками.
- Интеграционный аналитик. Как правило, они есть на очень сложных проектах. Их задача — анализировать спецификации и выполнять отчасти роль архитектора.
Какой он: типичный день аналитика
Бизнес-аналитик, сталкиваясь с задачей, понимает: менеджер не вникнет до конца в суть проблемы, например, как будет работать та или иная фича, и, следовательно, предъявит много вопросов к разработчикам. Аналитик выстраивает коммуникацию с заказчиком с целью понять, чего тот на самом деле хочет.
Аналитик — он про анализ ситуации и понимание, как дальше ее выруливать. Он смотрит на метрики, понимает, что был какой-то провал. Он общается с клиентом, пытаясь найти ответ на вопрос «что сделать, чтобы не допустить провала?
После того, как позиция и требования заказчика ясны, аналитик предлагает варианты оптимизации или способы добиться желанного результата минимальными усилиями.
Необходимо отметить, что в некоторых компаниях аналитик совмещает несколько ролей, выполняя обязанности менеджера или QA. В зарубежных структурах, как сказала Катя, зачастую нет аналитика, есть только product-owner и разработчик, которые общаются напрямую.
Куда расти дальше
Карьерный рост — неотъемлемая часть профессионального развития. Как рассказали гостьи подкаста, перед бизнес-аналитиком открыто немало путей.
Есть несколько путей развития. Либо стать ведущим старшим бизнес-аналитиком, либо пойти в бизнес, стать product-ом, например, либо пойти менеджером в проекты.
Она добавила, что человеку может «надоесть» быть аналитиком, и, при условии сохранения скилла, ему открыт путь в разработчики. Катя же отметила, что с пунктом «бизнес-аналитик» в резюме можно даже «поднатаскаться» на аккаунт-менеджера или архитектора.
Как бывают трудности
Как призналась Вероника, главный навык в скиллсете ее профессии — умение задавать глупые вопросы. Это важный психологический момент: ведь боязнь выглядеть «не так» сразу может свести на «нет» работу, и ошибка будет заметна только в финальном продукте. Учитывая, что иногда работа ведется сразу над несколькими фичами, держать в голове весь массив информации становится трудно.
Если ты сам этого не понял, как передавать информацию своим коллегам? Ты не можешь такого допустить, поэтому спрашивать нужно до тех пор, пока все не станет ясно. Нужно спрашивать. Даже если ты уже всем надоел.
Еще один «минус» — невозможность работы на фрилансе. По словам Вероники и Кати, в их профессии должен быть максимальный уровень «доверия, воспитанности, интеграции в команду». Когда этого изначально нет, общаться удаленно очень сложно — преодолевать коммуникативный барьер намного эффективнее при личном контакте.
Развенчание мифов
Говорят, что бизнес-аналитик в IT-компании должен иметь опыт разработки или IT-образование.
Мнения наших гостей по этому вопросу разошлись: Катя считает, что это желательный, но необязательный пункт, в то время как Вероника выступила за непременное наличие IT-образования.
При этом наши эксперты опровергли необходимость наличия опыта разработки, а также умения работать в UML. А самым обидным Катя назвала миф о том, что «бизнес-аналитик нужен только для того, чтобы написать спеку». Последнее стоит особенно тщательно запомнить: пригодится в общении с коллегами.
Слушайте подкаст на удобной платформе: Soundcloud, Apple, Google Podcasts.
Полезные материалы
- Классика BA литературы: Разработка требований к программному обеспечению. К. Вигерс, Д. Битти,
- Все ещё актуальная книга: «Как завоевывать друзей и оказывать влияние на людей. Дейла Карнеги»,
- Полезно для понимания, как взаимодействовать с разными людьми на проекте — эмоциональный интеллект. Д. Гоулман,
- Тот самый "BABOK".
Предыдущие выпуски подкаста «Сушите вёсла»
QA для начинающих: как протестировать ракету или самолёт,
Архитектор ПО: зачем он нужен и в чём его проклятие,
CTO всея стартапа.
Приходите обсуждать выпуск в Telegram-чат.
Добавлю токсичности.
Послушал подкаст.
Они вообще не бизнес аналитики: 80 процентов скорее системные аналитики и только 20 бизнес. Не предпочитают UML, а-ля можно как угодно описывать требования, но для этого и придумали унифицированную спецификацию, чтоб всем было понятно. Конечно можно и текстом описать use case для разработчика, где будет основной правильный сценарий и альтернативные/ошибочные. Системный аналитик это НЕ только меж системное взаимодействие, а вообще про работу системы, например, что по нажатию на эту кнопку происходит вот это. Он как раз в основном общается с разработчиками, в том числе и дизайнерами.
Бизнес аналитики снимают именно текущее состояние и желаемые функции, а не только показатели. Все это желательно фиксировать в популярной нотации. Они больше аудиторы (as is) и консалтинг (to be). И я склоняюсь, что нужно иметь it background, чтоб не наобещать сделать то, что не реально или долго и дорого.
Про бабУк это не книга(book-бук), а аббревиатура также как и PMBOK, который уже пишут во все вакансии на PM - только сдать экзамен гораздо сложнее. На западе и в big 4 очень ценится BABOK именно для бизнес аналитиков. В РФ зачастую в IT нужны просто грамотные техписы, поэтому и такие зарплаты, но современные компании понимают, что системный аналитик сильно сокращает трудозатраты разработчиков. На западе популярен CusDev, поэтому и появился спрос на аналитиков. Действительно мало универсальных аналитиков, которые могут грамотно общаться и с заказчиком и с командой, вот тут как раз образование и background даёт перевес в одну сторону.
Системным аналитиком фрилансером быть сложно, а вот бизнес аналитиком можно оказывать аудит и консалтинг услуги без взаимодействия с командой.
А теперь ‘боль’ - трудно стать product owner без помощника, который будет выдавать результаты (писать скрипты, делать ux макеты) гипотез для анализа. В плане развития - системный аналитик может стать и тех. директором (CTO), а бизнес аналитик стать директором по развитию.
Итого нужно четко понимать кто ты: системный, продуктовый или все таки бизнес аналитик.
На самом деле у нас нет разделения на бизнес-аналитиков и системных аналитиков. У нас в компании мы используем UML (и знаем его), когда он действительно нужен.
Но как показывает практика, во многих кейсах описания требований избыточные схемы могут их только усложнить. Если функционал сложный, то, конечно, мы как аналитики описываем требования в схемах, в том числе используем UML. Тут, главное, без фанатизма, потому что иногда использование нотаций к любым требованиям может их усложнить.
Поэтому хороший аналитик должен понимать, когда стоит использовать нотации, а когда нет. BABOK — это свод знаний, найти можно в виде книги, пересобирается каждый год. Действительно, нужно четко понимать, в какой области ты больше хочешь развиваться, но при этом стараться быть подкованным в любой из областей аналитики, чтобы делать качественный продукт.
Я откланивался от термина применяемого на протяжении всего подкаста, что это бизнес аналитики, хотя 80/20 они скорее системные аналитики. И если развиваться как бизнес аналитики, то это совсем не те скиллы, которые были перечислены.
Про UML: в подкасте говорили, что придумали ‘своё’, а я лишь отметил, что нотации как раз обобщают популярные случаи и логичнее использовать их, при этом никто не мешает адаптировать под свои нужды. В постановках задач для разработчиков Вы как я понял применяете ‘шаблон’ use case из Confluence. Учтивая Ваше портфолио - нужно было делать много около ГОСТовых документов, где одним текстом не обойдёшься и функциональность верхнего уровня нужно было ‘рисовать’.
про BABOK: указал лишь на что как и с PMBOK в разговоре жонглируют термином ‘бук’ как будто две буквы OO.
Из содержания статьи получается, что бизнес-аналитик - это такой посредник в коммуникациях между заказчиком и разработкой, который еще анализирует и разруливает "ситуации", а сбор-анализ-формализация требований и рисование UML - это так, между делом. Ну-ну...
Настоятельно рекомендую вашим аналитикам внимательно почитать книгу "Software Requirements" от Microsoft (которая, к слову, указана в списке полезных материалов) и больше не вводить людей в заблуждение.
Главная книга это ‘завоевывать друзей’ или другие рекомендации SMM менеджера )))
В подкасте мы рассказывали именно про наш опыт бизнес-аналитики, понятное дело, что он варьируется от компании к компании.
Действительно, формализация требований, описание схем — это важная часть нашей работы, но, как показала наша личная практика, хороший бизнес-аналитик умеет понимать, при решении какой задачи необходимо уделить больше времени коммуникации, сбору требований и общению, а при решении какой нужно больше проектирования и формализации требований.
Этап коммуникации важен, так как именно на нём можно закрыть часть вопросов, которые потом не придется описывать в требованиях и уточнять. Принцип Парето в действии 🙂
В книге Вигерса (Разработка требований к программному обеспечению) об этом тоже говорится.
А сколько получают у Вас бизнес аналитики? Пропорционально разработчикам и руководителям проектов?
Нашёл здесь Вашу вакансию 80 и это наверное ещё до налогового вычета. Итого пол разработчика
Виктор, в нашей вакансии указана цифра после вычета налогов.
Спасибо, что обратили внимание. Мы указали минимум для младшего аналитика. Поправим)
Если не секрет- сколько у Вас аналитиков?
Не секрет. В московской команде 13 аналитиков.
Интересно как ‘младший’ должен уже иметь опыта от 2х лет... Всегда радуют такие а-ля стартовые позиции с необходимым конкретным опытом - не хватает только ‘портфолио с 10 успешными крупными проектами’
В бизнес аналитики из РП, а потом развитие из аналитиков в РП = замкнутый круг получается. Хороший аналитик может стать product owner, но на это слишком много сейчас Хайпа - уже все хотят стать owner. Мое личное мнение, что Аналитику в IT обязателен нужен именно опыт в IT, а то это ещё хуже чем РП без опыта в IT !!
Есть рост вертикальный, есть горизонтальный.
Если ты решил стать бизнес-аналитиком из смежных профессий, то твой следующий шаг развития — прокачка навыков именно в бизнес-аналитике.
Если ты бизнес-аналитик и решил расти в управление, то логичный для тебя шаг — перейти в руководители проектов.
Никакого противоречия тут нет, могут быть разные траектории развития.
Мы согласны с тем, что хорошему аналитику нужно иметь опыт в IT.
Почему то считается популярным развитием из аналитика в РП. Но лично для меня это сильно разные сферы отвественности, например, не хочу отвечать за финансы и договора проекта. И как раз подметил, что если ты пришёл в аналитику из РП, то развитие в РП будет замкнутым кругом.
Комментарий недоступен
Комментарий удален модератором
Комментарий удален модератором