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

Выявление бизнес-целей и создание стратегии их достижения 4-16 часов
Прежде, чем писать программный код, мы совместно с заказчиком отвечаем на вопрос: «Как будет оцениваться успех задуманного IT-продукта?» Ответом на этот вопрос будет список бизнес-целей описанных по SMART. Качество ответа определит выбор инструментов для реализации проекта и уровень мотивации продуктовой команды.
Примеры грамотно сформулированных бизнес-целей, с которыми можно начинать работу:
- Увеличить чистую прибыль на 1 млн. рублей через 6 месяцев после запуска продукта.
- В 2 раза увеличить индекс Удовлетворенности пользователей через год после запуска продукта.
- Захватить 15% рынка партнёрских сетей через 4 месяца после запуска продукта.
Отсутствие бизнес-целей или ошибочные цели приводят к перерасходу бюджета, расфокусировке команды и проблемам в пользовательском интерфейсе. Ошибка на этом этапе может означать провал проекта.
После выявления целей мы описываем стратегию их достижения. Мы понимаем кто и почему приведёт нас к поставленным целям. Заказчик приоритезирует пути достижения, мы помогаем выбрать среди стратегий наиболее быстрые и дешёвые.

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


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

Путевая карта пользователя 4-16 часов
Чтобы продукт оставался целостным и не создавал препятствий на пути пользователей, важно увидеть его с высоты «птичьего полёта». Для этого выявляются точки входа пользователя, точки выхода и переходы между экранами и состояниями. Мы описываем схему переходов и взаимодействий с помощью Путевой карты пользователя (Customer Journey Mapping).

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

Карта пользовательских историй 4-16 часов
Функции IT-продукта описываются историями пользователя (User Story). История имеет следующий формат:
Я как... <роль пользователя>
<описание проблемы, если есть>
Хочу... <описание задачи>
Чтобы... <описание бизнес-ценности>
Например:
Я как корпоративный клиент
Не понимаю в каком состоянии счет и из-за этого ухожу в минус
Хочу останавливать работу, если баланс стал критично низким
Чтобы не терять деньги
или
Я как рекламодатель
Хочу покупать только автомобильный рекламный трафик
Чтобы эффективно использовать бюджет, привлекая целевую аудиторию
Мы выбрали этот формат, потому что он помогает формулировать задачи с точки зрения взаимодействия пользователя с системой и сохраняет понимание бизнес-ценности. Задача, поставленная в такой форме, даёт всестороннее понимание исполнителю и позволяет ему самостоятельно выбирать подходящее решение.
Пользовательская история берётся в работу, только если её удаётся привязать к одной из веток Impact Mapping. В работу не берутся истории, которые не привязаны к бизнес-целям. Получается, что Impact Mapping выступает фильтром, с помощью которого отсеиваются истории, не приносящие бизнес-ценность.
User Story Mapping
Функции, записанные в виде историй, упорядочиваются и приоритизируются с помощью Карты пользовательских историй (User Story Mapping). В карте истории разложены по двум осям: слева направо идёт время, сверху вниз — важность:

С помощью этой карты исполнитель вместе с заказчиком выбирают задачи для ближайшего релиза и оценивает объем работы.
Статья про метод Usert Story Mapping
Результаты этапа
- Описание функций системы.
- Список функций на ближайший релиз.
Описание функций системы.
Список функций на ближайший релиз.
Результаты аналитики
Цели и стратегия их достиженияПДФ-документ с диаграммой связей Impact Mapping с комментариями |
|
Путевая карта пользователяПДФ-документ с диаграммой Customer Journey Mapping с комментариями |
|
Карта пользовательских историйПДФ-документ оформлен в виде изображения с комментариями |
Набор из этих документов даёт стратегическое и тактическое понимание IT-продукта. На основе этих документов создается план проекта: цена, срок и объем работ.
Разница между классическим Техническим заданием, написанным заказчиком, и подходом Byndyusoft заключается в активном понимании исполнителем бизнес-целей заказчика.
На эту тему
- Почему мы делаем аналитику как описано выше, вместо того, чтобы брать в работу список задач.
- Статья о нашем процессе создания IT-продуктов с примером применения на реальном проекте.
-
Выступление c AgileDays 2016 в Москве: