Написание пользовательских историй для систем бэк-офиса

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

Единственным самым большим препятствием является написание пользовательских историй. Приверженцы Agile знают, что история пользователя — это вертикальный срез пути пользователя. Они принимают форму «как пользователь x, я делаю yдля zвыгоды». Цель пользовательской истории — разбить сложные пользовательские взаимодействия на простые фрагменты функциональности, которые можно доставлять как непрерывный поток ценности.

Что вы делаете, подумали вы, если пользователь неизвестен, как это часто бывает в бэк-офисных системах? Трудно использовать обученную структуру, если система не зависит от пользователя. Команда начинает с лучшими намерениями, пробуя все обычные вещи, «как пользователь API», «как клиент» и другие лингвистические приемы, но они никогда не работают хорошо, поскольку они кажутся фальшивыми и часто уже находятся на уровне реализации. Как мы все знаем, истории должны быть независимыми от технологий, если вы уже говорите об API, то мы уже закрыли творческий процесс.

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

Одна из моих навязчивых идей — приносить пользу коммерческим командам. Эта проблема с гибкими и бэк-офисными системами подрывает эту цель, и это случается достаточно часто, что мне приходится искать решение.

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

Однажды мы говорили о процессах, которые выполнялись как часть особенно сложной системы бэк-офиса. Эта система принимала данные от пользователей, а также от событий реального мира, которые происходили асинхронно с пользовательским опытом. Даррен вполне естественно смоделировал взаимодействие с клиентом как часть общей системы. Фактически, он упомянул изменения состояния процесса и связал их непосредственно с пользовательскими историями. Загорелся свет! Пользовательская история — это просто срез процесса, в котором стимулом процесса является событие, созданное клиентом.

Если вы, как и я, начинали с телекоммуникационного бума 90-х, то вы знаете о Конечных автоматах, или FSM. Конечный автомат — это поведенческая модель. Он отображает процесс на конечное число состояний с событиями, которые перемещают процесс между состояниями. В зависимости от текущего состояния и заданного события машина выполняет переход и выдает выходные данные. Полностью определенный FSM является детерминированным, ни в какой момент входное событие не может привести к неизвестности состояния. Это именно то, к чему мы стремимся в хорошем UX, опыт пользователя всегда должен быть детерминированным. Стремление к предсказуемости ведет к постоянному упрощению пути.

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

  1. Определите цель процесса как результат
    Четкое заявление о цели процесса. Результаты — это мощный способ выразить цель, описанный в моих других блогах. Результаты позволяют избежать расползания функций и коробок в целях системы. Результаты также обеспечивают первую разбивку сложности. Они позволяют увидеть более мелкие процессы, из которых состоит деятельность компании. Результаты также помогают отличиться от самого процесса и наблюдателей процесса, которые заинтересованы во входных и выходных данных, но не влияют на процесс.
  2. Нарисуйте конечный автомат для процесса
    Кажется простым, да? Удивительно, как много людей этого не делают. Есть несколько способов нарисовать машины состояний. Для меня UML имеет простой для понимания формат, хорошо документирован и общепризнан. Составление FSM заставляет задуматься обо всех событиях в процессе, обеспечивающем результат, о том, когда они могут произойти, и об отношениях между ними. Это дает вам возможность решить условия гонки, прежде чем вы перейдете к уровню кода. Часто конечный автомат для бизнес-процесса можно зафиксировать на одной странице. Самое главное, это позволяет вам спроектировать процесс, а не диктовать его текущими практиками.
  3. Для каждого перехода напишите пользовательскую историю
    Я знаю, что модная пользовательская история звучит так: «Как пользователь x, я делаю y для zвыгода». Это всего лишь служебное предложение. Нет ничего плохого в том, что история выражается как «в состоянии x, когда получено событие y, выполнить z». Если история представляет собой единый переход через процесс, то она отвечает цели истории, разбивая сложность на простые в реализации и тестировании блоки полезной функциональности.

И вот, теперь у вас есть четко определенный и проверяемый набор историй, который дает вам 100% охват и детерминированное поведение. Лучше всего использовать этот формат вместе с традиционной формой пользовательской истории, определяющей опыт для наблюдателей. Эти два метода дают вам возможность полностью охватить как процесс, так и наблюдаемость процесса, не упуская из виду важность создания целостной системы.