Простыми словами о сложном: объясняем, как управлять командами, продуктами и компаниями с помощью Скрама, Канбана, SAFe, LeSS, OKR и других гибких подходов.
Способ описания требований к разрабатываемому решению с точки зрения мотивации клиента. Фокусируемся не на том, чего хочет сделать пользователь, а на том, ради чего он это делает. Клиенты «нанимают» решения для выполнения определенной «работы». Концепция JTBD фокусирует на мотивациях клиентов, что оставляет широкое поле для инноваций при разработке решений, так как не определяет конкретных действий и решений клиента.
Как правило, Job Story выражается формулой:
Когда <Ситуация> я хочу <Мотивация>, чтобы я мог <Ожидаемый результат>.
Например:
Когда я не могу принять решение, какие фичи отправить в следующий спринт, я хочу избавиться от чувства волнения и неуверенности, чтобы я мог достойно провести планирование спринта.
Способ описания требований к разрабатываемому решению с точки зрения разработчиков. Формат напоминает User Story, только с фокусом на процессе взаимодействия пользователей с разрабатываемым решением:
<Глагол действия> <Субъект>, чтобы <Кто> получил <Что> (или чтобы <Цель>).
Например:
Установить уровень давления в системе в соответствии с типом пива, чтобы покупатель смог наполнил бутылку пива без пены за 30 секунд.
Тот же пример в формате User Story:
Как покупатель пива, я хочу наполнить бутылку пива за 30 секунд без пены.
(Клиент не знает о том, что разные сорта пива требуют разной подачи давления для налива, но хочет всегда получить 0,5 пива за 30 секунд. System Story описывает процесс с точки зрения разработчиков, а не пользователя).
Способ описания требований к разрабатываемому решению в виде потребности пользователя и цели, стоящей за этой потребностью. Фокусируемся на результате, который дает решение (а не на самом решении).
Как правило, пользовательская история выражается формулой:
Как <Кто> я хочу <Что>, чтобы <Цель>.
Например:
Как «читатель глоссария», я хочу «узнать непонятный мне термин», чтобы «понять, как мне лучше общаться с командой».
Техника проектирование точек контакта клиента с услугой, продуктом или компанией. Визуализация включает в себя сценарии использования, точки касания, видимые клиенту (интерфейсные решения) и точки касания, не видимые клиенту (внутренние системы). Может использоваться для оцифровки текущих процессов и опыта клиентов.
Шаблон, который помогает проектировать ценностное предложение разрабатываемого решения.
Шаблон состоит из двух частей:
АЛЕКСЕЙ ЕВДОКИМОВ
→6 АВГ 2021Простое и ёмкое изложение выгоды, которую потребители получат при использовании продукта или услуги.
Например: Прочитав глоссарий, вы поймете, из чего состоит мир управления продуктами.
АЛЕКСЕЙ ЕВДОКИМОВ
→6 АВГ 2021Визуализация последовательности шагов, осуществление которых необходимо для того, чтобы предоставить клиенту продукт или услугу. Это практика из бережливого производства (Lean). Используется для оптимизации всего процесса доставки ценности, а не только одного этапа процесса за счет других этапов.
АЛЕКСЕЙ ЕВДОКИМОВ
→6 АВГ 2021Техника визуального представления последовательности действий клиента в проектируемом решении. При этом используется двухмерная сетка: по горизонтали отражаем последовательность действий, по вертикали — вариации действий на конкретном шаге.
АЛЕКСЕЙ ЕВДОКИМОВ
→6 АВГ 2021«Черновая» реализация решения, продукта или его части, для анализа работы системы, проверки гипотез и анализа пользовательского опыта.
АЛЕКСЕЙ ЕВДОКИМОВ
→6 АВГ 2021Решение, достаточное для получение обратной связи по дальнейшему развитию продукта. Обладает минимальными, но достаточными для удовлетворения первых потребителей функциями.
АЛЕКСЕЙ ЕВДОКИМОВ
→Теория без практики не работает. Проходите тренинги с реальными кейсами, опытными тренерами и международными сертификациями.