Поговорим о Service Blueprint

По сути это инструмент проектирования будущей системы. Его строят после того, как провели исследования по картам путей пользователя (Customer Journey Map).

Входной информацией для проектирования будет вся имеющаяся как и при проектировании в BPMN, UML: это могут быть результаты интервью, требования, спецификации, документация и т.д.

Разница в том, что если до проектирования вы проводили CJM, то методология утверждает, что ее результаты удобнее отражать в Blueprint.

Вот как выглядит описание сценария в Blueprint:

То есть в верху где Customer Actions ты прописываешь агрегированный пользовательский опыт.
Под ним во Front of Stage какими действиями со стороны фронтенда ты планируешь этот опыт поддерживать. То есть где автоматизация или помощь пользователю со стороны системы.
Над Customer Action пишешь какими атрибутами ты хочешь реализовать коннект между кастомером. Например, данные берешь из соц.сетей и это точка доступа к сервису и точка поступления информации. После обработки информации по CJM ты понимаешь, что пользователь итак уже долго ждет ответ и волнуется, поэтому добавляешь в атрибуты рассылку на почту с уведомлением "Все в порядке, все получили. Работаем".
На уровне Back of Stage под каждым шагом прописываешь какие события на стороне бэкенда в этот момент должны происходить в системе. Там где на фронтенде будет отображаться форма для ввода информации, но бэкенд будет пыхтеть от логики проверки входных данных, сохранения данных в систему, логики какие поля и уведомления отображать и т.д.
В Support Processes ты записываешь какие модули и сервисы будут бэку в этом помогать: СУБД, интеграционные сервисы, sms-шлюзы, сервисы почтовой рассылки, подсистема логирования и т.д.

Портянка в итоге получается объемная и глобально отражающая процесс. Уровень детализации может быть любой. Можно идти по стандартному пути: сначала рисовать верхнеуровневый процесс, потом декомпозировать каждый шаг и рисовать отдельно по нему блюпринт. Можно, рисовать только верхнеуровневый сценарий для общей картины и декомпозировать в других методологиях — зависит от личных предпочтений.

Рисовать удобно в https://miro.com/

Шаблон для составления S.Blueprint:

__________________________________________________________________

P.S.

Честно скажу, я этот сервис в бою еще ни разу не использовала. Для меня это как еще один инструмент в копилочке. Если прилетит проект, где с самого начала будет время и ценность на user expirience, то обязательно опробую.

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