Карта пользовательских историй (User Story Map) как инструмент диагностики организационных дисфункций

Представьте ситуацию: над одним продуктом работают несколько команд. У каждой есть план, трекер и регулярные встречи. Одни уже закончили свою часть работы, другие ждут уточнений, третьи не могут начать без решения коллег. Запланированную функциональность снова не удаётся выпустить в срок.

На общей встрече участники пробуют описать, как человек будет пользоваться продуктом. Выясняется, что под одной задачей команды подразумевали разные сценарии. Одни проектировали самостоятельное оформление заявки, другие рассчитывали на помощь сотрудника. Планы были согласованы, но опирались на разные представления о результате. Это условный пример: в конкретной организации причины задержки предстоит установить.

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

User Story Map связывает работу над продуктом с задачами человека, который будет им пользоваться. Например, пользователь сервиса хочет записаться на приём: выбрать специалиста и время, оформить запись, получить подтверждение. Эти действия задают последовательность карты. Под ними участники размещают детали: что нужно в обычном случае, какие варианты и затруднения возникают, какую функциональность предстоит создать.

Крупные действия образуют основу карты — её «каркас», или backbone. Слева направо разворачивается пользовательская история; ниже раскрываются подробности и варианты. Горизонтальными срезами выделяют объём отдельных релизов: выбирают сочетание возможностей, с которым человек сможет пройти нужный сценарий целиком. Такой способ организации бэклога описывает Джефф Паттон.

User Story Map и Customer Journey Map рассматривают разные стороны работы с продуктом. CJM помогает исследовать опыт человека: точки контакта, ожидания, затруднения и эмоции. USM помогает связать его действия с будущими изменениями продукта и обсудить состав релизов. В обоих случаях представления команды необходимо сверять с тем, что известно о реальных пользователях: согласие участников встречи ещё не подтверждает потребность клиента.

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

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

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

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

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

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

Разберите, где и сколько времени ждали последние изменения. Отдельно посмотрите время выполнения работы и ожидания её начала, решения или согласования. Уточните, какие задержки сдвигали выпуск, а какие совпадали по времени с другими необходимыми работами. Это помогает определить, что действительно ограничивает скорость прохождения изменения до пользователя.

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

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

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

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

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

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

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

В крупной технологической компании шесть команд развивали один продукт. Каждая вела свой трекер, планировала спринты и синхронизировалась с коллегами. Проводилось и PI-планирование — совместное планирование работы нескольких команд на предстоящий период. Тем не менее даже небольшие функциональные изменения регулярно задерживались.

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

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

Существенным было сочетание этих наблюдений: постоянные зависимости даже в небольших изменениях, дублирование работы и отсутствие у отдельной команды возможности довести изменение до выпуска. Рассматривать только количество встреч или качество планов было недостаточно. Требовалось пересмотреть, как между командами распределена ответственность за создание результата.

После этой работы команды переформировали по потокам создания ценности, а ответственность каждой стала сквозной. Время от начала работы над функциональностью до её выпуска сократилось на 27%. Это результат проведённых организационных изменений в конкретной компании. Карта помогла увидеть и обсудить проблему; последующие изменения затронули устройство команд и их ответственность. Переход дался непросто и руководителям, и участникам: вместе с распределением работы приходилось менять привычный способ её осмысления.

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

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

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

Так карта остаётся рабочим инструментом: к ней возвращаются при изменении пользовательских сценариев, состава релиза или распределения ответственности. Её ценность проявляется в решениях, которые команды принимают и проверяют в работе.

Автор статьи
Анастасия Бутова-Никишина
Организационный консультант, продуктовый стратег и советник руководителей, основатель «Лаборатории ПроЛидеров» / ProLeadersLab®.