Гибкая методология разработки позволяет командам и организациям действовать, приспосабливаясь к окружающим обстоятельствам. Подход возник при разработке программного обеспечения, но распространился на другие сферы деятельности, в том числе и на государственное управление и армию. Принципы гибкой методологии разработки применимы практически в любой отрасли.
Главный элемент методологии – приложение усилия к отдельным единицам работы. Истории пользователей – короткие описания характеристик и функционала, написанные с точки зрения конечного пользователя. Это позволяет командам сосредоточиться на маленькой части целого и контролируемо продвигаться вперед.
Истории пользователей обычно состоят из трех частей. Первая указывает на роль пользователя в системе. Вторая – на возможность, позволяющую человеку выполнить задание. Последняя часть обычно описывает преимущества или причину воспользоваться этой возможностью.
Хотя в конкретных случаях детали и стиль могут отличаться, типичная история пользователя похожа на следующий текст:
В качестве [роль] я могу [возможность], так что [выгода].
Примеры историй пользователей в этом формате:
• Как системный администратор я могу определить файлы и папки для резервного копирования, основываясь на их размере, дате создания и дате изменения.
• Как пользователь я могу указать папки, которые не надо копировать, чтобы мой диск не переполнился тем, что мне не надо хранить.
• Как пользователь я хочу иметь возможность изменить имя документа так, чтобы я мог отнести его к какой-либо категории.
В любой отдельно взятой системе могут заключаться сотни историй пользователей. Некоторые достаточно невелики, например описание одной кнопки и того, почему пользователь нажимает на ее. Эти истории организуют в пакеты незавершенных заданий или репозитории для создания функционала. Команды разбивают логические группы историй пользователей на спринты – короткие циклы работы, длящиеся несколько недель.
Истории работы
Хотя истории пользователей годятся для разбивания работы на части, обычно они не могут связать создаваемое решение с потребностями пользователя. В них не хватает указания, почему некто ведет себя определенным образом и что ему нужно, чтобы выполнить работу. На самом деле истории пользователей проистекают из создания функциональной возможности, а не из наблюдения за реальным поведением.
Альтернатива историям пользователей – истории работы. Они следуют традиции разделения усилий на небольшие части, но делают это сквозь призму JTBD.
Впервые метод применила команда разработки продукта в компании Intercom – лидере на рынке решений для обмена деловыми сообщениями. Разработчики хотели избежать влияния готовых решений, а также не привязывать разработку к идеологии и стратегии компании.
Пол Адамс, менеджер по продукту в Intercom, писал о первом применении историй работы так: «Мы оформили каждую задачу проектирования как работу, сосредоточившись на инициирующем событии или ситуации, мотивации, цели и желаемом результате»[36].
В результате их истории работы также состоят из трех частей. Но вместо того, чтобы ставить в центр внимания групповую роль, такую как «пользователь» или «администратор», в историях работы прежде всего подчеркивается ситуация или контекст, а не отдельный человек:
Когда [ситуация], я хочу [мотивация], чтобы я мог [ожидаемый результат].
Примеры историй работы:
• Когда на сервис подписывается новый важный клиент, я хочу получать об этом уведомление, чтобы иметь возможность начать диалог с этим человеком.
• Когда я захожу на чью-то страницу профиля, я хочу видеть, сколько постов этот человек написал по каждой теме, чтобы иметь возможность понимать, в чем он разбирается лучше.
• Когда я часто использую приложение, меня подталкивают к тому, чтобы я внес свой вклад, и, таким образом, поощряют к участию в его разработке.
Автор и лидирующий специалист по JTBD Алан Клемент сделал бо́льшую часть работы по оттачиванию формата историй[37]. Он считает, что добавление подробностей об обстоятельствах лучше показывает причинно-следственную связь. Сосредоточенность на контексте переключает внимание с человека на ситуацию. Клемент советует избегать описания неопределенных ситуаций, но, насколько это возможно, придерживаться конкретики.
Например, рассмотрим три возможные ситуации в качестве первого элемента истории работы:
• Когда я голоден…
• Когда я заблудился…
• Когда я хочу проверить электронную почту…
Вместо этого Клемент рекомендует более детально описывать обстоятельства.
• Когда я голоден и при этом куда-то опаздываю, не уверен, когда мне удастся поесть в следующий раз, и беспокоюсь, что скоро потеряю силы и начну раздражаться из-за голода…
• Когда я заблудился в городе, где никогда раньше не бывал, не знаю местного языка и беспокоюсь, что потеряю время там, где не хочу находиться…
• Когда я хочу проверить электронную почту, но не хочу, чтобы кто-то вокруг знал, что я это делаю, потому что они могут подумать, что это невежливо…
Каждый пример ситуации обеспечивает гораздо более широкий контекст для разработки приемлемого решения.
Как подходить к историям работы
Истории работы состоят из свободно заменяемых частей, обеспечивая дизайнерам и разработчикам гибкость для решения проблем альтернативными путями. Истории работы основываются на реальном опыте, и при создании решений они имеют больше силы, чем истории пользователей. Но в то же время истории работы свободнее по форме, чем другие методы JTBD. Тем не менее существуют схемы, которым рекомендовано следовать. Используя элементы из главы 2, можно придать им следующую структуру:
Когда я [обстоятельство + этап работы / шаг], я хочу [микроработа], чтобы я мог [потребность].
Примеры:
• Когда я, обновив свои социальные сети, оказываюсь в топе блогеров, я хочу отразить это в своем профиле, чтобы иметь возможность получить признание как эксперт в каком-то предмете.
• Когда мне не хватает материалов, чтобы закончить художественный проект, я хочу найти альтернативные ресурсы, чтобы довести до максимума использование имеющихся запасов.
• Когда я собираюсь поехать на работу и понимаю, что выезжаю поздно, я хочу знать, какая погода, чтобы я мог свести к минимуму шансы промокнуть по пути.
Рассмотрим последний пример. Первый элемент соединяет информацию об обстоятельствах (выезжаю поздно) с выполнением основной работы (поехать на работу) в рамках одного из этапов процесса (готовлюсь поехать).
Второй элемент указывает на еще более маленький шаг или микроработу (узнать прогноз погоды). Его необходимо сформулировать без указаний на конкретную технологию, но достаточно точно, чтобы позволить дизайнерам и разработчикам создать определенную возможность.
Наконец, последний элемент можно взять непосредственно из списка потребностей. В данном случае исполнитель работы (тот, кто едет на работу) не хочет приходить в офис мокрым (свести к минимуму шансы промокнуть по пути). Формулируя положения о работе, можете эффективно использовать элементы, которые уже обнаружили во время вашего исследования JTBD.
Проводя исследования для этой книги, я наткнулся на несколько альтернативных подходов к формулированию историй работы. Андреа Хилл, известная защитница JTBD в социальных сетях, предлагает несколько отличающийся вариант. Она полагает, что средний элемент должен указывать непосредственно на характеристику или решение, таким образом явно переходя из пространства проблемы в пространство решения. Ее основной формат выглядит так:
Когда я [обстоятельства] хочу [возможность решения] так, чтобы я мог [потребность].
Тогда история работы из предыдущего примера с поездкой на работу выглядела бы следующим образом:
Когда я собираюсь поехать на работу, я хочу, чтобы прогноз погоды приходил на телефон как пуш-уведомление, чтобы я мог свести к минимуму шансы промокнуть по пути.
Стеф Троэт, исследователь и инструктор по JTBD из Великобритании, подходит к историям работы иным образом. Она использует формулу:
Когда я [обстоятельства] хочу [работа] так, чтобы [выгода, предлагаемая решением].
Интерпретация не столь важна, главное – найти последовательную структуру и придерживаться ее. Форма, на которой вы остановитесь, должна подходить для вашей команды и ситуации.
Истории работы в действии
В конечном счете истории работы связывают усилия по дизайну и разработке на местах с более широкой концепцией JTBD. Поскольку формат историй работы включает детали контекста, они становятся переносимыми. Другими словами, история работы должна иметь смысл и для человека, не представляющего более широкую картину JTBD или карту работы. В результате истории работы обладают изменчивостью и готовы к использованию, что часто необходимо для дизайнеров и разработчиков в рамках гибкой методологии разработки.
Например, те, кто занимается планированием, могут управлять очередью незавершенных историй работы практически так же, как управляют историями пользователей. Если какой-то спринт разработки замедляется или меняет направление, незатронутые истории переходят в следующий спринт. Наличие небольших, автономных описаний малых работ для выполнения является преимуществом на разных этапах дизайна и разработки.
Однако внесу ясность: я обнаружил, что истории работы в процессе разработки не заменяют истории пользователей полностью. Они направляют и подают концепцию решения, но не отслеживают его реализацию. Лучше всего они служат как инструмент разработки для создания или определения направления развития идеи и проекта. Разработчикам и инженерам, скорее всего, понадобятся истории пользователей, чтобы измерить сгорание задач[38] и прогресс в целом.
Карта работы позволяет ориентироваться в общей картине JTBD и сконцентрироваться на конкретной зоне для дизайна и разработки. Дорожная карта проекта дает высокоуровневую последовательность развития с обоснованиями для планирования деятельности. Истории работы более конкретны, они направляют команды дизайна и разработки на местах при создании характеристик и возможностей решения.
При создании истории работы, основанной на JTBD, следуйте этим инструкциям:
Этап 1. Понимание этапов работы и сопутствующих обстоятельств
Основывается на соответствующих работах и обстоятельствах из проведенных ранее интервью и наблюдений. Для каждой сферы разработки решения рассмотрите этапы основной работы. Затем копните глубже и составьте список все более малых шагов-микроработ, используя правила формулировки JTBD. Также определите обстоятельства, сопутствующие конкретной части основной работы.
В зависимости от глубины предварительного исследования и того, насколько хорошо вы и ваша команда понимаете работу, вам могут и не понадобиться дополнительные исследования для создания и обоснования истории работы. Однако никогда не помешает еще раз поговорить с людьми и углубиться в их конкретные проблемы и цели. Во время дополнительных интервью задавайте вопрос «как?», пока не достигнете необходимого уровня понимания целей и подцелей.
Этап 2. Формулирование историй работы
Вместе с командой запишите истории работы, характерные для ваших задач проектирования и разработки. Договоритесь о едином формате историй и придерживайтесь его.
Стремитесь предлагать уникальные взаимоисключающие истории, ориентированные на конкретные работы и обстоятельства. Избегайте избыточности. Скажем, если вернуться к предыдущему примеру, вам, возможно, не нужны отдельные истории для поездки на поезде и на автомобиле. Разрабатывайте наиболее важные и сосредоточенные на ограниченном наборе тем истории. В итоге у вас может получиться от трех до восьми историй работы на проект или спринт.
Этап 3. Раскрывайте истории работы
Сделайте истории работы заметными для всей команды, чтобы раскрыть лежащую за ними потребность. Например, повесьте список историй на доску во время мозгового штурма, чтобы все его видели. Или перечислите истории работы в начале критического анализа дизайна, чтобы дать команде контекст для комментариев. Используйте JTBD, чтобы направлять решения по проектированию и разработке.
Также возможно использовать истории работы, чтобы рассмотреть вопрос о целесообразности вашего решения. Во-первых, дизайн-команда может применить имеющие отношения к проекту истории работы как набор эвристических правил. Члены этой команды должны постоянно спрашивать себя, соответствует ли дизайн целям пользователей, заданным в историях работы.
Затем проверьте решения вместе с пользователями, использовав как основу истории работы. Покажите пользователям свои решения (скажем, как макеты или прототипы) и спросите, насколько хорошо каждое из них решает проблему, изложенную в истории работы. Это можно сделать как в стиле интервью, так и путем опроса. В конечном счете истории работы станут мерилом успеха дизайна еще до того, как что-то сделано.
Истории работы позволяют сделать шаг назад и посмотреть на контекст работы при разработке продукта или услуги. В этом отношении они заполняют значительный пробел между наблюдениями за клиентами и разработкой решения, связывая информацию о потребностях клиентов с отдельными характеристиками продукта и усилиями по разработке.