Я использую Картирование пользовательских историй (User Story Mapping) вот уже 14 лет, и это один из наиболее полезных и продолжительно сопутствующих моей практике подходов. Этот метод до сих пор любим и широко используем ИТ-сообществом, хотя и имеет разные «диалекты» от компании к компании. Если бы меня попросили выбрать один метод, который я бы непременно оставил для практики разработки пользовательского интерфейса, я бы оставил USM.
Вместе с тем, за эти годы, я оброс собственными примочками к этому методу, о которых неоднократно писал и рассказывал. Пришло время сделать следующий шаг, решив все проблемы, выявленные в методе за эти годы, и оставив в следующей версии все его прелести. Но перед тем как сделать этот шаг, проведём критический анализ. Не с тем, чтобы дискредитировать метод, а, наоборот, отдать дань его силе и наметить контуры слабостей для прицельного их улучшения на следующем шаге развития.
Ниже я приведу свои размышления по поводу сильных и слабых сторон USM.
Важные вещи USM, что мне хочется сохранить
Человеко-центричность как принцип поиска лучших решений с позиции конечных пользователей. Пункт хоть и спорный для современного витка ИТ-капитализма, но крайне важный как с гуманистической точки зрения, так и с точки зрения того же бизнеса, зависящего от потребителя и желающего удовлетворять его.
Структурная матрица «логика процесса — глубина детализации форм решения» для структурирования бэклога. Карта выстраивает по горизонтали логику следования деятельностных ситуаций и требуемых в них функций. Карта выстраивает по вертикали логику согласования этих ситуаций с конкретной формой их реализации.
Ёмкий формат требований, записанных в тексте. Краткость на объёме историй даёт кратное сокращение времени на чтение длинных документов, такие требования лучше осязаемы, их проще затащить в голову.
Отдельный блок плюсов я хочу забрать в новый метод из личных практик сформированных по большей части в Byndyusoft
Инвентаризация — шаг работы с картой с явным выделением форм решения из текста историй. Практика инвентаризации коротко описана в статье «Выращивание или проектирование через тестирование».
Строгий язык для описания способов действования, вызванный более узким контекстом ИТ-систем — в них всегда присутствует интерфейс. Например, когда мы пишем «потребитель видит», мы понимаем, что важно передать данные человеку в нужном представлении, а когда пишем «потребитель понимает» — мы должны организовать передачу в голову человека некоторой концепции. В проектной группе часто возникает свой набор глаголов сужающий способы действования. Подход к строгому описанию языка сделан рабочей группой Консорциума исследования пользовательского интерфейса в репозитории «Структурный язык описания интерфейсных ситуаций»
Работа с объектами данных. Важно ещё при работе с историями, задолго до макетов, описать структуры данных и определить, что с ними происходит в контексте ситуации. Важно понимать, что это не те структуры данных, что используют программисты для хранения или передачи данных, а те, без которых не будет работать бизнес. Рассмотрение потока данных как структуры для проектирования сделано в статье «Схема цепи преобразования данных в системах с интерфейсами».
Чего недостаёт USM, какие с ним проблемы
Тотальная зависимость от человеко-центричного подхода и модели потребителя, а не способа действия и ситуации, приводит к искажениям и чрезмерной центрированности на предпочтениях людей, а не на деле. Это не всегда минус, но сейчас работает как догма, и бывает, что проектирующих заносит в крайность пользовательской апологетики.
Липовая зависимость от пользователя, даже когда мы хотим записать требование бизнеса. Например, мы явно хотим влиять на поведение пользователя, и это нельзя записать в формате истории с ценностью для пользователя. Я видел как записывают истории вида «Я как потребитель, хочу чаще получать анонсы об акциях сервиса, чтобы не пропустить ничего интересного для собственной выгоды», ни разу не выйдя в поле и не поговорив с потребителем, действительно ли он это хочет и в каком количественном соотношении таких потребителей в общей массе. Да, так пишут, но с точки зрения метода — это натягивание совы на глобус. Не хватает способа в том же инструменте карты зафиксировать требования, вызванные желанием бизнеса влиять.
Модель способа решения может быть недоступна на момент записи истории, а её нужно вынуть и положить в историю. Такое встречается редко, но случается. Например, ясно что за ситуацию нужно решить, но никто не знает как именно в будущем в ней будут действовать, это ещё нужно изобрести. Я писал в такие истории метку-заполнитель в виде вопросика или прямо писал „<делаю что-то эдакое>, чтобы добиться конкретно вот этого результата“. Например: логист делает что-то, чтобы проверить, что все правила настроены верно. Эта история — задание на проектирование, где неизвестен даже способ действования, а закреплен лишь результата. С таким тоже можно работать.
Практикующие USM часто удовлетворяются псевдо-ценностью, и метод их не ограничивает в этом. Чаще пишут так называемые «горизонтальные» цели-ценности: я как потребитель авторизуюсь в системе, чтобы продолжить работу. В таких ценностях нет никакого смысла, потому что USM и так упорядочивает истории и понятно, что текущая чаще всего идёт перед последующей именно в логике процесса. Гораздо важнее вычислять «вертикальные» истории, отвечающие на вопрос зачем всё это делается или почему именно таким способом.
Часто я вижу в историях коллег «склейку» формы решения и принципа, способа действования. Нужно сделать что-то в новом методе, чтобы так записать было невозможно.
Нет явного мостика для перехода к реализации. Меня постоянно спрашивают, а как переходить от историй к интерфейсам.
Есть ощущение, что выявленных сильных сторон и возможных для улучшения моментов достаточно для следующего шага развития метода.