Давайте поговорим о двух клевых техниках для проработки скоупа решений — Impact Map и User Story Map. Мы разберем то, как их можно использовать в связке, но зачастую эти техники применяются и по отдельности — смотря, какую задачу аналитик решает в моменте.
Начнем с того, что и Impact Map, и User Story Map чаще всего подаются как agile-техники. А у практически всех таких техник есть яркая черта: это способ реализовать некую задачу дешево и сердито, т. е. в ногу с принципом Парето (20/80) это подход к тому, как быстро и не особо затратно выработать ключевой результат, игнорируя менее значимые рюшечки. Т. е. надо понимать, что техники эти а) простые, б) довольно поверхностные, в) быстро применимые. Грубо говоря, постройку ядерного реактора я бы не советовал прорабатывать с помощью agile-техник, а вот для MVP некоего стартапа — самое оно.
Начнем с Impact Map. Impact Map — это техника визуальной проработки плана достижения некой цели. В контексте бизнес-анализа — это способ проработать со стейкхолдерами наполнение решения в ответ на поставленные перед решением бизнес- цели. Разбирать техники мы будем на примере проекта из книги Карла Вигерса «Разработка требований к программному обеспечению» (3-е издание), т. к. многие знакомы с его условием и контентом V&S и SRS из книги.
Частичный контекст проекта (опущено то, что мы не будем разбирать в примере здесь):
Большинство сотрудников Process Impact в настоящее время тратят в среднем 65 минут в день, чтобы выбрать, оплатить и съесть обед в кафетерии. Около 20 минут уходит на то, чтобы дойти до кафетерия и вернуться на рабочее место, выбрать еду и оплатить ее наличными или с помощью кредитной карты. Таким образом, сотрудники проводят около 90 минут вне рабочих мест. Некоторые звонят в кафетерий заранее, чтобы блюда были готовы к их приходу. Они не всегда получают то, что заказали, потому что некоторые блюда заканчиваются до их прихода.
В книге, честно говоря, не особо понятно, кто является бенефициаром решения, потому что по какой-то причине мы решаем проблемы и кафетерия, и компании, сотрудники которой туда ходят кушать, поэтому сократим 3 бизнес-цели из книги до одной, релевантной для компании Process Impact:
BO-3 Увеличить среднее эффективное рабочее время каждого сотрудника на 15 минут в день в течение 6 месяцев после первого выпуска системы.
Не будем тут рассуждать, почему именно к таким метрикам пришли, т. к. Impact Map — это не техника проработки бизнес-требований. В нее вы идете с уже готовыми целями. Цели эти могут быть по SMART или сугубо векторно — неважно. Главное, что вы их со стейкхолдерами определили. Точно так же это не техника выбора конечного решения, а потому неизвестной нам магией мы пришли к следующему образу решения:
Cafeteria Ordering System — это интернет-приложение(в оригинале была еще приписка «или приложение для смартфона», но давайте все же определимся, чем это конкретно будет), которое принимает заявки на питание, взимает оплату и инициирует доставку готовых блюд к указанному пункту на территории Process Impact.
Примерно с этой точки мы и стартуем impact mapping, или построение Impact Map. Impact map (сложно красиво перевести, но пусть это будет карта воздействий по-русски) — это ментальная карта (mind map), которая заполняется по определенному шаблону. Причем важно понимать, что Impact Map, как и абсолютное большинство agile-техник — это не просто артефакт, который вы изолированно от всех рожаете на своем рабочем месте. Лучше всего agile-техники работают тогда, когда вы делаете это совместно с релевантными стейкхолдерами (заказчик, ключевые люди с его стороны, представители пользователей, вы, ваш юиксер, ведущий разработчик и т. п.). В конце мы вкратце поговорим о том, как подобный процесс может выглядеть.
Итак, первый уровень карты — это бизнес-цели (goals). Второй уровень, на котором нужно сфокусироваться и не идти дальше, пока он не будет проработан (и подобный подход актуален для каждого уровня карты, коих 4: не спешите бежать дальше и сфокусируйте думалку именно на прорабатываемом в моменте уровне) — это актеры (actors). Это те, кто могут поспособствовать или помешать достичь бизнес-целей. Наводящие вопросы:
Кто напрямую влияет на достижение бизнес-цели?
Кто косвенно влияет на достижение бизнес-целей и участвует в бизнес-процессах?
Кто при каких-то обстоятельствах может помочь/помешать достичь бизнес-цель?
Мы знаем контекст сформулированной выше бизнес-цели: увеличиваем эффективное время сотрудников мы за счет автоматизации заказа еды и избавления от необходимости ходить в кафетерий, а потому, отвечая на вопросы выше, мы можем сгенерировать такой набор актеров:
Сами сотрудники (именно их мы и «прокачиваем»)
Кафетерий в лице менеджмента (кафетерий как организация будет доставлять еду в TO BE ситуации)
Можем добавить руководство Process Impact, но это не особо нужно, т. к. их цель мы и прорабатываем. Но да, очевидно, что они являются ответом на вопрос, т. к. финансируют все происходящее
Доставщики еды кафетерия
Повара кафетерия
Служба поддержки (для обработки вопросов)
·Актеры, которых также стоило бы проработать, но сократим, дабы не усложнять пример:
внешний хостинг или админы внутреннего хостинга
государственные органы (если есть какое-либо регулирование того, как делать конкретно данное решение)
отдел учета расходов на заказы еды в компании Process Impact
Интернет-провайдер компании
платежный провайдер
Вероятно, вы заметили, что фактически мы сейчас сделали урезанную идентификацию заинтересованных лиц (ЗЛ). Урезанную, т. к. вопросы, на которые мы отвечали, это не на 100% равенство термину «заинтересованное лицо», и у нас в этом контексте могут остаться пробелы. Но обратите еще раз внимание на вводную о ярких чертах Agile-техник.
В целом, на этом этапе вам все-таки может помочь понимание того, кто такие ЗЛ и каких категорий они могут быть, но и без этого сочетание коллективного разума и бредогенерации могут помочь в устранении пробелов.
Третий уровень карты — это воздействия (impacts). Это желаемое изменение в поведении актера, которое позволит достичь бизнес-целей. Т. е. что мы хотим от актеров в плане изменения их поведения, чтобы поспособствовать достижению бизнес-цели. Наводящие вопросы:
Что должен начать делать или сделать актер?
Что должен перестать делать или не сделать актер?
Что актер должен начать делать по-другому (чаще, реже, больше, меньше)?
Давайте набросаем, помня о том, что наша цель — увеличить среднее эффективное рабочее время сотрудников за счет автоматизации заказа еды.
Сотрудники
Перестать ходить ножками в кафетерий за едой
Заказывать еду в веб-приложении из офиса
Кафетерий в лице менеджмента
Настроить новую структуру ролей и обязанностей, если услуги доставки там пока еще нет (новые обязанности для поваров, доставщики, служба поддержки)
Настроить процессы сбора заказов и их оперативной обработки
Руководство Process Impact
Собственно, ничего, поэтому они тут не особо и нужны. Финансировать изменения, что очевидно.
Доставщики еды кафетерия
Оперативно доставлять заказы в Process Impact
Служба поддержки
Консультировать по телефону
Повара кафетерия
Оперативно готовить еду по заказам
На этом уровне также, вероятно, получилось много пробелов, но надо понимать, что я набрасывал идеи в одно лицо. Если бы под рукой был заказчик, представитель кафетерия, голодный сотрудник, плюс моя команда (например, в лице ключевого UX-специалиста и технического лида), то результат получился бы существенно более надежный.
Последний, четвертый уровень карты — это решения в ответ на каждый impact (deliverables). Т. е. что мы в плане решений мы можем дать или должны сделать, чтобы обеспечить желаемые impacts актеров. В первую для нас очередь, сюда будут входить функциональные возможности целевого IT-решения. Но также могут быть и важные нефункциональные требования или что-то вне рамок IT-решения, чем его нужно дополнить (в терминах требований — это переходные требования и внешние зависимости, а в человеческих терминах — просто надо понимать, что одним IT-продуктом изменение, как правило, не обеспечивается).
Сотрудники:
Перестать ходить ножками в кафетерий за едой
Покроем в следующем пункте, т. к. он заменяет текущий
Заказывать еду в веб-приложении из офиса
Вход под своим аккаунтом (чтобы была привязка заказа к человеку) + выход (вероятно, тут же всякие нюансы по восстановлению пароля, смене пароля в личном профиле, активная сессия в течение какого-то времени)
Просмотр меню (которое кому-то из кафетерия надо в систему внести, а потому рядом стоит добавить и управление меню: добавление, редактирование, удаление пунктов меню)
Заказ/редактирование/отмена заказа
Оплата заказа (например, картой)
Уточнение деталей насчет заказа/доставки в службе поддержки
Кафетерий в лице менеджмента
Настроить новую структуру ролей и обязанностей, если услуги доставки там пока еще нет (новые обязанности для поваров, доставщики, служба поддержки)
Нам ничего делать не надо, кроме как убедиться, что это выполнено кафетерием и работает. Скорее всего, за это в целом будет отвечать заказчик решения, но очертить это всем присутствующим ЗЛ полезно.
Настроить процессы сбора заказов и их оперативной обработки
Аналогично тому, что выше. Можем помочь тут обучением пользованию решения.
Доставщики еды кафетерия
Оперативно доставлять заказы в Process Impact
Бизнес-процессы по доставке еды, если их еще нет в кафетерии. Аналогично, едва ли это будет наша зона ответственности, но пометим и обсудим, т. к. мы делаем общее дело во имя достижения цели.
Повара кафетерия
Оперативно готовить еду по заказам
Просмотр заказов
Давайте для большей полноты сформулируем и deliverables, которые могут вытечь из актеров, которые были помечены выше как «стоило бы проработать». Пропустим этап impacts и покажем просто, что еще может быть в результирующих планах на проект:
Подбор хостинга (внешний хостинг)
Анализ и учет бизнес-правил государства в сфере веб-приложений и сервиса доставки еды (политика приватности данных, размещение хостинга на территории государства, внесение в реестр коммерческой деятельности в Интернете, используемая на сайте валюта + какие-либо регуляции, которые нужно учесть кафетерию, который хочет начать доставлять еду) (государство)
Экспорт расходов на заказы по каждому человеку (отдел учета расходов Process Impact)
Интеграция с платежным провайдером (платежный провайдер).
Что мы по итогу сделали? Мы сгенерировали скоуп решения и дополнительные окружающие его аспекты путем последовательной проработки того, как мы можем достичь бизнес-цель. Все получившееся — это кандидаты в эпики, user stories, фичи, нефункциональные требования, дополнительные внешние зависимости, проектные работы и т. п. Конечно, с точки зрения требований это все еще нужно причесывать: что-то пойдет как функциональные или нефункциональные требования в контексте IT-решения (что, скорее всего, нас интересует в первую очередь), что-то — работы, которые надо проделать в дополнение к IT-решению (причем часть будет делать или контролировать заказчик или иные стейкхолдеры). Но в сумме это план, который реализует для заказчика достижение исходной бизнес-цели. Да, нужно понимать, что план этот весьма черновой и высокоуровневый, но для agile это как раз то, что нужно, на этапе discovery.
Как процессно можно организовать проработку Impact Map? В целом, вы вольны пользовать тут любую свою магию фасилитации совместных проработок чего-либо со стейкхолдерами, но пример может быть таким:
1) На входе у вас уже есть бизнес-цели и понимание того, чем будет конечное решение (например, вы выработали это ранее на похожей сессии по проработке Lean Canvas). 2) Организуете воркшоп с наиболее релевантными тире доступными стейкхолдерами — физическое или удаленное собрание. Напомню, что это может быть заказчик, представитель кафетерия, голодный сотрудник, вы, ваша команда (UX-специалист, технический лид, проектный менеджер, лид тестирования). 3) До/на воркшопе, как и для воркшопа по любой иной теме, убедитесь, что все понимают цель и ожидаемую ценность по итогу, плюс готовы активно работать. Это можно донести в агенде, плюс однозначно стоит пояснить на старте. 4) Опишите терминологию происходящего: что такое Impact Map, как вы будете поуровнево ее прорабатывать и что конкретно ожидается от каждого человека:
Работаем с конкретным уровнем карты в моменте.
Для каждого уровня я буду пояснять, что он означает и какие вопросы стоит задавать себе для генерации идей.
Вы «лепите» стикеры или добавляете ветки mind map в Miro в течение 5 минут (тут может быть любая ваша вариация процесса и инструментов для коллаборативного брейнрайтинга), после чего обсуждаем каждый (автор поясняет, остальные — комментируют), подчищаем дубликаты, приоритизируем.
Как сюда ложится User Story Map? User Story Map позволит взять этот план в той его части, которая касается целевого IT-решения, и превратить в качественное наполнение бэклога на старте проекта по разработке решения. Т. е. превратить по-черновому накиданные пункты в качественную нарезку на эпики и user stories. Но об этом в следующей статье.