Заплати аналитику и спи спокойно: почему этот этап разработки нельзя пропускать

Аналитика на IT-проекте как набросок карандашом, позволяющий красиво нарисовать картину. Ты можешь отказаться от эскиза, но, если задумка не получится, готовый рисунок не исправить, только выбросить.

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

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

Предположим, клиент попросил агентство обойтись без аналитики, чтобы немного сэкономить деньги и уменьшить сроки. Итак:

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

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

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

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

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

Фаза discovery ведет от глобального (задачи бизнеса) к локальному (действия конкретного пользователя системы).

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

На этапе discovery мы:

- составляем план выполнения задач по проекту,

- определяем, какие работы и в какие сроки нужно сделать,

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

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

- изучаем, какие решения предлагает рынок целевой аудитории.

Фаза discovery длится от 1-2 недель до нескольких месяцев. За это время команда разрабатывает группу артефактов и схем, позволяющих эффективно работать на проекте. Набор документов зависит от задач, поставленных клиентом. Расскажем вам, какие это могут быть артефакты:

1) Описание бизнес-модели — схематичное изображение всех бизнес-процессов (от предложения и потребителей до финансов и инфраструктуры).

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

3) CJM — наглядная схема взаимодействия пользователя с продуктом. Это визуализированный опыт пользователя с учетом его настроения, целей и мотивов на пути получения результата в сочетании со всеми каналами и точками взаимодействия с продуктом. CJM позволяет понять узкие места в продукте, потенциальные проблемы и найти решения.

4) User Stories — описание функциональных требований к системе и критериев приёмки системы. Это коротко сформулированные намерения, рассказывающие, что система должна делать для пользователя. Они объясняют роль пользователя, его действия в системе, его потребности, и как они закрываются системой. User Stories позволяют посмотреть на систему целиком, выявить слабые стороны и реализовать её, как задумано изначально. На этапе тестирования User Stories используются QA-специалистами при проверке продукта.

5) User Flow (диаграмма пользовательского пути) — схематическое изображение экранов продукта и переходов между ними, показывающее сценарии взаимодействия с интерфейсом. Это простая понятная последовательность действий от шага к шагу, которую выполнит пользователь, чтобы достигнуть значимую цель на сайте или в мобильном приложении. Данный артефакт помогает команде сфокусироваться на разработке интуитивно понятного интерфейса, который решает стоящие задачи. Также с помощью User Flow можно наглядно представить идеи по развитию системы.

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

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

8) Пользовательские опросы позволяют проанализировать эффективность и юзабилити продукта, выявить потенциальные проблемы и возможности развития. Их полезно проводить, если требуется:

• оценить, какая часть пользователей сталкивается с выявленными проблемами,
• собрать количественные данные о мнениях и предпочтениях целевой аудитории,
  
• проверить гипотезы, полученные в качественных исследованиях.
  

9) Backlog продукта — перечень рабочих задач для команды разработки, в которых определены приоритеты и сроки внедрения тех или иных функциональностей. Данный документ составляется на базе road map и включенных в него требований. Благодаря бэклогу команда понимает, с чего стартовать, и куда далее развивать продукт. Например, на этапе создания MVP-версии определяет первичное наполнение продукта и функции.

10) Другие количественные и качественные методы исследований.

Также при проведении discovery могут организовываться фокус-группы, анализ документов, айтрекинг, A/B тестирование, наблюдения и многие другие форматы исследований.

Преимущества проведения discovery:

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

Может показаться, что discovery усложняет разработку и повышает бюджет проекта. Но это миф: при этом часть работ по аналитике проводится на первоначальном этапе, а не во время разработки. Проведение discovery в разы улучшает эффективность работы команды.

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

На этапе предпроектной аналитики мы провели исследование конкурентов, чтобы посмотреть, какие решения есть у конкурентов, их плюсы и минусы. Команда организовала глубинные интервью с пользователями работающего продукта клиента и выявила их боли и проблемы. Это позволит взять за основу УТП то, чего хочет целевая аудитория, и что ей не нравится в существующих решениях.

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

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

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

Например, в Notamedia на этом этапе команда подготавливает высокодетализированные черно-белые интерфейсы будущей системы. Демонстрация прототипов в этом формате помогает согласовать логику и структуру, не отвлекаясь на стилистические решения.

Команда продумывает все процессы взаимодействия пользователя и нового решения на базе созданных аналитиками артефактов (user flow, user stories, CJM и т.д.).

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

Таким образом, на одном предпроектном анализе участие аналитика в разработке продукта не заканчивается, он вовлечен во все последующие этапы.

Аналитик выступает посредником между бизнесом, пользователями и разработчиками сайтов и приложений. Он обеспечивает точное однозначное понимание, что надо разработать, и для какой целевой аудитории.

Изменения на этапе аналитики вносятся легко и не так критично, как на других этапах разработки, но при этом они отражаются на сроках и бюджете всего проекта.

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