Анализ 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-продукта описываются деятельностными историями следующего формата:

Я как... <носитель действия: функциональная роль>
Когда <описание ситуации, контекста или проблемы>
Делаю <описание способа действия>
Чтобы <описание бизнес-ценности>

Например:

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

или

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

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

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

Карта реализации историй

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

Истории на карте разложены по двум осям. Колонки слева направо ориентируют в логика последовательного разворачивания процесса. Слои сверху вниз разворачиваются от замысла к формам его реализации.

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

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

1. Описание «чистых», без примесей реализации, функций системы
2. Описание деятельностных историй
3. Описание формы реализации историй
4. Список историй и форм их реализации, взятых на ближайший релиз

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

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

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

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