Метод Jobs to Be Done. Проектирование клиентоориентированного продукта

Узнать больше

Alan Klement, Replacing the User Story with the Job Story, JTBD.info (блог), 12 ноября 2013 года; 5 Tips for Writing a Job Story, JTBD.info (блог), 12 ноября 2013 года; Designing Features Using Job Stories, Inside Intercom (блог).

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

Maxim van de Keuken, Using Job Stories and Jobs-to-be-Done in Software Requirements Engineering, (диссертация, Утрехтский университет, 2017).

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

PLAY ➤ Разработка структуры решения

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

«Архитектура» в данном случае означает базовую структуру объединения различных компонентов решения на концептуальном уровне. Речь не идет о технической архитектуре или организации компонентов интерфейса. Это, скорее, структура, лежащая в основе решения: то, как организованы его части. В идеале такая организация основывается на схемах, определенных работой, которую нужно выполнить. Совпадение модели системы с моделью работы обеспечивает лучшую степень охвата, большее удобство использования и в конечном счете соответствие продукта рынку.

Разработка структуры решения напоминает печально известную модель дизайна опыта пользователя Джесса Джеймса Гаррета, имеющую пять слоев (рис. 5.2)[41]. В середине находится «Структура», то есть принцип объединения частей продукта или услуги в рамках одной концепции. Тем не менее перед этим поставщик продукта должен определить стратегию и масштаб. После появления структуры создаются каркас и внешняя сторона интерфейса. В целом дизайн проходит весь путь от абстрактного к конкретному, двигаясь по этим слоям.

Рис. 5.2. Модель дизайна опыта пользователя Гаррета показывает концептуальные слои, находящиеся под поверхностью

Пол Адамс, руководитель товарного направления Intercom, говорит о важности поиска правильной структуры в статье «Дрибббилизация дизайнеров»[42], где он также представляет понятие историй работы[43]. Архитектура решения должна основываться не на технологии, а на работах, которые нужно выполнить. Адамс пишет:

За целью и перспективой следует архитектура. Не техническая архитектура, нет, скорее выявление составляющих данного продукта и способа их соотношения. Система.

Она вносит ясность. Так мы привязываем Работу к нашей цели и расставляем приоритеты соответствующим образом. Так мы гарантируем, что не забудем ни один из уровней дизайна. Мы видим, какие компоненты нашей системы являются частью Работы и какие отношения и взаимодействия можно применить для достижения цели.