Если вы задумались о разработке своего сайта или приложения, то уже наверняка знаете, кто должен входить в команду. Это, конечно, разработчики, тестировщики, менеджер проекта, который следит за всем и предоставляет отчеты, и, как минимум, один аналитик. И если остальные ключевые роли и их важность на проекте обычно не вызывают вопросов, то роль аналитика и его задачи понятны не всем. В этой статье мы с аналитиком Марией Плотниковой решили разобраться на конкретных примерах, какие IT-аналитики существуют и какую роль они играют на проекте.
Прежде всего, понятие аналитики очень широкое. Даже если говорить только о сфере IT, то есть ряд направлений: бизнес-аналитика, системная аналитика, UX-аналитика, продуктовая, digital intelligence… Мы в компании Siberian.pro сфокусировались на трех областях, а именно системной, продуктовой и бизнес-аналитике. О них и расскажем подробнее.
Бизнес-аналитика
Чем занимается бизнес-аналитик?
Специалист в этой области не обязан в деталях знать технические особенности и тонкости разработки. Задачи бизнес-аналитика — изучить предметную область и ее особенности, понять проблему заказчика и предложить эффективный способ решения. Как правило, в запросе на оценку дают готовые варианты, тем не менее, хороший аналитик подскажет, как те же проблемы решают конкуренты, где могут возникнуть сложности или узкие места.
Ты не угадаешь что выведет эта программа на python №16
Помимо этого, задача бизнес-аналитика — продумать все варианты развития событий. Например, в запросе от заказчика часто описан только положительный сценарий.
Допустим, нужно создать такси-агрегатор. Основной сценарий понятен: пользователь указывает, где он находится и куда нужно попасть, система подбирает машину, пассажир доезжает до места и оплачивает заказ картой либо наличными. Кажется, все просто. Но как быть, если машин мало или ни один водитель не хочет брать заказ?
Если у водителя или пассажира плохой интернет и невозможно отследить местоположение? Если по пути пассажиру перезвонили и надо ехать на другой конец города? Да, это, скорее, исключения, но система должна уметь с ними работать. Хороший аналитик опишет решение для таких случаев.
Что будет в результате работы?
Результат работы бизнес-аналитика — описание верхнеуровневых бизнес-требований (ВБТ), техническое задание (ТЗ) с описанием сценариев в формате use cases и user stories, при необходимости дополненные схемами и диаграммами. Точный список зависит от проекта.
Например, исходное описание нового раздела для ритейл-сети может выглядеть так:
«Добавляем в приложение список покупок. Пользователь записывает туда товары, которые собирается купить, при вводе должны появляться подсказки об акциях. В магазине, добавив товар, пользователь может его вычеркнуть. Вычеркнутые товары можно скрыть или удалить, чтобы не мешали. Если пользователь использует разные устройства, списки должны синхронизироваться».
Бизнес-аналитик распишет эти требования на несколько страниц, попутно указав все возможные сценарии, позитивные и негативные, опишет логику подсказок, которые появляются при поиске товара, продумает тексты для всех заглушек, поп-апов и ошибок.
Ты не угадаешь что выведет эта программа на python №24
Как это поможет проекту?
Описание бизнес-требований — один из основных артефактов проекта, который поможет решить сразу ряд задач.
- Если вы выбираете подрядчика или оцениваете целесообразность разработки, то чем точнее описаны требования, тем меньше разброс в оценках подрядчиков и ниже вероятность, что в ходе разработки появятся дополнительные расходы.
- Большая часть компаний отказывается разрабатывать проекты без предварительного этапа аналитики либо соглашается, но только по модели TimeM
Вы можете сэкономить на бизнес-аналитике, выбрав вместо тяжеловесной разработки по модели Fix Price более гибкую разработку на основе TimeGo. Её суть в том, что покупатель в торговом зале сканирует штрихкоды, складывая товар в корзину, оплачивает в приложении и выходит с покупками, минуя кассы. На тот момент это была передовая технология, набиравшая популярность на Западе.
Наши аналитики начали анализ конкурентов и рисков безопасности и занялись проработкой ТЗ… когда грянула пандемия. Количество покупок в магазинах упало в разы, а доставка стала пользоваться небывалым спросом. Работы в направлении Scanhttps://vc.ru/u/705929-vlad-karmakov/251544-kakova-rol-analitika-i-ego-zadachi-pri-razrabotke-mobilnyh-prilozheniy» target=»_blank»]vc.ru[/mask_link]
Системный аналитик: что делает, сколько получает и как им стать
Системный аналитик помогает оптимизировать и автоматизировать работу компании и её подразделений. Этот специалист разбирается в менеджменте, экономике и информационных технологиях — помогает скоординировать процесс разработки ПО так, чтобы результат был максимально продуктивным.
Рассказываем, чем занимается системный аналитик, что он должен знать и уметь, сколько зарабатывает, как войти в профессию и какие доступны карьерные возможности.
Благодарим за помощь в подготовке материала Ксению Шипину, системного аналитика Skyeng и преподавателя курса «Системный аналитик» в Нетологии.
Ксения Шипина
Системный аналитик Skyeng
Системный аналитик — IT-профессия широкого плана
Системный аналитик — это специалист, который изучает бизнес и определяет, как можно сделать его эффективнее с помощью внедрения информационных систем.
Его можно назвать посредником между заказчиком — руководством компании — и исполнителем — разработчиком.
Итог такого сотрудничества — программный продукт.
Такое определение близко к истине, но не универсально. У проблемы трактовки есть несколько причин.
Основная причина — различия в требованиях разных компаний к специалисту.
Другая причина — разница в развитии IT-рынков в России и в мире. Впервые термин «системный анализ» ввела в 1948 году некоммерческая организация RAND, которая в 1956 году выпустила книгу на эту тему. В 1959 году американские предприниматели Рой Натт и Флетчер Джонс основали первую компанию по разработке ПО — Computer Sciences Corporation. И многие практики задумались о том, что основы системного анализа можно использовать в разработке.
Это дало свои плоды — спрос на системный анализ начал расти. В 1976 году была разработана технология Waterfall, позволяющая оптимизировать процесс разработки ПО.
В России и странах ближнего зарубежья развитие IT-рынка началось позднее. Разработка первых программ для коммерческого использования ЭВМ стартовала только в 1980 году. А индустрия информационных технологий начала развиваться только в 1990-х — после распространения первых ПК.
На протяжении долгого времени на российском рынке не было кузницы кадров. Системные аналитики начали появляться в России в начале 2000-х, а профессиональные стандарты появились лишь к 2014 году.
Профессия системного аналитика окончательно оформилась как самостоятельная и стала востребованной по нескольким причинам:
- При зарождении IT-рынка выделенной роли аналитика не было, но потребность в системном анализе присутствовала всегда. Зачастую анализ выполнял смежный специалист, но не всегда успешно.
- Рост конкуренции на рынке ПО тоже оказал влияние. По разным причинам многие проекты завершались неудачно: компании вкладывались в невостребованные решения из-за недопонимания между заказчиком разработки и исполнителем. Так возникла потребность в специалистах с хорошим техническим бэкграундом и развитыми soft skills, которые могут правильно понять боли бизнеса и оптимизировать процесс разработки.
- Усложнение программ сыграло свою роль — для грамотной интеграции ПО нужны узкоспециализированные специалисты.
Чем занимается системный аналитик и что он должен уметь
Основная задача системного аналитика — разработка информационной системы, которая соответствует потребностям компании и позволяет наладить бизнес-процессы. Он разрабатывает список задач и доносит их команде так, чтобы у коллег было чёткое представление о целях и методах их достижения.
Что делает системный аналитик:
- собирает и анализирует требования исходных программ, проводит интервью с заказчиком;
- согласовывает требования и управляет их изменениями, включая мониторинг изменений требований для предотвращения противоречий;
- составляет проектную, техническую, пользовательскую документацию, фиксирует потоки информации во избежание путаницы;
- презентует работу заказчику;
- синхронизирует контекст команды и заказчика: обеспечивает качественную коммуникацию, сводит к минимуму конфликты.
Для выполнения рабочих задач специалист должен владеть определёнными компетенциями:
- понимать базовые принципы разработки ПО;
- уметь определять границы систем и зоны их ответственности — для анализа возможностей и ограничений;
- знать, как выделять подсистемы и их функции;
- уметь находить явные и неявные требования — для поиска решений;
- обладать навыками моделирования — для визуализации процессов.
Процесс разработки — это постоянный обмен информацией. Чтобы правильно запрашивать и ясно доносить её, системному аналитику важно развивать и soft skills.
В разных сферах предъявляют разные требования к системному аналитику
На примере вакансий рассмотрим требования работодателей в различных областях.
В банковской сфере системному аналитику понадобится понимание бухгалтерского учёта, экономики, а также знание информационной безопасности для анализа дополнительных требований к банковскому ПО.
В ритейле при автоматизации процессов часто используют клиент-серверные системы, поэтому системный аналитик должен понимать соответствующие требования и архитектуру. Опыт разработки прототипов поможет создавать пользовательские интерфейсы для удобного общения пользователя и программы.
Для сферы кибербезопасности важно разбираться в системах шифрования и защите данных.
Осваивать всё сразу необязательно: профессия быстро развивается — стремительно меняются и тенденции.
Что отличает системного аналитика от других профессий
Аналитика — широкая сфера деятельности. Расскажем об отличиях системного аналитика от схожих и смежных профессий.
Бизнес-аналитик
Граница между бизнес- и системным аналитиком сильно размыта: часто обязанности этих специалистов смешиваются. Но бизнес-аналитик больше сфокусирован на оптимизации бизнес-процессов, снижении издержек и увеличении прибыли за счёт автоматизации. Он разрабатывает решение и передаёт системному аналитику, который перекладывает это решение на техническую реализацию и помогает команде понять, что должно получиться в результате разработки.
Аналитик данных
Аналитик занимается Big Data: умеет обрабатывать сырые данные и строить гипотезы на этой основе. Аналитик данных работает с метриками, системный аналитик — с процессами. Для первого знание Python необходимо, для второго — будет плюсом.
Project-manager
Системный аналитик переводит собранные требования в задачи на разработку. Project-manager контролирует ход проекта, согласовывает сдвиги в плане, управляет ресурсами и рисками.
Product-manager, Product owner
Product-manager отвечает за стратегию продукта — от выдвижения гипотезы до анализа результатов. Он знает, что нужно пользователю, а системный аналитик понимает, как это сделать.
Системный архитектор
Системный аналитик продумывает строение системы, а архитектор её создаёт. Системный архитектор проектирует архитектуру таким образом, чтобы разрабатываемая система не только удовлетворяла текущим требованиям бизнеса, но и могла гибко расширяться и модифицироваться при возникновении новых потребностей.
Технический писатель
Технический писатель отвечает за документацию. В обязанности системного аналитика тоже входит подготовка документов, но круг его обязанностей намного шире.
Кто такой бизнес-аналитик и как помогает компаниям быть на шаг впереди
Сколько зарабатывают системные аналитики
По данным Glassdoor, средняя зарплата системного аналитика в Москве — 150 000 рублей:
Согласно данным Хабр Карьеры, в 2020 году медианная зарплата специалистов по России составила 100 000 рублей:
На HeadHunter на момент написания статьи за месяц по России размещено более 3 000 вакансий по запросу «Системный аналитик» с зарплатой от 75 000 рублей:
Американский новостной журнал US News and World Report поставил эту специальность на 5-е место в списке лучших технических профессий. По данным издания, в 2019 году медианная зарплата системного аналитика в Америке составила $91 000.
Системный аналитик может расти как вертикально, так и горизонтально
Системный анализ — сфера деятельности, которая находится на стыке нескольких диджитал-сфер, и это открывает большие карьерные перспективы для специалистов.
Вертикальный рост не отличается от традиционного для интернет-профессий: стандартные Junior, Middle и Senior — это младший, старший и ведущий аналитики, далее — руководитель отдела аналитики.
А вот возможности для горизонтального развития шире:
- опытные системные аналитики часто становятся системными архитекторами — большой опыт проектирования систем и знания предметных областей бизнеса помогают им решать сложные архитектурные задачи;
- многие специалисты становятся проджект-менеджерами — так сложилось, что на рынке эти направления часто пересекаются, что делает подобный переход обоснованным и достаточно простым;
- аналитики часто сталкиваются с проблемами пользователей, и иногда желание помочь и решить эти проблемы перерастают в закономерный переход на позицию владельца продукта.
Но этим карьерные возможности не ограничиваются. Поскольку системный аналитик обладает большим количеством навыков, он может перейти в практически любое IT-направление: например, в разработку, тестирование, техническое писательство.
Как стать системным аналитиком
В вузах образовательная программа по специальности «Системный анализ и управление» сформировалась только в 2015 году, однако эксперты в этой нише появились куда раньше.
Тем, кто хочет попробовать себя в новой профессии, необязательно идти в университет — обучение на системного аналитика можно пройти и удалённо. Кроме того, онлайн-программы адаптируются под быстро меняющийся рынок и дают студентам дополнительные полезные навыки.
Если присматриваетесь к профессии системного аналитика, предлагаем обратить внимание на курс «Системный аналитик» в Нетологии. За период обучения вы освоите различные технические навыки, получите опыт решения практических задач, научитесь работать в команде. Это позволит стать участником команды по разработке продукта и перейти к интеграции сложных систем.
Лучшие выпускники курса пройдут собеседование в компании «Спортмастер».
Источник: netology.ru
Кейс: как построить отдел аналитики в большой компании?
Слово «аналитика» происходит от древнегреческого άναλυτικά, что означает искусство анализа. Это была часть более широкого понятия логики, рассматривавшая процесс познания как разложение целого на составные части с целью более детального изучения.
К первым аналитикам можно отнести знаменитых философов того времени Платона и Аристотеля. Но во всех странах были люди, владевшие сведениями и знаниями, недоступными большинству людей, и способные правильно их трактовать и интерпретировать. Такие люди, по своей сути были аналитиками, что очень ценилось власть предержащими, поскольку помогали им принимать более взвешенные и рациональные решения.
Современный мир не остался в стороне, аналитики работают и в правительствах и в коммерческих структурах. На данный момент практически невозможно найти более или менее серьезную компанию в которой не было бы аналитика, потому что если ты не владеешь информацией и не делаешь из нее выводы, ты закрываешься.
Видов аналитики на данный момент появилось достаточно много (о чем частично мы рассказывали в этой статье) — это бизнес-анализ, системная аналитика, продуктовая аналитика, BI и тд. Но так как я работаю в сфере digital, то речь пойдет именно о аналитике данных и всем что с этим связано.
Так зачем же компании работающей в цифровой среде аналитика?
В реальности бизнесу неинтересны показатели просмотров рекламных объявлений, кликов по ним, количество событий на сайте и прочие непонятные вещи. Бизнесу интересны деньги (неожиданно, правда ). И с его точки зрения, аналитика это — способ быстро и качественно сделать вывод о результативности маркетинга и его процессов для принятия решения.
Следовательно, аналитика нужна бизнесу для того чтобы:
- закупать качественный трафик и оптимизировать расходы;
- развивать продукты и увеличивать удовлетворенность пользователей;
- развивать дополнительные каналы привлечения пользователей;
- оцифровывать и считать ключевые метрики;
- выводить и отслеживать эти метрики на дашбордах.
Но хотелось бы более системно осмыслить роль аналитики на пути клиента при соприкосновении с бизнесом и тех знаниях которые мы получаем на каждом из этапов этого пути:
- Любой клиентский путь начинается с привлечения — это тот этап, на котором пользователь знакомится с компанией и ее услугами посредством digital или offline-рекламы. На этом этапе аналитика может быть полезна при сборе и анализе данных о расходах.
- Вторым пунктом клиентского пути является посещение — это этап, на котором пользователь попадает на наш сайт или мобильное приложение. И тут мы уже знаем о источнике трафика приведшего клиента, а также о его идентификаторах (Client ID, User ID и тп).
- На третьем этапе пользователь совершает какие-то действия, например, изучает каталог и знакомится с описанием товаров. Тут аналитика ответственна за сбор данных о событиях.
- Некоторые действия являются конверсиями и переводят посетителя в статус клиента. На этапе конверсии аналитика помогает с анализом данных о доходах, а также при построении различных моделей атрибуции, для того чтобы честно оценить вклад каждого из источников трафика в достижение конверсии.
- Между этапом действий и конверсий мы можем проводить A/B-тесты направленные на увеличение Convertion Rate и здесь возникают знания о экспериментах, которые необходимо анализировать и интерпретировать.
- После совершения конверсии клиентский путь не заканчивается и он переходит на этап возврата, в котором аналитика ответственна за сбор данных о аудиториях и сегментах для загрузки в ретаргетинговые и crm-системы.
И теперь давайте дадим определение digital-аналитики:
Это метод анализа эффективности маркетинговых инвестиций на основе данных, прослеживающий полный путь клиента и систематизирующий знания о нем на всех этапах, начиная от просмотра рекламного объявления, посещения ресурса и заканчивая продажей, с дальнейшим анализом возврата пользователя в воронку.
Мой старт, какие вызовы стояли?
Осенью 2017 года я получил предложение о работе на позицию веб-аналитика в компанию Сравни.ру. Это сейчас Сравни крупнейший финансовый маркетплейс с лицензией ЦБ и десятками миллионов посетителей в месяц, а тогда это был сравнительно небольшой сайт с единственной вакансией аналитика во всей компании.
Параллельно с предложением от Сравни, я получил оффер от весьма именитого агентства. Передо мной встала диллема — идти работать в крупное агентство с большим спектром задач и разными клиентами или на текущее место работы, мой выбор пал на сторону клиента. Я четко осознавал риски «застоя» при работе на клиентской стороне и был заряжен на саморазвитие. Благо, работодатель поддержал мои стремления к росту и постоянной прокачке, благодаря чему и Сравни.ру стал получать профиты в виде выстроенной системы web/app-аналитики, собственного BI-инструмента, появлению A/B-тестирования и прочих аналитических радостей.
Придя в компанию я попал в отдел маркетинга и застал аналитику в весьма удручающем состоянии — вся аналитика состояла из отчета по контекстной рекламе в Google Sheets, на подготовку которого ежедневно необходимо было тратить два часа, руками выгружая данные из Google Analytics и рекламных кабинетов.
Трекинг рекламных кампаний и Google Analytics был настроен весьма странно — utm-разметка использовалась по наитию, невозможно было понять, что означает то или иное событие, не был настроен импорт расходов и тп.
Соответственно передо мной стояли следующие вызовы:
- разработать единый стандарт utm-разметки рекламных кампаний;
- провести аудит текущей системы событий и разработать новую;
- провести аудит настроек Google Tag Manager — убрать лишние теги и внедрить подход «одна система — один тег»;
- обеспечить бесшовный переход со старой системы событий на новую;
- избавиться от ежедневного ручного сбора отчета по контексту и автоматизировать его.
Закатав рукава, я приступил к реализации плана.
Аудит всего — от трекинга, до отчетов
UTM-метки и единый стандарт
Выстраивание аналитики в любом новом проекте всегда стоит начинать с аудита текущей utm-разметки используемой в рекламных кампаниях для привлечения трафика на сайт. И часто, уже даже на данном этапе, можно найти столько детских ошибок и откровенных косяков, что иногда ты искренне не понимаешь, как оно вообще работало и даже окупалось.
UTM-метки на самом деле, являются одним из важнейших элементов так называемой «сквозной аналитики», без которых она работать не будет. А все потому что это не просто параметр в ссылке — после перехода на сайт параметры utm, содержащие источник/канал и много другой полезной информации, фиксируются системами трекинга и далее на этих данных строится вся аналитика по показам, кликам, конверсиям и расходам на маркетинг. Но это еще не все, далее эти параметры попадают в базы данных и CRM-системы, после чего на основе информации о закрытых сделках и продажах в разрезе источников принимаются решения о увеличении бюджета, либо остановке той или иной рекламной кампании.
Поэтому ваша первостепенная задача как аналитика — это составить простой и понятный документ содержащий правила utm-разметки, а также получить обещание от всех соблюдать этот стандарт. Пример такого документа можете посмотреть здесь. Понятно, что эти правила будут скорей всего уникальны для разных типов бизнеса и компаний, но есть общие принципы, соблюдая которые вы сведете возможность ошибиться к минимуму:
- Название источника ( utm_source ) обязательно должно быть заполнено и являться краткими, но релевантными;
- Лучше всего, использовать домен в качестве имени источника;
- Выбирая название для канала ( utm_medium ), следуйте настройкам каналов по умолчанию в Google Analytics;
- Самая большая ошибка, которую можно допустить — это неправильно разметить каналы, так как это самый важный тег для правильной группировки в системах трекинга;
- Все utm-метки всегда пишите строчными (маленькими) буквами;
- Перед внедрением какой-либо новой метки, необходимо проверить не используется ли она уже в другом варианте.
Более подробно о UTM-метках, читайте в одном из уроков бесплатного курса «Digital-аналитика для новичков», а также в моей статье «Все что вы хотели знать о UTM-метках, но боялись спросить».
Google Tag Manager и система событий
Первый аудит GTM закончился неожиданно…
Я решил переделать передачу Client ID в Google Analytics через customTask по методу, который был описан в блоге Simo Ahava, вечером зарелизил свежую версию тега в GTM и со спокойной душой ушел домой… Но результате моих действий наш сервис подбора кредита оказался парализованным и почти сутки тестировщики не могли найти в чем причина. А дело было в том, что в прошлой версии Client ID получаемый из cookies использовался для передачи в одном из полей формы заявки на кредит и каким-то образом все это было подвязано на GTM
Пришлось срочно все откатывать назад и подойти к аудиту трекинга более обстоятельно.
Из данной ситуации можно сделать два вывода:
- Любой процесс всегда нужно опрозрачивать, чтобы все (продукт, маркетинг) были в курсе планирующихся изменений и они не стали для них неожиданностью;
- Любое изменение должно проходить через этап тестирования к которому необходимо подключать сам продукт.
Вторая попытка оказалась успешней.
Была составлена карта событий, которые трекались на тот момент, но какой-то системности в них не было. Далее были опрошены product owners каждого из продуктов на предмет того, что бы им хотелось отслеживать и чего сейчас не хватает в плане аналитики. После этого я составил новую карту событий, построенную на следующих принципах:
- Учтён маппинг со старыми событиями, чтобы не пострадала аналитика по продукту;
- Единая событийная модель для всего сайта;
- Одинаковые действия (Event Action) в разных продуктах, должны называться одинаково;
- Унифицированный стиль именования событий — какой используется регистр, заменяются ли пробелы и тп.;
- Учет версионности — каждое изменение в карте событий должно отражаться;
- Доступная для всех документация с примерами кода для разработчиков.
Пример карты событий можно посмотреть по ссылке.
После составления карты, сразу были поставлены и запущены задачи во всех продуктах по переезду на новую систему. Сам переезд занял примерно месяц, после чего мы получили гибкую и понятную систему для всего сайта, которой приятно пользоваться.
Параллельно с внедрением новой системы событий была переделана организация контейнера Google Tag Manager:
- Удалены все устаревшие или неиспользуемые теги, триггеры и переменные;
- Сам трекинг был перестроен по принципу одно логическое действие — один тег.
Про последний принцип расскажу чуть более подробно.
Часто встречал такие кейсы, когда начинающие web-аналитики настраивали по несколько десяткой тегов и триггеров для каждого нужного им события привязываясь к различным идентификаторам и классам того или иного элемента html-разметки. Из-за чего на контейнер GTM становилось страшно смотреть и в нем невозможно было разобраться не посвятив этому целый день.
А правильным подходом является разделение всех действий происходящих в контейнере на несколько логических этапов:
- Просмотр страницы;
- Событие на странице;
- Отправка конверсии во внешнюю рекламную систему;
- и тп.
И далее под каждое такое действие и систему создается отдельный триггер и тег. Такой подход позволяет покрыть нужны базового трекинга Google Analytics всего лишь двумя тегами и триггерами к ним, а также несколькими переменными.
Если тег и триггер фиксирующий просмотр страницы стандартный, то про организацию тега отправляющего событие нужно рассказать более детально.
Как вы могли заметить на рисунке выше, для активации тега отправки события используется триггер «Специальное событие», посмотрим его настройки.
