Давайте поговорим о двух клевых техниках для проработки скоупа решений — 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). Это те, кто могут поспособствовать или помешать достичь бизнес-целей. Наводящие вопросы:
Мы знаем контекст сформулированной выше бизнес-цели: увеличиваем эффективное время сотрудников мы за счет автоматизации заказа еды и избавления от необходимости ходить в кафетерий, а потому, отвечая на вопросы выше, мы можем сгенерировать такой набор актеров:
·Актеры, которых также стоило бы проработать, но сократим, дабы не усложнять пример:
Вероятно, вы заметили, что фактически мы сейчас сделали урезанную идентификацию заинтересованных лиц (ЗЛ). Урезанную, т. к. вопросы, на которые мы отвечали, это не на 100% равенство термину «заинтересованное лицо», и у нас в этом контексте могут остаться пробелы. Но обратите еще раз внимание на вводную о ярких чертах Agile-техник.
В целом, на этом этапе вам все-таки может помочь понимание того, кто такие ЗЛ и каких категорий они могут быть, но и без этого сочетание коллективного разума и бредогенерации могут помочь в устранении пробелов.
Третий уровень карты — это воздействия (impacts). Это желаемое изменение в поведении актера, которое позволит достичь бизнес-целей. Т. е. что мы хотим от актеров в плане изменения их поведения, чтобы поспособствовать достижению бизнес-цели. Наводящие вопросы:
Давайте набросаем, помня о том, что наша цель — увеличить среднее эффективное рабочее время сотрудников за счет автоматизации заказа еды.
Сотрудники
На этом уровне также, вероятно, получилось много пробелов, но надо понимать, что я набрасывал идеи в одно лицо. Если бы под рукой был заказчик, представитель кафетерия, голодный сотрудник, плюс моя команда (например, в лице ключевого UX-специалиста и технического лида), то результат получился бы существенно более надежный.
Последний, четвертый уровень карты — это решения в ответ на каждый impact (deliverables). Т. е. что мы в плане решений мы можем дать или должны сделать, чтобы обеспечить желаемые impacts актеров. В первую для нас очередь, сюда будут входить функциональные возможности целевого IT-решения. Но также могут быть и важные нефункциональные требования или что-то вне рамок IT-решения, чем его нужно дополнить (в терминах требований — это переходные требования и внешние зависимости, а в человеческих терминах — просто надо понимать, что одним IT-продуктом изменение, как правило, не обеспечивается).
Сотрудники:
Кафетерий в лице менеджмента
Доставщики еды кафетерия
Повара кафетерия
Давайте для большей полноты сформулируем и deliverables, которые могут вытечь из актеров, которые были помечены выше как «стоило бы проработать». Пропустим этап impacts и покажем просто, что еще может быть в результирующих планах на проект:
Что мы по итогу сделали? Мы сгенерировали скоуп решения и дополнительные окружающие его аспекты путем последовательной проработки того, как мы можем достичь бизнес-цель. Все получившееся — это кандидаты в эпики, user stories, фичи, нефункциональные требования, дополнительные внешние зависимости, проектные работы и т. п. Конечно, с точки зрения требований это все еще нужно причесывать: что-то пойдет как функциональные или нефункциональные требования в контексте IT-решения (что, скорее всего, нас интересует в первую очередь), что-то — работы, которые надо проделать в дополнение к IT-решению (причем часть будет делать или контролировать заказчик или иные стейкхолдеры). Но в сумме это план, который реализует для заказчика достижение исходной бизнес-цели. Да, нужно понимать, что план этот весьма черновой и высокоуровневый, но для agile это как раз то, что нужно, на этапе discovery.
Как процессно можно организовать проработку Impact Map? В целом, вы вольны пользовать тут любую свою магию фасилитации совместных проработок чего-либо со стейкхолдерами, но пример может быть таким:
1) На входе у вас уже есть бизнес-цели и понимание того, чем будет конечное решение (например, вы выработали это ранее на похожей сессии по проработке Lean Canvas).
2) Организуете воркшоп с наиболее релевантными тире доступными стейкхолдерами — физическое или удаленное собрание. Напомню, что это может быть заказчик, представитель кафетерия, голодный сотрудник, вы, ваша команда (UX-специалист, технический лид, проектный менеджер, лид тестирования).
3) До/на воркшопе, как и для воркшопа по любой иной теме, убедитесь, что все понимают цель и ожидаемую ценность по итогу, плюс готовы активно работать. Это можно донести в агенде, плюс однозначно стоит пояснить на старте.
4) Опишите терминологию происходящего: что такое Impact Map, как вы будете поуровнево ее прорабатывать и что конкретно ожидается от каждого человека:
Как сюда ложится User Story Map? User Story Map позволит взять этот план в той его части, которая касается целевого IT-решения, и превратить в качественное наполнение бэклога на старте проекта по разработке решения. Т. е. превратить по-черновому накиданные пункты в качественную нарезку на эпики и user stories. Но об этом в следующей статье.
Визуальный пример проработанной в статье карты:
Начнем с того, что и 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
- Консультировать по телефону
- Оперативно готовить еду по заказам
На этом уровне также, вероятно, получилось много пробелов, но надо понимать, что я набрасывал идеи в одно лицо. Если бы под рукой был заказчик, представитель кафетерия, голодный сотрудник, плюс моя команда (например, в лице ключевого 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. Но об этом в следующей статье.
Визуальный пример проработанной в статье карты:
