Слава, что ты сделал? Рассказываю, чем занимаются аналитики в веб-студии

Статья, которая даст ответы на такие вопросы как: чем занимается аналитик в веб-студии, какой вклад в разработку продукта он вносит, и чем полезны работы аналитика для заказчика?

С тех пор как я устроился работать аналитиком в компанию Pyrobyte, все мои друзья и родственники меня спрашивают: "А че ты вообще там делаешь?". Я решил написать статью, в которой расскажу о всех наших работах внутри студии в рамках аналитики.

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

Pre-sale (с англ. «предпродажная подготовка) – этап, на котором происходит первое взаимодействия веб-студии и заказчика. Цель этого этапа – убедить заказчика в пользе сотрудничества, рассказать о нашей команде, и подготовить предварительную смету с договором.

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

Концепция проекта. Об этой работе уже кратко рассказывал в статье "ChatGPT в действии", поэтому здесь прикреплю цитату.

Работы в рамках пресейла. У заказчика есть потребность – сделать продукт, который будет приносить прибыль. С помощью этой работы мы показываем решения, которые могут к этому привести. Вдобавок, работы помогают заказчику получить ответы на такие вопросы как:

На каждый из этих вопросов отвечают разные работы, которые мы как раз и проводим в рамках пресейла. Давайте рассмотрим одну из них.

Анализ рынка методом TAM-SAM-SOM.
К нам обратился заказчик с идеей "X", но у него были сомнения, что проект стоит своих вложений и будет приносить прибыль. То есть заказчик сомневался – есть ли деньги на рынке его сферы? Обсудив эту проблему в отделе аналитики, мы приняли решение сделать анализ рынка методом TAM-SAM-SOM.

TAM-SAM-SOM – это способ оценить объём рынка, популярный в стартапах и растущем бизнесе. Метод используют, когда хотят понять перспективы роста — и то, стоит ли вкладывать деньги в проект.

TAM, SAM и SOM — это показатели. Каждый из них соответствует сегменту рынка.

TAM (Total Addressable Market) — общий объем рынка, на котором можно продать продукт заказчика. Показатель включает всех потенциальных клиентов — в том числе тех, кто уже покупает у конкурентов или даже не покупает товары-аналоги.

SAM (Served/Serviceable Available Market) — доступный объем рынка, доля от TAM. SAM показывает, сколько денег уже тратится на решения, похожие на решение заказчика. SAM — это рынок прямых конкурентов и аналогов.

SOM (Serviceable & Obtainable Market) — реально достижимый объем рынка, доля от SAM. Это объем продаж, который компания заказчика может получить с помощью доступных ей инструментов.

Для выполнения работы мы идем от большего сегмента к меньшему. В первую очередь исследуем TAM, затем сужаем рынок до SAM, и в конце ищем SOM.

Как мы это делаем? Изучаем различные источники со статистикой (у нас даже есть библиотека таких источников, которая периодически пополняется), анализируем, сопоставляем полученные данные с примерным ценником на продукт заказчика, используем математику за 5 класс, и вуаля – заказчик получает примерный размер рынка, на который он собирается зайти. Да, к сожалению результат не стопроцентный, так как получить информацию о сфере заказчика в определенном регионе, определенном продукте и определенных условиях – нереально. Однако, мы стремимся как можно глубже изучить статистику и сопоставить ее с продуктом.

Заказчик решил работать с нами, что дальше? А дальше начинается большая работа под названием "Предпроектная аналитика" (далее ПА). На этом этапе происходит получение информации об идее проекта, задачах, которые необходимы для достижения целей проекта. Изучаем конкурентов, целевую аудиторию и определяем структуру продукта.

Давайте кратко, но доступно расскажу о каждой работе в рамках ПА.

Брифование – это процесс получения данных о продукте во время первичного общения заказчика и аналитика.

Когда в отдел аналитики передали работу над проектом, то начинается знакомство с ним. Изучаются записи созвонов аккаунт-менеджера с заказчиком, а также различная документация, которую предоставил заказчик (техническое задание, блок-схемы, целевая аудитория и тому подобное).

Далее аналитик готовит список вопросов, ответы на которые позволят лучше понять идею заказчика. После составления вопросов назначается созвон, на котором присутствуют заказчик, менеджер и аналитик. На созвоне и задаются все интересующие аналитика вопросы.

Во время брифования мы получаем ответы на следующие вопросы:

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

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

Документ работы состоит из следующих разделов:

Документ оформляется в Figma.

Конкурентный анализ – исследование, сбор и оценка информации о преимуществах и недочетах компаний, которые являются прямыми или косвенными конкурентами для продукта заказчика.

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

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

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

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

А вот так выглядит мой телефон, который уже на 90% процентов состоит из приложений для изучения конкурентов:)

Анализ ЦА – это структурированный процесс сбора и интерпретации информации и данных о людях, которые с наибольшей вероятностью станут потребителями продукта заказчика.

Работа закрывает сразу несколько болей заказчика:

Чтобы приложение или сайт получились действительно полезными, нам следует узнать – а от чего душа болит у наших потенциальных пользователей? Какие потребности не могут закрыть уже существующие решения?

В нашей студии мы делаем анализ ЦА с помощью метода персон. Метод персон – это способ структурировать информацию о сегментах пользователей, их потребностях, проблемах и мотивах с помощью некого образа, портрета. То есть, опросив потенциальных пользователей, мы выделяем у них общие признаки/характеристики/мотивы/боли, и на основе этого создаем портрет.

Стоит отметить, что мы делаем не маркетинговое исследование ЦА. Наш анализ направлен исключительно на поиск болевых точек потребителей, чтобы наделить продукт функциями, позволяющими решать проблемы целевой аудитории.

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

Кстати, результаты опросов – моя любимая часть этой работы:) Вот, что отвечали люди на вопрос "Чего боитесь/опасаетесь при аренде авто?":

Но даже из этого можно сделать некоторые выводы о боли каждого из опрашиваемых)

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

Что получит заказчик, увидев данную работу? Полное представление всех элементов своего будущего продукта. Детальный пользовательский путь: с какого экрана начинает свое взаимодействие пользователь и к какому экрану он придет используя кнопки и другие элементы. А еще плюс работы в том, что заказчик, изучив работу, может указать на некоторые неточности в продукте или внести свое пожелание по некоторым элементам.

Вся предпроектная аналитика делается как раз для составления структуры:

Исходя из этого получаем, что в структуре отображается набор функций и элементов, которые позволяют решать бизнес-задачи заказчика. Если одна из таких задач, например – покупка какого-либо товара, то в структуре отображается весь путь пользователя от запуска приложения, до финального сообщения “Товар успешно оформлен”. При этом в структуре отображаются все элементы и функции, с которыми пользователь может взаимодействовать на пути к своей потребности.

Допустим, у нас есть экран. На нем есть некоторые элементы вроде кнопок и полей для ввода текста. Что будет, если нажмем на кнопку? На какой экран или окно переместится пользователь после этого? Какие пункты будут находиться в меню? Ответы на все эти вопросы как раз и дает структура проекта.

По сути, структура – это дерево. Есть корень, от него идут ветки, а от них уже листья.

Как показано на изображении выше – структура очень массивный документ. Все желтые элементы, которые вы видите – это страницы или окна продукта, а белые – элементы на странице.

После того, как на основании структуры дизайнеры создадут прототип, а затем дизайн проекта – аналитики начинают разработку требований. Если по простому, то эта работа направлена на перевод всех решений и функций, которые были выявлены на этапе ПА на язык разработчиков.

Вариантов оформления требований к продукту у нас два: техническое задание и бэклог.

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

Бэклог же имеет немного иной вид требований. Отличия в том, что документ имеет формат таблицы. Каждая строка – это функция на экране или странице. В столбце "Описание" указываются все те же атрибуты, что и в техническом задании (допустимые значения инпута, действие при нажатии на кнопку и так далее). Для каждой страницы прикрепляется скриншот дизайна страницы, а также ссылка на сам дизайн страницы в фигме.

Этот формат описания требований удобен тем, что на его написание уходит меньше времени, чем на ТЗ. Это частый кейс, когда заказчик очень спешит и ему необходимо приступить к разработке как можно быстрее.

Данной работе мы уже посвящали целую статью, поэтому оставлю здесь краткое описание работы:

Анализ требований сторов — это процесс проверки функционала мобильного приложения на запреты, ограничения и все, что может препятствовать выгрузке приложения в Google Play и App Store. Мы проводим исследование на полное соответствие функционала мобильного приложения согласно официальным требованиям и руководствам магазинов. Это исследование помогает снизить риски отказа модерации при публикации приложения.

Кстати, недавно мы публиковали статью об ошибках при публикации приложения в сторы – вэлком)

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

Необходимость в исследовании может возникнуть на разных этапах разработки проекта. Можно исследовать сервисы по отправке СМС, чтобы выбрать оптимальный. Проводили также исследование по конвертации платежей между продавцом и покупателем из разных стран.

Выделяем проблему, ставим задачи для ее решения и... начинаем исследовать. Чаще всего работа имеет сравнительный анализ какого-либо объекта, чтобы на основании множества выбрать подходящий.

Не всегда подобная работа необходима заказчику. Обычно она выполняется, если заказчик сомневается в каком-либо аспекте разрабатываемого продукта. И там, где наши компетенции позволяют – мы сами предлагаем решения на подобные запросы. Но если в проблеме нет четкого понимания ни у нас, ни у заказчика, то проводим исследование.

Спасибо, что уделили время этому длиннопосту. Надеюсь статья была вам полезна и вы узнали чуть больше:)