Для начала проясним, что это направление аналитики не имеет практически ничего общего с продуктовыми магазинами. Однако Product Analytics – это очень востребованная и перспективная специальность, популярность которой растет с каждым годом.
Простыми словами, продуктовый аналитик – это связующее звено между командой разработчиков и отзывами пользователей о софте компании (программное обеспечение, веб-приложение или сайт, созданный этой фирмой). Такие специалисты очень ценятся на рынке труда, а их заработные платы вне зависимости от региона всегда на высоком уровне. Все подробности ниже!
Содержание статьи скрыть
У вас может возникнуть вопрос — а где и как освоить профессию?
Чем занимаются продуктовые аналитики?
Вполне логично, что представители этой профессии занимаются анализом данных и пользовательского опыта. С этим все предельно ясно. Кроме того, продуктовые аналитики во многом ответственны и за будущее развитие продукта. Однако, если вы решите отыскать во всемирной паутине должностную инструкцию такого специалиста – поиски вряд ли увенчаются успехом. Поэтому нам пришлось очень постараться, чтобы собрать основные функции продуктового аналитика воедино:
Разные ВИДЫ АНАЛИТИКОВ — чем они отличаются? Аналитик данных, продуктовый аналитик и другие.
- поиск новых возможностей для развития продукта и искоренения имеющихся проблем и ошибок;
- подготовка отчетных данных по продукту в таком формате, что могли понять сотрудники всех подразделений компании;
- работа с продуктовой командой, подтверждение или опровержение их теоретических данных;
- проведение тестирований, исследований пользовательского мнения;
- анализ, анализ, очень много анализа.
Если брать обязанности продуктового аналитика из описаний вакансий, то картина может разниться кардинально. Это связано с тем, что должностные обязанности такого специалиста напрямую зависят от сферы деятельности компании. Благо в продуктовых аналитиках нуждаются компании из самых разных отраслей, и проблем с подбором приятного именно тебе дела возникнуть не должно.
Ежедневные советы от диджитал-наставника Checkroi прямо в твоем телеграме!
Подписывайся на канал
Подписаться
Что должен знать и уметь продуктовый аналитик?
Продуктовый аналитик – это очень ответственная специальность, которая требует определенных профессиональных навыков. И мы с вами можем попробовать собрать в один список основные знания и умения такого сотрудника:
- знает хотя бы один язык программирования, подходящий для аналитики (Python, Java или R);
- умеет работать с инструментами веб-аналитики, например, Google Analytics или Яндекс.Метрика;
- легко визуализирует полученные данные при помощи Tableau, Power BI или аналогов;
- понимает, как работать с базами данных, знаком с SQL.
Однако, как и любая другая специальность, связанная с высокой ответственностью, зачастую сжатыми сроками работы и возможным стрессом, продуктовая аналитика принимает не всех. О том, какими личными качествами должен обладать идеальный сотрудник в этой отрасли, я вам сейчас расскажу.
Чем отличается бизнес-анализ от бизнес-аналитики?
Какими личными качествами должен обладать продуктовый аналитик?
Работа продуктового аналитика очень непроста. Она может быть наполнена стрессом и переработками, сжатыми сроками и высокой персональной ответственностью. А значит, на должность продуктового аналитика смело может претендовать лишь человек с сильным характером. Например, такой специалист:
- обладает аналитическим складом ума, куда же без этого;
- очень внимателен, а порой даже придирчив к мелочам;
- не боится решать проблемы, в том числе и других людей (коллег, пользователей и т. д.);
- мыслит системно, а свои идеи излагает очень четко и ясно;
- терпелив и усидчив, если необходимо проделать всю работу заново ради идеального результата – даже колебаться не будет, ведь итог очень важен;
- критику воспринимает конструктивно, а мысли других людей обязательно рассматривает наравне со своими;
- любит числа, однако не больше, чем людей – общаться продуктовому аналитику приходится много.
Надеюсь, что я не сильно напугал вас сложностями этой профессии. Они встречаются не чаще, чем посты ДПС на междугородней трассе. Да и все неприятности в работе продуктового аналитика может сполна компенсировать уровень его заработной платы и весьма интересный рабочий процесс.
Плюсы и минусы работы продуктового аналитика
А какие же плюсы есть у работы продуктового аналитика? Их, к слову, достаточно много:
- высокая востребованность не только на отечественном рынке труда, но и на зарубежных (в который раз убеждаюсь, что английский язык полезен любому специалисту);
- конкурентоспособная заработная плата;
- возможность напрямую повлиять на конечный продукт компании;
- широкие перспективы карьерного роста;
- простота освоения специальности, например, через современные онлайн-курсы.
Есть и минусы, часть из которых я упомянул выше в статье:
- высокий уровень личной ответственности;
- вероятны переработки и стресс;
- работа по большей части сидячая и достаточно монотонная.
Работа по профессии: зарплата и перспективы
Специалисты по продуктовому анализу могут быть востребованы в самых разных компаниях: от интернациональных IT-корпораций до небольших локальных стартапов. Возможностей для успешного старта карьеры в этой области очень много:
- вы можете начать работать на фрилансе и брать небольшие заказы из любой точки мира;
- никто не отменял традиционное трудоустройство в штат крупной компании на младшую должность;
- также, можно присоединиться к небольшой компании, которая лишь начинает развиваться (этот вариант особо актуален для крупных городов).
Однако, большинство работодателей непременно обратят внимание на ваш опыт работы и объем вашего портфолио. Поэтому оптимальным решением может стать получение заветной практики еще в процессе обучения. К слову, большинство современных онлайн-курсов предлагают возможность не только освоить специальность продуктового аналитика, но и получить драгоценный опыт работы. Подробнее об этом я расскажу в конце статьи.
Формула заработной платы продуктового аналитика не сильно отличается от аналогичных специальностей, где на уровень доходов может повлиять опыт работы, географическое расположение компании и направление ее деятельности, должность сотрудника, его талант и т. д. Давайте рассмотрим тему зарплат подробнее. Динамика доходов продуктовых аналитиков в Москве за последний год выглядит следующим образом:
Если рассматривать не только столицу, но и другие крупные города России, получится такая картина:
Самое время взглянуть на вопрос трудоустройства более предметно. Открываем сайт HH.ru и пишем в поисковой строке «продуктовый аналитик». По такому запросу мы найдем более 3 500 актуальных вакансий. Также не забывайте проверять и другие сочетания слов, например «Product Analytics» – это поможет увеличить количество отображаемых предложений.
Итак, если вы – начинающий продуктовый аналитик и ваш трудовой стаж пока что составляет 1 год или даже меньше, то работодатели будут готовы предложить вам оклад от 50 000 рублей в месяц. Для этого вы должны обладать определенными профессиональными качествами:
- хорошее знание математики и основ статистики;
- владение инструментами веб-аналитики;
- умение визуализировать полученные данные;
- хорошие знание Excel, SQL;
- приветствуется владение Python или R.
Продуктовому аналитику с опытом работы более 1 года, компании-работодатели готовы платить минимум 90 000 рублей в месяц. Однако и требования к таким специалистам выше:
- релевантный опыт работы от 1 года;
- уверенное владение основами математической статистики;
- знание SQL и Python на уровне уверенного пользователя;
- гуру Excel и Google-таблиц;
- английский язык на уровне Upper-Intermediate (B2) – желательно;
- аналитический склад ума;
- хорошее понимание веб-аналитики;
- знание и владение Google Analytics и Яндекс.Метрика;
- умение и желание проводить А/Б-тесты;
- знание систем Call-трекинга и CRM:
- умение составлять ТЗ для программистов / дизайнеров – желательно.
Как мы видим, английский язык и сюда забрался. Благо его на онлайн-курсах тоже можно освоить. А вообще, продуктовому аналитику с опытом работы по специальности более 3-х лет, знанием пары-тройки языков программирования и владением иностранным на разговорном уровне, компании без раздумий будут выписывать чек на 250 000 рублей минимум на ежемесячной основе.
Как стать продуктовым аналитиком
Где и как освоить такую специальность, как продуктовая аналитика – это вопрос, который вас наверняка интересует с момента, как вы начали читать эту статью. Итак, как и всегда, вариантов есть несколько: самообразование, вузы, онлайн-курсы.
Первые два пути достаточно консервативны, но продуктовая аналитика – это не та профессия, которую можно освоить в полной мере читая книги или просматривая YouTube от «А до Я». А отечественные вузы, к сожалению, не могут предоставить должной практики своим студентам. И в большинстве случаев, выпускники-аналитики по окончании обучения имеют лишь диплом, не подкрепленный реальным опытом работы. Но не время отчаиваться! Мы живем в век технологий, а значит и обучение должно быть современным. Я собрал для вас топовые онлайн-курсы, где можно обучиться на Product Analytics:
Более удобного формата для получения специальности продуктового аналитика еще не придумали. А на онлайн-курсах вы сможете и теорию постичь, и практику получить, и при необходимости, проконсультироваться с личным менеджером по любому вопросу. У таких образовательных программ есть и другие преимущества:
- Освоение специальности в короткие сроки — занятия проводятся в удобное именно вам время, а темп прохождения курса вы можете выбрать самостоятельно.
- Четко структурированная информация — вы изучаете отобранную профессионалами информацию в очень удобном формате.
- Наработанное портфолио — то, что так часто ценят все работодатели. Домашние задания помогут с практикой, а все проделанные работы вы сможете продемонстрировать заказчику в качестве портфолио.
- Удобство обучения — формат занятий дает вам возможность получать информацию где угодно, когда угодно и на любом гаджете.
Если вас заинтересовала профессия — ставьте плюс в комментариях, расскажем, как в ней легко стартануть
Поделитесь материалом в соцсетях — обсудите его с друзьями и коллегами!
Не знаете с чего начать?
Получите персональный список курсов, пройдя бесплатный тест по карьере
Источник: checkroi.ru
5 различий работы аналитика в проектах и продуктовой разработке
2018-05-17 в 7:37, admin , рубрики: agile, Анализ и проектирование систем, аналитика, аналитика проекта, Блог компании Туту.ру, Карьера в IT-индустрии, консалтинг, продуктовая разработка, продукты, проектная деятельность, системный анализ, управление разработкой, управление требованиями
Когда речь заходит о роли аналитика в IT, то всегда приходится добавлять кучу уточнений. Бизнес или системный аналитик? Анализ в продуктовой разработке или в проектной, как это, например, часто бывает в консалтинге? На внутренней разработке или на заказной. Заказчика государственного или негосударственного?
И так далее.
До прихода в Туту.ру я работала в IT-консалтинге на ERP-проектах и в заказной продуктовой разработке, здесь же я занимаюсь системным анализом во внутреннем продукте «Авиа». Отдел системного анализа у нас состоит из 9 аналитиков и 1 технического писателя. Далее на своем опыте я расскажу, что меняется в голове специалиста и в рабочих процессах при смене формата деятельности на внутреннюю продуктовую разработку с точки зрения анализа, а заодно поделюсь, как устроен процесс в целом у нас в Туту.ру.
1. Добби свободен! О мнимых рамках при анализе
В кастомной заказной разработке (т.е. в реализации проекта под конкретные бизнес-задачи — чаще всего, но необязательно — с нуля) или на проектах внедрения существующих IT-решений, аналитики ограничены требованиями заказчика как первостепенного держателя компетенций в своём деле, эксперта в методологиях бизнеса и законодательства, либо ограничены возможностями стандартной функциональности внедряемых решений. Для последних иногда выпускают пакеты локализаций (дополнительные части стандартного функционала, ориентированные на бизнес и законодательство определенных регионов), что должно немного облегчить ситуацию, но, говоря откровенно, полезны они бывают не часто. В такой работе задача аналитика — предложить не слишком сложное для реализации решение, не ломая текущую архитектуру. И все это, я повторюсь, в рамках ограничений, накладываемых базовой функциональностью.
Согласна, эту фразу было довольно скучно читать. И это довольно узкое поле для творчества, не так ли? Тем не менее, творчество здесь присутствует, и ограничения могут послужить стимулом разработать весьма причудливые и при этом работающие механизмы!
Как это было в продуктах: Когда я перешла в продуктовую разработку, было непросто переключиться на мысль, что я могу придумать абсолютно все, что угодно. Приобретенные за годы инстинкты призывали действовать в рамках существующих решений. Ведь если дело касается собственного продукта, нужно подключать фантазию, выдавать варианты и альтернативы. Вплоть до создания новых процессов, функций и вообще изменения всего, чего угодно.
Борьба с этим рефлексом занимает некоторое время. Поначалу то и дело ловишь себя на мысли, что вокруг границы, границы, границы. Но границы эти только в голове.
Как это работает в Туту: В рамках работы над каждой задачей мы обсуждаем возможные решения с командой, тимлидами и владельцем продукта (он же Product Owner, он же ПО), которые поощряют креативные идеи, даже если в итоге в разработку попадает наиболее простой вариант из предложенных. При необходимости мы можем собрать мозгоштурм — в том числе с коллегами из других подразделений (например, из нашего контакт-центра или отдела поддержки продаж туров), которые с удовольствием делятся своими наблюдениями и советами.
2. Немного о зонах ответственности
В проектной работе, где всегда есть установленный Заказчик (сколько бы отдельных «подзаказчиков» не было в рамках Одного Большого), чаще не приходится слишком много думать о том, зачем нужно то или иное требование. Заказчик сказал так-то и так-то, это не противоречит принятым бизнес-правилам, методологиям и доселе разработанной функциональности — значит так и надо. Не будет же Заказчик идти сам против себя и своего бизнеса! Таким образом, задача системного аналитика включает в себя больше описание бизнес-процессов, сбор и спецификацию требований, локальную проработку архитектуры и, возможно, документирование всего выше перечисленного.
В продуктах экспертиза зачастую находится внутри, и мы, как команда разработки, можем, хотим и даже обладаем карт-бланшем на большую самостоятельность для проработки решений. Новый важный вопрос — можно ли что-то концептуально сделать иначе, другим способом? Точно ли есть необходимость? Как ещё можно решить задачу, проблему, боль и потребность?
Точно ли это оптимальный вариант, и будет ли он полезен пользователям и бизнесу? Точно ли мы поможем кому-либо своим решением? Вот те вопросы, о которых мне, как аналитику (да и другим участникам команды), стоит задуматься еще в самом начале анализа. Получается, в каком-то смысле, я и мои коллеги наделяемся ощутимой силой при принятии решений, но, в то же время, и весьма большой ответственностью.
Как это работает в Туту: Заказчиком — то есть голосом конечного пользователя — чаще всего выступают владельцы продуктов (ПО). Но при этом наши ПО внимательно прислушиваются к мнению команды разработки, хотя точка принятия решения находится именно на их стороне. Как говорится, один мозг — хорошо, а шесть — лучше. Именно поэтому иногда мы обсуждаем задачи все вместе. В конце концов, все мы — не только разработчики, но ещё и пассажиры, которые потом и будут пользоваться готовым продуктом.
3. Об анализе после анализа
Говоря о разных фреймворках и моделях процесса разработки программного обеспечения — таких как Waterfall, RUP и прочие, стоит помнить, что это не просто разные подходы и методики управления, это могут быть еще и принципиально разные культуры и паттерны поведения. Например, в консалтинге весьма привычна ситуация, когда при возникновении новых немаловажных требований или новых вводных (о которых забыли — такое бывает, проекты большие) подрядчик находит письмо, в котором вы договаривались о таком-то объеме и составе работ, а новые требования не обозначались в рамках плана. Такое письмо может служить официальным разрешением не принимать во внимание требования сейчас, отложить разработку на следующий этап проекта, в рамках новой задачи и за дополнительные средства. То есть, в крайних случаях, обязательства могут стоять выше разрешения боли заказчика — иначе границы проекта и плана могут разрастаться до бесконечности.
В Agile в целом (здесь я не настаиваю конкретно на продуктовой разработке), при появлении новых знаний можно, и часто даже нужно, переоценивать и менять поведение и план разработки. Даже если эта самая разработка уже в процессе, а то и завершилась вот только что. Да, это может быть не очень приятно, но это не должно быть катастрофой, в том числе для системного аналитика. Впрочем, важное замечание: не каждое новое требование обязано быть взятым в работу прямо сию минуту. Новые требования должны быть оценены и приоритезированы в карусели других задач (например, метод MoSCoW может быть в помощь).
Как это работает в Туту: мы стараемся проводить анализ как можно более полно перед началом разработки — это позволяет разработчикам заниматься вопросами своей области, а тестировщикам — в точности знать, как должна вести себя будущая функциональность. Однако, в связи с большим количеством стейкхолдеров и разнообразных перевозчиков, бывает, что новые приоритетные требования по задаче прилетают по факту.
В таких случаях мы можем действовать по ситуации: либо принять решение сейчас же изменить план разработки, даже если это не слишком удобно (если изменились внешние обстоятельства, например, появились новые требования перевозчиков с определенным сроком), либо сделать некоторый конечный вариант без новых требований, но обязательно поставив задачу с новым требованием на ближайший спринт-два. Таким образом мы играем с балансом скорости/качества анализа в рамках здравого смысла.
4. Пара слов о «техническом задании» и документации
Уже сейчас существует десяток-другой способов оформлять и хранить проектную документацию. О, эти требования к проектной документации и её структуре… Аналитиков любят набирать со знанием стандартов ГОСТ 19, ГОСТ 34. Методология Oracle AIM предлагает десяток-другой шаблонов различных видов документов: функциональный дизайн, каталог настроек, библиотека ролей, все шаблоны утверждены и прокодированы. Документация держится в актуальном состоянии, любой сотрудник может обратиться к любому документу и поправить там что угодно (безусловно, с указанием авторства, заявки и характера изменений). А если это всё вовремя «не поддержать» — зачтут ли доработки при аудите трудозатрат?
Но вот у тебя есть свой продукт и внезапно — ты хозяин сам себе и своей базе знаний. Потрудишься над описанием процессов, продуктов, функциональности, требований — будет хорошо. Плохо напишешь — плохо потом будет людям, которым эти тексты с требованиями и описаниями понадобятся, в том числе, тебе самому. Несмотря на то, что никто не будет стоять с ружьем у виска и заставлять под страхом смерти писать тексты по ГОСТу, в твоих интересах знания задокументировать и сделать это оптимально (таким образом, как это удобно тебе и всем).
Как это работает в Туту: Для ведения различных документов мы используем Confluence и локальные стандарты аналитики, при этом сами задачи могут вестись в JIRA. О том, какой объем необходим и достаточен, мы договариваемся сообща: несмотря на то, что популярной в компании является lightweight-документация (без излишних подробностей), для некоторых команд мы описываем требования более детально. Документы не являются инструментом согласования (как это бывает в заказной разработке), но позволяют сформировать полное понимание продукта и отдельных блоков функциональности как нами, командой разработки, так и внешним заинтересованным лицам (например, коллегам из других продуктов и отделов).
5. Гибкость против Паники
Иногда эта картинка из прошлого возникает и по сей день. Прилетает какой-то баг, и вот, нужно всё бросать, быстро за 10 минут рисовать логику и код, потом ещё 5 минут на тестирование и ещё 5 минут на установку на продакшен. А потом можно выдохнуть, если не прилетел еще один аналогичный баг.
Который, скорее всего, прилетел… При внедрении того же бухгалтерского учета каждый месяц прилетало по несколько срочных, критичных задач на датафиксы — данные нельзя было исправить вручную, а финансовый период с некорректными данными в учете не закроешь. Вспомним еще про SLA по проектному договору, за нарушение которого можно оштрафоваться или получить нагоняй. А ещё пользователи переживают, не хочется их лишний раз волновать.
И ты остаёшься с этими доработками до полуночи, до часу ночи — пока системные администраторы не доберутся до домашних компьютеров и не зальют их на продуктивную базу, и ты не напишешь пользователям позднее письмо «всё исправили, можно закрываться!». И по выходным то же самое…
Но нет. Всё же в продуктах по-настоящему блокирующие задачи, из-за которых нужно немного попаниковать, возникают весьма редко, ЕСЛИ речь не идёт о высоконагруженных продуктах, где цена простоя очень высока. В стандартной ситуации большинство багов (не утверждаю, что все) едва ли требуют решения здесь и сейчас, через одно мгновение: можно остановиться, выдохнуть, подумать о том, что и как мы правим. Задачам с проблемами чаще всего просто проставляют повышенный приоритет, и они идут без очереди относительно других задач плана или спринта, но при этом проходят в рамках регулярных релизов.
Таким образом, можно говорить, что есть различие не столько между проектами и продуктами (хотя и здесь оно есть), а между степенями нагруженности используемой функциональности со стороны пользователей, со стороны имеющегося объема данных.
Хотя, признаюсь вам честно: иногда срабатывает какой-то давно забытый рефлекс — вот, нужно на прод прямо сейчас, прямо через 10 минут!
Как это работает в Туту: Так как наш сервис путешествий является высоконагруженным, безусловно, у нас существует понятие «блокирующей задачи» — той, которую нужно делать прямо сейчас. Тем не менее мы стараемся провести эту задачу по всем ролям, включая аналитику и качественную проверку тестировщиком на всех необходимых стендах, разве что делаем это в более оперативном режиме. Это позволяет нам определить риски и избежать будущих переделок, ненужных костылей в коде и нарушений пользовательской логики. В остальных случаях задаче ставится приоритет «повышенный», либо она уходит в бэклог багов, который курируют наши дорогие тестировщики.
Что лучше — проекты или продукты? Здесь совершенно неуместны такие слова как «лучше» или «хуже», в этом IT-мире есть своё место как для одного, так и для другого. Стоит понимать особенности разных подходов, формировать корректные ожидания и рассматривать каждый проект/продукт индивидуально. В общем, я свой выбор сделала, но совершенно его не навязываю.
У каждого свой опыт, свой бэкграунд, свои ожидания от работы. Я — про продукты, а вы — решайте сами.
Источник: www.pvsm.ru
Кто такой продуктовый аналитик и какие типы аналитиков бывают?
Я расскажу о разных типах аналитиков в контексте работы с digital-продуктами. Если проанализировать вакансии на hh.ru, можно увидеть много разных позиций, связанных с аналитикой. Я объясняю это тем, что у каждой компании своя специфика, свои задачи и сложившиеся процессы работы с данными. Сам я в digital-аналитике с 2014 года — участвовал в сертификации агентства по продуктам Google Marketing Platform, работал с Яндекс.Метрикой, AppMetrica, AppsFlyer. Последнее время развиваю Amplitude в России и странах СНГ — в том числе отвечаю на вопросы пользователей в Amplitude Insights Chat.
Возьмем анализ эффективности маркетинга на сайте и в приложениях. Где-то этим занимаются разные люди: веб-аналитик, который, работает с Google Analytics, и мобильный аналитик, который работает с платформами атрибуционной аналитики (например, AppsFlyer). В некоторых компаниях все эти функции выполняет один специалист. Как тогда назвать такого человека?
В небольших компаниях этот сотрудник может заниматься еще и продуктовой аналитикой: искать возможности для роста с точки зрения поведенческой аналитики и оптимизации продукта. Чем меньше компания, тем больше функций в себе сочетает один сотрудник.
Посмотрим на самые распространенные обязанности по каждому направлению.
Мы пишем о менеджменте продуктов и развитии в телеграм-каналах make sense и Продуктовое мышление.
Digital-аналитика
6−7 лет назад для работы в digital-маркетинге было достаточно знать только сами системы аналитики. Сейчас этот функционал расширился:
- Знать Google Analytics и Яндекс.Метрику на продвинутом уровне, понимать, как собираются данные и считаются метрики.
- Google Tag Manager — управлять работой аналитики и рекламными пикселями.
- Владеть инструментами визуализации данных: Google DataStudio, Tableau, Power BI.
- Базово знать HTML, CSS, JavaScript для работы с разметкой на вебе.
- Понимать основы трекинга данных в мобильных приложениях и знать их отличия от веба. Если есть такие знания, будет нетрудно разобраться с инструментами AppsFlyer, Adjust, AppMetrica и т.д.
На мой взгляд, этой базы достаточно для мобильного и веб-аналитика. Но список можно дополнить такими требованиями:
- Знать SQL и иметь опыт работы с Google BigQuery.
- Владеть инструментами A/B-тестирования: Google Optimize, Optimizely и т. п. — а также базово знать статистику.
- Уметь анализировать конкурентов: работать с инструментами SimilarWeb, SEMrush, SensorTower.
- Уметь мониторить социальные медиа: работать с IQBuzz, Brand Analytics.
- Работать с качественным тестированием: Survey Monkey, Фабрика Юзабилити.
BI-аналитика, аналитика баз данных, аналитика DWH
Аналитик, который работает с базами данных, должен:
- разрабатывать отчетности с использованием баз данных;
- создать и поддерживать аналитические отчеты в BI-инструментах;
- автоматизировать сбор данных: обращение по API к внешним сервисам, рекламным кабинетам, CRM и т. д.;
- ставить задачи для IT-специалистов, связанные с архитектурой хранилища данных;
- проводить Ad hoc-аналитику по запросу.
Набор умений зависит от аналитического стека, который используется в компании: опыт работы с BI-системами, определенными базами данных (MS SQL/PostgreSQL/Oracle и т.д.), понимание основ и принципов проектирования (DWH/ETL/OLAP/систем плоской отчётности), отличное знание SQL.
Бизнес-аналитика
Бизнес-аналитик выступает важным звеном между бизнесом и разработкой. Он работает с бизнес-процессами, ищет возможности роста и устранения проблем.
Этот человек много общается с заказчиками, поэтому нужно уметь:
- выявить требования и детализировать их;
- разделить запросы на требования и «хотелки»;
- составить документацию, сделать прототипирование;
- понятно донести до команды, как будет разработан продукт или решение.
Также в функции бизнес-аналитика может входить стратегический анализ: работа над стратегией развития компании и продукта. Это основные функции бизнес-аналитика. Еще есть дополнительные требования:
- анализ конкурентов;
- расчет unit-экономики;
- проведение анализа план-факт;
- управленческая отчетность;
- подготовка бизнес-планов и финансовых моделей.
Системная аналитика
Функционал системных аналитиков часто схож с бизнес-аналитиками: нужно определять бизнес-требования, анализировать их с точки зрения возможности реализации. Но обычно системный аналитик решает техническую часть вопроса.
Системному аналитику требуется больше технических навыков, он ближе к группе технических специалистов и должен понимать их язык. Выделю основные требования для такого сотрудника:
- работать с бизнес-требованиями с точки зрения определения стека нужных технологий или готовых решений;
- систематизировать технические требования для разработчиков;
- участвовать в проверке реализации согласно ТЗ;
- составлять техническую документацию.
Продуктовая аналитика
Продуктовой аналитикой могут заниматься продуктовые аналитики и веб-аналитики: все зависит от компании и ее процессов. Основная задача продуктовой аналитики — искать точки роста в продукте и данные о поведении пользователя. Для этого нужно:
- собрать данные;
- рассчитать метрики;
- сформировать гипотезы в эксперименты;
- анализировать запуск новых фич;
- участвовать в принятии решения по изменениям в продукте.
В задачи еще входит UX-аналитика — глубокий поведенческий и сценарный анализ пользователей, создание Customer Journey Maps.
Задачи продуктового аналитика обычно связаны с BI-системами, созданием дашбордов и отчетов. Он должен знать SQL и уметь работать с базами данных, владеть Python или R, строить модели, хорошо знать математику и статистику. Преимуществом будет опыт работы с системами продуктовой аналитики, например, Amplitude. Нужно уметь использовать инструменты для поиска инсайтов, работы с данными и организовать поддержку команды в работе с ними.
Платформы продуктовой аналитики помогают решать ad hoc задачи продуктовым и маркетинговым командам и освобождают время аналитиков для более сложных задач. Поэтому процесс обучения или онбординга здесь может лечь на плечи продуктовых аналитиков.
Резюмируем: кто такой продуктовый аналитик
Продуктовый аналитик — это человек, который:
- находит ответы на вопросы, связанные с улучшением показателей продукта, с точки зрения данных: где есть проблемы? как сделать, чтобы было хорошо?
- помогает разобраться в причинах того или иного поведения пользователей;
- глубоко погружен в продукт, помогает вовремя выявлять проблемы и улучшать состояние продукта;
- предлагает варианты для решения проблемы или возможности роста.
Я перечислил основные требования к разным видам аналитиков в сфере digital. Но важно понимать, что специфика бизнеса накладывает отпечаток на каждую специальность, таким образом размывая границы конкретной должности.
Источник: sense23.com