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

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

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

Шаги

• Понять этапы работы и сопутствующие обстоятельства.

• Сформулировать истории работы.

• Раскрыть истории работы.

Сложность

Низкая. Закончив исследование JTBD, создав карту работы и имея дорожную карту продукта, сгенерировать набор историй работы достаточно просто.

Осторожно

Истории работы могут иметь самые разные форматы, их применение также обычно различается. Главное – разработать постоянный формат, подходящий к вашей ситуации. Слово «история» подразумевает, что истории работы способны заменить истории пользователей в гибкой методологии разработки. Но в большинстве ситуаций этого не происходит: при гибкой разработке по-прежнему приходится измерять сгорание задач, используя традиционные истории пользователей.

Полезные советы

Рассмотрите работы, которые нужно сделать, в связи с конкретными усилиями, которые вы предпринимаете в данный момент. Сформулируйте 6–12 историй в одном формате, основываясь на данных исследований. Поделитесь этими историями для обсуждения. Затем сделайте их заметными на собраниях, семинарах и дизайн-сессиях, чтобы связать свою деятельность с потребностями клиентов.

См

• 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).

<p>3. Разработать структуру решения</p>

В разработке программного обеспечения структура решения, будь то продукт или услуга, может рассматриваться независимо от пользовательского интерфейса. Вам нужно сделать основой макета решения работы, которую нужно сделать. Тогда ваше предложение просуществует дольше и получит больше шансов на принятие клиентами. Существует несколько связанных методов, показывающих, как это сделать в различных ситуациях. Один из них – дизайн пользовательской среды (User Environment Design, UED).

Шаги

• Понять пользователей и их работу.

• Определить области фокусировки.

• Смоделировать структуру решения.

Сложность

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

Осторожно

Моделирование структуры решения – это абстрактная деятельность. Иногда его путают с технической архитектурой, с одной стороны, или разработкой интерфейса, с другой. Не объединяйте обсуждения базовой модели с уровнем реализации.

Полезные советы

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

См

• Hugh Beyer and Karen Holtzblatt, Contextual Design (San Francisco: Morgan Kaufmann, 1998).

• Indi Young, Structure Derivation, Chap. 13 in Mental Models (New York: Rosenfeld Media, 2008).

<p>4. Проверить предположения</p>

Даже самые тщательные исследования JTBD не дают гарантий, что созданное вами предложение примут клиенты. Запланируйте эксперименты и проверки вашего решения, чтобы убедить в наилучшем соответствии продукта рынку.

Шаги

• Сформулировать гипотезы.

• Подтвердить или не подтвердить гипотезы экспериментально.

• Сделать выводы из того, что вы узнали, и двигаться вперед.

Сложность

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

Осторожно

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