Аналитика IT-продукта

Прежде, чем писать программный код, мы совместно с заказчиком отвечаем на вопрос: «Как будет оцениваться успех задуманного IT-продукта?» Ответом на этот вопрос будет список бизнес-целей описанных по SMART. Качество ответа определит выбор инструментов для реализации проекта и уровень мотивации продуктовой команды.

Примеры грамотно сформулированных бизнес-целей, с которыми можно начинать работу:

1. Увеличить чистую прибыль на 1 млн. рублей через 6 месяцев после запуска продукта.
2. В 2 раза увеличить индекс Удовлетворенности пользователей через год после запуска продукта.
3. Захватить 15% рынка партнёрских сетей через 4 месяца после запуска продукта.

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

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

Карта гипотез

Цели и стратегии описываются Картой гипотез. Результат выглядит как диаграмма связей (Mind map). В корне карты — цели, ветки — пути достижения целей:

Результаты этапа

Заказчик и разработчики:

1. понимают зачем создается IT-продукт;
2. принимают бизнес-цели и готовы взяться за их достижение;
3. понимают стратегию достижения результата и приоритеты;
4. понимают критерии успешности IT-продукта;

Чтобы продукт оставался целостным и не создавал препятствий на пути потребителя, важно увидеть его целостно с высоты «птичьего полёта». Кроме этого, каждое поведение пользователей требует адекватной поддержки внутри системы. Для этого сначала выявляются точки контакта потребителя с сервисом, важнейшие точки входа и выхода, а также переходы между экранами и состояниями. Всё это используется для грамотного выстраивания процесса, поддерживающего это поведение внутри системы. Мы проектируем и согласовываем внутренние процессы работы цифровых сервисов с индивидуальным опытом пользователей с помощью метода карты процесс—опыт.

Карта процесса-опыта

·  ·  ·	Обозначение на схеме	Примеры
	Действующие лица и точки их взаимодействия	Клиент как юридическое лицо, отдел маркетинга банка, директор филиала
	Условия переходов из одного состояния в другое	Подошел срок сдачи отчетности, поэтому нужно написать своему бухгалтеру задачу
	Препятствия и барьеры, которые мешают пользователям	Сall-центр не готов принимать звонки ночью, поэтому клиент остается без помощи до утра
	Артефакты, которые образуются в результате взаимодействия с IT‑продуктом	Cформированный файл, отправленное письмо

Результаты этапа

1. Целостное видение IT-продукта.
2. Точки входа, точки выхода и переходы пользователей.
3. Линии жизни действующих лиц и важнейшие точки их взаимодействия друг с другом.
4. «Зашнуровка» всех внутренних процессов в бесшовный внешний опыт в глазах потребителя.

Функции IT-продукта описываются историями пользователя (User Story). История имеет следующий формат:

Я как... <роль пользователя>
<описание проблемы, если есть>
Хочу... <описание задачи>
Чтобы... <описание бизнес-ценности>

Например:

Я как корпоративный клиент
Не понимаю в каком состоянии счет и из-за этого ухожу в минус
Хочу останавливать работу, если баланс стал критично низким
Чтобы не терять деньги

или

Я как рекламодатель
Хочу покупать только автомобильный рекламный трафик
Чтобы эффективно использовать бюджет, привлекая целевую аудиторию

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

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

User Story Mapping

Функции, записанные в виде историй, упорядочиваются и приоритизируются с помощью Карты пользовательских историй (User Story Mapping). В карте истории разложены по двум осям: слева направо идёт время, сверху вниз — важность:

С помощью этой карты исполнитель вместе с заказчиком выбирают задачи для ближайшего релиза и оценивает объем работы.

Статья про метод Usert Story Mapping

Результаты этапа

1. Описание функций системы.
2. Список функций на ближайший релиз.

	Цели и стратегия их достижения ПДФ-документ с диаграммой связей по Карте гипотез с комментариями
	Путевая карта пользователя ПДФ-документ с Картой процесса-опыта с комментариями
	Карта пользовательских историй ПДФ-документ оформлен в виде изображения с комментариями

Набор из этих документов даёт стратегическое и тактическое понимание IT-продукта. На основе этих документов создается план проекта: цена, срок и объем работ.

Разница между классическим Техническим заданием, написанным заказчиком, и подходом Byndyusoft заключается в активном понимании исполнителем бизнес-целей заказчика.

1. Почему мы делаем аналитику как описано выше, вместо того, чтобы брать в работу список задач.
2. Статья о нашем процессе создания IT-продуктов с примером применения на реальном проекте.
3. Выступление c AgileDays 2016 в Москве: