Кто такой IT-аналитик и зачем он нужен в разработке

Статья для тех, кто планирует стать IT-аналитиком в разработке или уже работает с аналитиком, но не понимает его роль в команде.

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

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

Работа аналитика начинается со сбора и структурирования информации — это фундамент. Любая информация, поступающая в команду разработки, должна проходить этап анализа и сбора недостающих фактов:

Наша компания разрабатывает облачные сервисы и AI-технологии. У нас есть несколько платформ, в том числе платформа искусственного интеллекта Cloud.ru ML Space. Разработкой этой платформы занимается несколько продуктовых команд, у каждой свое ML-направление, и в каждой есть свои аналитики. Так вот, в нашей команде я тот человек, кто работает над поступающими к нам запросами от заказчиков, коллег или пользователей. К примеру, одни хотят получить дашборд с нужными им метриками, другие пришли с идеей доработки сайта платформы, третьи ждут, чтобы я актуализировала для них техническое описание нашего сервиса. Все это нужно проанализировать, структурировать и обработать для дальнейшего принятия решения с командой.

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

Вы спросите, как научиться структурировать? Мой ответ таков: растить внутреннюю дисциплину. Банально, но это как в спорте, когда посещаешь тренировки стабильно в определенные дни. Это тоже структурирование, потому что приходится конкретно сортировать дела на важные и неважные и скорей всего просто «отсеивать» те, что не относятся к спорту. Когда я несколько лет подряд ходила на тренировки в зал три раза в неделю, мне приходилось структурировать жизнь так, чтобы спорт всегда вписывался в мой график — а как мы знаем, соблазны в моменте начинают искушать. Думаю, в тот период жизни у меня заложилась база человека-структуры и развился системный подход ко всему.

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

Удобнее показать собранную информацию коллегам наглядно, чем объяснять на словах, порой это даже нереально. Мне нравится излагать мысли в статьях и схемах. Кстати, статьи я пишу в корпоративной базе знаний, схемы обычно рисую в бесплатном сервисе Draw.io: его макрос уже встроен в нашу базу, и можно в одном месте писать текст и сразу в режиме редактирования рисовать схему. И далее одним кликом опубликовать всю статью — удобно.

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

У нас в компании часто бывают единые интеграции. Недавно мы реализовали сервис уведомлений для клиентов ML-платформы на сайте. Эта задача затрагивала не только нашу команду разработки, но и соседние. В таких рабочих историях у нас принято «шарить» собранный опыт для тех команд, кто только приступает к задаче. Здесь, например, мы первые интегрировались с сервисом нотификаций, поэтому я подготовила материалы для коллег из других команд, чтобы поделиться опытом с ними. Это поможет им не изобретать велосипед, лишний раз не набивать шишки и ускорить процесс выкатки в прод.

Не спорю, soft skills нужны всем членам команды, но у аналитика они должны быть встроены по дефолту. Это важно, так как на коммуникациях строится вся его работа.

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

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

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

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

Вы спросите, как научиться эффективно коммуницировать? Мой ответ таков: быть инициатором общения и не бояться задавать вопросы. Иногда мне кажется, что я спрашиваю глупость, но из этого получались груминг (обсуждение), идея в бэклог, рабочая задача.

Soft skills — это, конечно, хорошо, но в разработке на одних коммуникативных навыках не вылезешь. И не вывезешь 🙂

Аналитик должен обладать широкими знаниями технических инструментов. Ведь прежде, чем ставить задачу коллегам, нужно понять язык разработки и в целом весь жизненный цикл продуктовой команды: работу frontend и backend-разработчиков, этапы и сценарии тестирования, UI-дизайн. Если обобщить, то пользователь смотрит на UI (сайт), разработчики — в frontend и backend (код), а аналитик смотрит во все стороны сразу. И чтобы обладать таким «широким зрением», нужна техническая база.

Когда мой карьерный путь приблизился к профессии IT-аналитика, у меня уже были определенные technical skills: знание основ языка программирования Java и тестирования, опыт написания простых SQL-запросов и постановки задач в разработку, работа с технической документацией. Эти скилы, которые я получила до «входа в аналитики», помогли мне быстро адаптироваться в новой профессии.

Без технических знаний, считаю, в команде разработки будет тяжело. Когда я перешла на работу аналитиком в Cloud.ru, то меня заботливо предупредили: «Саш, будет сложно, но интересно». Так и получилось. Но было бы в разы сложнее, если бы у меня вообще не было опыта и пришлось бы в горящем режиме гуглить информацию про технические инструменты, например:

Такие технические вопросы задают на собеседованиях, но я к тому моменту уже была к ним готова. Когда я проходила собеседования в аналитики, то моя доска в Miro разрывалась от IT-«раскопок». И снова структурирование информации в конспекты, отрисовка схем и процессов — лайк!

Про важность soft skills я уже писала выше в разделе «Умеет общаться даже со сложными людьми», но хочу отдельно выделить коммуникацию с продуктовым менеджером (продактом) и архитектором.

В какой-то мере аналитик — это «демоверсия» архитектора, так как он мыслит в формате архитектурных схем и взаимосвязей с другими сервисами. По крайней мере, в моей голове это так. Невозможно представить IT-аналитика, не соприкасающегося с архитектурными схемами в своей работе. К примеру, если аналитик работает над сбором требований для реализации какой-либо фичи, то он так или иначе будет иметь дело со схемами. Это либо чтение уже отрисованных архитектурных схем, либо проектирование их самому. Но в последствии удобно будет всем, потому что:

Что касается взаимодействия продуктового менеджера и аналитика. Считаю, что им важно сработаться, они должны быть на одной волне, так как их рабочие задачи тесно соприкасаются. В классической схеме работы продакт коммуницирует с бизнесом (руководством) и приносит порцию задач в команду. Задачи декомпозируются на технического лидера (техлида) и аналитика, а уже далее после проработки требований и технической возможности отдается разработчикам, тестировщикам, техническим писателям и выкатывается в прод.

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

Еще одна важная роль аналитика – работа с бизнес-процессами, то есть поддержка существующих процессов в разработке и их оптимизация в режиме быстро меняющихся обстоятельств.

Именно быстрое реагирование на условия рынка или внутренние потребности компании помогает аналитику перестроить процессы и документацию под новые требования. То есть отразить в текущем процессе (as is) те изменения, которые будут внедрены в процесс после проведения каких-либо работ (to be). И тут вопрос: что изменится для пользователя, бизнеса и коллег?

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

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

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

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

Мой карьерный IT-трек разнообразный, до этого я работала менеджером в управлении инфраструктуры в крупной IT-компании, далее перешла в младшие QA-разработчики по автоматизации тестирования на Java, потом получила опыт работы руководителем сложных IT-проектов по РФ и СНГ, но в итоге пришла к тому, что хочу быть IT-аналитиком. Эта профессия такая многогранная, но в тоже время сбалансированная. Путей развития много, и об этом, пожалуй, я расскажу в следующий раз.

Надеюсь, моя статья привнесла толику ясности в то, кто такой IT-аналитик и зачем он нужен команде разработки. Благодарю коллег за помощь в подготовке материала и читателей за внимание. До новых встреч 🙂