Кто ты, IT-аналитик?

Не все работающие в IT — разработчики, да?

Вроде понятно, но как же часто приходится развенчивать именно этот стереотип…

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

Презентовать очень разным людям, зачастую далеким от мира технологий. Но каждый раз я впадаю в ступор — о чем рассказывать, если все и так понятно?



Сегодня я структурирую вводную информацию о специальности IT-аналитика. Расскажу про наиболее распространенные подвиды.

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

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

В зависимости от типа данных IT-аналитиков можно поделить на подвиды.



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

Итак, начнем:



Описание


Задачи — анализ и оптимизация бизнес процессов. Такой аналитик хорошо знает процессы своей компании (или направления, с которым работает). Понимает лучшии практики, конкурентов и узкие места бизнеса. Применяет свои знания, чтобы улучшать процессы.
Скилы — знания предметной области; управление требованиями; составление диаграмм бизнес процесса; коммуникативные навыки; качественные исследования и т.д.
Данные — бизнес процессы.

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





Описание


Задачи — перевод требований от бизнеса на технический язык. Хорошо знает, как устроена разрабатываемая система и софт вообще. Может читать код.
Скилы — технические знания; архитектура софта; техническая документация; проектирование систем и взаимодействие и т.д.
Данные — устройство разрабатываемой системы.

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




Описание


Задачи — в цифрах увидеть ответы и подсказки. Хорошо считает, знает математику и статистику. Обращается к базе данных и обрабатывает цифры с помощью подходящих инструментов (как правило R и Python).
Скилы — знания SQL, математики, статистики, умение работать с цифрами и делать на их основе выводы и т.д.
Данные — данные в распространенном представлении — цифры.

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





Описание


Задачи — понять, чего хотят посетители сайта. Хорош в системах web-аналитики (Google Analytics и Яндекс.Метрика). Делает выводы о поведении посетителей, проблемных местах и точках роста. Улучшает web-страницу и опыт пользователя.
Скилы — умение работать с системами web-аналитики, интерпретация данных, проведение А/Б тестов и т.д.
Данные — информация о работе с Web-страницами.

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





Описание


Задачи — дать пользователю логичный, простой и удобный опыт работы с интерфейсом. Изучает взаимодействие с системой. Улучшает пользовательский опыт и сценарии использования.
Скилы — понимание в дизайне, анализ пользователей, качественные исследования, А/Б тестирование, понимание шаблонов поведения и т.д.
Данные — информация о взаимодействии с интерфейсом.

UX-аналитик — выяснит какие действия вызывают у аудитории сложности или не очевидны для нее. Поможет понять, как упростить взаимодействие пользователя и системы.





Описание


Задачи — исследование продукта на предмет точек роста. На мой вкус выделять продуктового аналитика — дань моде, однако совсем проигнорировать эту роль и считать заметку актуальной тоже странно. Продуктовый аналитик — хороший пример микса из умений всех видов IT аналитиков. Из багажа знаний он берет наиболее действенные инструменты.
Скилы — качественные и количественные исследования; работа с метриками; воронками активации и т.д.
Данные — метрики продукта.

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





Подводя итог придется бросить ложку дегтя и лишний раз подчеркнуть - разделение подвидов IT аналитика довольно условное. От компании к компании названия различаются. Стоит смотреть на описание требований и уточнять ожидания на собеседовании.

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

Для понимания картины распределения IT-аналитиков прикладываю итоги опроса, который мы проводили внутри сообщества IT-аналитиков Новосибирска:


*Не аналитики — HR специалисты, Product и Project managers, Технические писатели и т.д

Быть прекрасным сразу во всех инструментах, специализациях и предметных областях невозможно. Правильная стратегия, если вы решили стать IT-аналитиком, выбрать в какой специализации вам интересно развиваться и не сворачивать с пути.

Удачи в карьере! Учитесь, развивайтесь и задавайте вопросы (я, кстати, всегда рад помочь)
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 8

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

    Был ли у вас такой опыт?
      0
      На эту тему, думаю, можно написать не меньше :)

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

      Каждый аналитик примыкал к своей функциональной команде (например BI, бухгалтерия, кадры и т.д. Мы делали ERP). Лидер аналитиков подбирал к командам аналитика, компетенции, которого именно в этой области будут наиболее подходящие. В BI нужно мапить данные, понимать как они взаимодействуют внутри куба — тут лучше системный; в колл-центре много неэффективных действий и нужно хорошо понять боль отдела — бизнес.
      Отдельно от всех стоял, разве что, интеграционный аналитик, т.к. он описывал все апи.
      В случаях, когда аналитику, более качающемуся в бизнесе, попадала тех. задача он просил помощи у коллег-аналитиков (ERP нарисовать, в базу залезть и т.д). Или если задача горела, то более системный брал ее на себя — детали уточнял у ответственного аналитика.

      Признаю — очень зависимая от сознательности людей система, но она работала.

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

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

      Почему же «дань моде», можете развернуть мысль?
        0
        Подчеркну, что это сугубо мое мнение (я не хочу холиварить :) )

        Дань моде, т.к. на все с приставкой «продукт-» сейчас повышенный спрос.
        Посмотрите на количество курсов Продукт менеджера. Однако, отзывы некоторых слушателей курса сводятся к выводу в духе — очень много навыков надо уметь, это нереально.
        Предложение развивается и хочет удовлетворить подобный профиль. Мы видим как форсятся роли продуктового аналитика, продуктового дизайнера, продуктового HR и продуктового + любое слово.

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

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

            Т.е. если под продуктом мы рассматриваем любой B2C, то обязанности и особенности будут приблизительно одинаковые. Неважно какая предметная область — доставка, маркетплейс или соц.сеть. (кроме тех предметных областей, которые совсем другие, но мы их уже дважды выделили).

            С другой стороны, если под продуктом понимать технологическое решение, то выделять здесь отдельную роль даже странно, а не только не удачно :)

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое