Пролог
Аналитика — основа каждого проекта. Весь проект будет стоять на разработанном фундаменте, который с развитием проекта должен показать себя прочной опорой.
Видов аналитики великое множество: можно анализировать данные, можно проводить бизнес-аналитику и делать анализ бизнес-процессов, можно проводить финансовый анализ. Если у вас продукт, то нужен продуктовый аналитик, а если нужно разработать web-сервис, то понадобится web-аналитик.
Сегодня посмотрим, что из себя представляет web-аналитика, что и как необходимо сделать, чтобы проект не превратился в слив денег и времени и не подвел заказчика и команду.
Основные идеи
- Если вы любите рисковать и гадать на кофейной гуще, на воске и картах таро — то аналитика вам не нужна
- Ошибки аналитики — самые дорогие в исправлении
- Реализовать какой-нибудь проект не так сложно, как сделать “какой-нибудь” проект “тем самым” для клиента и конечного пользователя
Глава 1
О чем вообще речь?
У нас в Митре под аналитикой понимается самый первый этап работы над проектом. В зависимости от специфики проекта, его бюджета и сложности в рамках аналитики можно сделать:
- Брифинг и дебрифинг
- Анализ целевой аудитории
- Анализ сайтов/сервисов/приложений конкурентов
- Структуру проекта
- Концепцию проекта
- Техническое задание или функциональные требования
- Прототипы ключевых страниц
О каждом виде работ мы расскажем более подробно в других статьях, а пока посмотрим на этап аналитики в целом.
Обосновать значимость
Бывает, что еще на этапе продажи клиенты не понимают ценности аналитики и сомневаются в целесообразности трат времени и бюджета. Для таких случаев у нас есть «пример пиджака» и наглядная демонстрация результатов каждого вида работ:
Представьте, что вам понадобился новый пиджак. В магазинах все какое-то не то, и вы решили прийти в ателье. Что сделает опытный портной? Еще до того, как снять с вас мерки, он задаст множество уточняющих вопросов:
- Какой желаемый бюджет на пошив пиджака?
- Пиджак будет нарядный или деловой?
- Это будет однобортный или двубортный пиджак?
- По фигуре или посвободнее?
- Может быть у вас есть картинка с примером?
Хороший портной проводит аналитику, прежде чем взяться за выполнение задачи. А еще он расскажет, чем отличается одна ткань для пиджаков от другой, и почему вам стоит рассмотреть вариант с двубортным пиджаком.
Если одни ваши требования к пиджаку противоречат другим вашим требованиям (что вполне нормально для человека, который не эксперт в шитье вообще и в пиджаках в частности), то портной прояснит для вас все детали и предложит альтернативные варианты.
Как и портной, аналитик должен знать, что основа основ — это понять и синхронизировать картинку проекта в своей голове и в голове заказчика (а потом это грамотно изложить, конечно).
Определить истинный мотив и цели заказчика
Теперь перейдем к примеру из web-разработки:
В web-студию обращается самый крупный в регионе магазин по продаже комнатных растений и просит разработать мобильное приложение. Что можно выяснить, прежде чем готовить коммерческое предложение?
Например, что магазин цветов хочет сделать мобильное приложение для продажи комнатных растений. Тогда нужно понять, есть ли у магазина комнатных цветов сайт. Если нет, то лучше сделать сайт, который обойдется в разы дешевле, чем приложение. Если сайт есть, то надо выяснять, что на нем не хватает для продажи растений.
А может оказаться, что продавать комнатные растения вообще не главная цель заказчика, и он хочет мобильное приложение, чтобы:
- оказывать своим покупателям круглосуточную поддержку по уходу за растениями
- сделать там форум и собрать комьюнити
- а еще хочется сделать функционал для определения растений по фото, чтобы пользователь тут же мог сфотать понравившийся неведомый цветок, понять что это, найти его в каталоге и заказать
И нужно всё это, чтобы укрепить имидж бренда и стать лидером отрасли по всей стране, стать такой компанией по продаже комнатных цветов, на которую все будут равняться. В этом случае можно сделать вывод, что мобильное приложение действительно необходимо и оправдано.
В общем, как бы ни была сформулирована потребность клиента им самим, первый этап — это качественный брифинг и дебрифинг, и начинается он еще с отдела продаж.
Дальше подключится аналитик — ему нужно определить границы проекта и действовать строго внутри них, чтобы проект не наполнился костылями. Границы проекта — это не только бюджеты и сроки, это могут быть технические ограничения, законодательные нормы и даже особенности целевой аудитории.
Кстати, если проект крупный, то согласовать с заказчиком цель, задачи и границы проекта поможет концепция — небольшой текстовый документ. Его полезно не только заказчику показать и согласовать с ним, но и дать почитать дизайнерам и разработчикам — обычно они ребята смышленые, зная цели проекта, смогут предложить наиболее удачные решения по своей части.
Глава 2
Ошибки аналитики
Почему же так важно оценить необходимость аналитики по достоинству? С тестированием, например, все как-то проще, его польза всем гораздо более очевидна — наверняка вы слышали истории как баг или прореха в безопасности сервиса стоили бизнесу репутационных и финансовых потерь (взять хоть сбой в работе Amazone в 2014 году, когда на два часа множество товаров оказалось выставлено по бросовой цене).
Всё дело в том, что ошибки разработки и тестирования зачастую становятся известны сразу множеству людей. А вот ошибки, закравшиеся на этапе аналитики не столь очевидны, но они могут вообще не дать бизнесу появиться и хоть что-то заработать.
Что самое безобидное может произойти, если в этапе аналитики были допущены ошибки или аналитикой совсем пренебрегли? Самое безобидное — это головная боль для всей команды разработки. Потому что каждому участнику процесса все равно придется взять на себя часть работы аналитика и сочинять правила на ходу, неоднократно переделывая реализацию.
Такая чехарда увеличивает сроки и стоимость разработки и нервирует руководителя проекта, команду и заказчика.
Пример из жизни
Продолжим на примере цветочного магазина:
Для магазина комнатных цветов был разработан интернет-магазин, но помимо каталога и других важных штук, там есть и раздел с мероприятиями. Мероприятия публикуются администраторами сайта и выводятся пользователям в виде красивого календаря.
Но заказчики в ходе использования поняли, что в некоторые месяцы мероприятий нет совсем и это выглядит очень «грустно», ведь на странице запрограммирован вывод текущего месяца в виде календаря — пользователи заходят, видят его пустым и уходят.
Заказчики решают обратиться к разработчикам:
— Хотим вариант вывода мероприятий не только сеткой, но и списком. Чтобы всегда было видно какие-то мероприятия. Можете сделать?
— Можем, — отвечает команда разработки. Ну а что там, казалось бы? Дело нехитрое.
Но в процессе работы программист чешет затылок и приходит к менеджеру с вопросом:
— Слуууушай, а в каком порядке выводить мероприятия будем?
Менеджер начинает разбираться и выясняет, что заказчики заполняют список мероприятий на месяцы вперед, и если сделать вывод «от самых старых к самым новым», то в самом верху окажутся мероприятия, которые наступят только через полгода, а это будет неудобно и не сильно лучше, чем пустая сетка месяца.
Вот тут менеджер вспоминает про аналитика, которого поленился привлечь в самом начале.
Аналитик, конечно, все придумал, но:
- потрачены человеко-часы, не заложенные ранее в бюджет этой доработки
- аналитика выдернули с проекта, которым он занимался
- пришлось возвращаться на шаг назад и переделывать макет страницы мероприятий, чтобы дорисовать несколько нужных элементов для корректной сортировки
- пришлось дергать заказчика на согласования, хотя заказчик свято верил, что его доработка уже вот-вот будет готова. А тут оказывается только способ сортировки согласовывают :(
Если бы менеджер сразу учел дополнительный час трудозатрат аналитика и привлек бы его в самом начале, то выяснилось бы:
- существующего способа фильтрации мероприятий по признакам «Активные» и «Завершенные» будет явно недостаточно
- в макете страницы нужно добавить сортировку по дате проведения мероприятия
- нужно запрограммировать все так, чтобы при открытии страницы мероприятий в виде списка по умолчанию выводились только активные мероприятия уже заранее отсортированные от ближайших к будущим
Глава 3
Тот самый проект
Конечно, никто не застрахован от того, что сформулированные на старте проекта гипотезы не оправдают ожиданий. Но это уже территория стартап-консалтинга и бизнес-инкубаторов, где специально обученные люди помогают сформулировать и отобрать жизнеспособные идеи и оценить гипотезы.
Экспертиза web-аналитики более узкая и в общих чертах ее задача в том, чтобы в контексте разработки сайта, приложения или сервиса ответить на вопросы:
- Что мы делаем?
- Зачем мы это делаем?
- Для кого мы это делаем?
- Как оно должно работать, чтобы получилась штука из вопроса №1, которая нужна для достижения цели из вопроса №2 для аудитории из вопроса №3?
Можно ли разработать простой сайт без аналитики? Пожалуй, что можно.
Будет ли такой сайт на все 100% окупать вложенные в него деньги и время? Крайне маловероятно.
Да и зачастую, если аналитика не выделена явно в отдельный этап, она все равно присутствует. Опытный web-дизайнер обязательно задаст массу вопросов клиенту, если этого не сделал аналитик. Как и опытный программист. То есть аналитика все равно будет, просто время на нее потратят специалисты, у которых в проекте вообще другие задачи.
Мы знаем, что есть проекты, которые реализуются по наитию и выстреливают, но это скорее исключение, которое подтверждает правило. И когда приходит время такой проект развивать, то одним чутьем основателя уже не обойтись — придется привлекать продуктовых аналитиков, которые помогут заложить базу для масштабирования идеи, ее улучшения и привлечения всё большей аудитории.
Но если аналитика состоялась, и в ходе нее удалось сформулировать ответы на вопросы выше, то кратно растет вероятность получить на выходе классный работающий проект, разработанный качественно и в срок.
Эпилог
Всё просто :)
Не забивайте на аналитику, пишите точные и понятные ТЗ, согласовывайте с заказчиком — это отличная база для того самого проекта, который точно получится :)
