Эффективные инструменты для управления продуктами

Построение бизнес-моделей

Полное описание построения бизнес-моделей есть в работе Александра Остервальдера и Ива Пинье «Построение бизнес-моделей. Настольная книга стратега и новатора».

Бизнес-модели «Канвас» дают возможность визуализировать бизнес-модели и адаптировать их для проектов по разработке ПО.

Лучший способ визуализации – всей командой с использованием стикеров и доски.

Персоны

Практика персонального анализа была заимствована из практики опыта использования (user experience). Суть заключается в представлении продукта в виде реального персонажа, обладающего определенными ценностями.

Бизнес-модель в виде Lean Canvas

Проблемы

Решения

Уникальное предложение

Преимущество

Сегменты заказчиков

3 наиболее важные проблемы заказчиков

Функциональность продукта, решающая проблемы

Доступное пониманию сообщение, почему заказчику стоит обратиться к вам

Невозможность купить или быстро скопировать

Заказчики или конечные пользователи продукта

Метрики оценки

Каналы продаж

Как понять, что продукт решает проблемы пользователя

Как ваш продукт дойдет до вашего заказчика

Структура затрат

Потоки прибыли

На что вы потратите деньги при производстве продукта?

Как именно вы получите прибыль?

Стори-мэппинг

Функционал обозначается после обозначения персон. Он создается посредством стори-мэппинга — метода планирования и визуализации функциональности продукта. Планирование и визуализация проводятся на доске: отмечаются высокоуровневые персональные активности, подразделяются на задачи, а далее — на подзадачи.

К верхнему уровню подзадач относится элементарный функционал, чаще всего входящий в первую версию.

Нижний уровень подзадач включает в себя:·        

  • дополнительные функции

  • юзабилити

  • безопасность

  • производительность

Со снижением уровня подзадач понижается и их значимость.


Журнал пожеланий продукта

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

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

Имя пользовательской истории представляет из себя небольшое — до 10 слов — описание функциональной части продукта с техническим заданием пользователя. Составляется оно по формуле «роль-действие-цель», например: юзер вводит свой адрес e-mail для завершения регистрации на вебсайте. 

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


В данном случае, 10 — это Story Points, 200 — важность, а 1453 — номер из трека.

Кроме этих 4 величин, в трекер часто заносят следующие параметры:

  • Детальное описание пользовательской истории в форме текста или графики. Чаще всего применяется в распределенных командах для хранения данных о функциональности продукта;

  • Демонстрация — подробный сценарий демонстрирации пользовательской истории. Для предыдущего примера можно привести следующие сценарии:

    • Юзер вводит свой адрес e-mail и получает письмо о подтверждении регистрации;
    • Юзер вводит свой адрес e-mail и получает сообщение «Данный e-mail адрес уже используется».
  • Категория – повышает управляемость с помощью разделения задач на категории.

Размер журнала пожеланий и стратегическое планирование

Чтобы эффективно управлять текущим и ближайшими спринтами (тактическое планирование), нужно выделять в журнале необходимый минимум пожеланий. В то же время для долгосрочного стратегического планирования нужно располагать длинным журналом пожеланий. В результате рождается противоречие.

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

Этот подход тесно кореллирует с принципами KISS и YAGNI, оба из которых в своей основе подразумевают отсутствие необходимости усложнения и избавление от функций, которые не понадобятся.

Тех. истории — это задачи при  разработке ПО, которые не связаны с функциями пользователя напрямую:·

  • рефакторинг модуля

  • производственная оптимизация

  • устранение существенного дефекта

  • оптимизация инфраструктуры.

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