BRIDGeS Framework: универсальный подход к принятию бизнес-решений

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

Меня зовут Сергей Королёв, я управляющий директор компании Railsware. В зону моих ответственностей в том числе входит разработка продуктов и развитие продуктовой культуры. В своей статье я хочу вам рассказать об универсальном фреймворке BRIDGeS, который помогает нам принимать решения различной сложности и создавать продукты с помощью мультиконтекстного анализа.

BRIDGeS могут использовать руководители С-level, продакт менеджеры, бизнес аналитики, инженеры и другие специалисты. Если вы занимаетесь разработкой продуктов, операционной деятельностью, принимаете стратегические и тактические решения, такой инструмент наверняка вам пригодится.

У истоков

В 2011 году, работая над совместными проектами с командой Pivotal Labs, мы познакомились с дискавери подходом Inception, который сильно вдохновил нас. Впоследствии мы начали применять его в комбинации с различными фреймворками, такими как Lean Canvas, Value Proposition Canvas, Job-to-be-done и другими.

Тем не менее, так как одни инструменты заточены на бизнес, а другие — на продукт, нам не хватало универсальности. Чтобы одновременно работать над разными контекстами, мы объединяли и адаптировали отдельные элементы из разных методологий. Нам хотелось получить универсальный инструмент для работы с бизнес-задачей — от построения продукта до оптимизации процессов компании. В результате на свет появился BRIDGeS Framework.

Основные элементы и механика BRIDGeS

Название фреймворка BRIDGeS — это аббревиатура главных его элементов — Benefits, Risks, Issues, Domain knowledge, Goals, Solutions. Сам фреймворк состоит из двух частей — Problem Space, где описывается контекст проблемы и приоритизируются потребности, и Solution Space, в котором отображаются варианты решения и его детализация.

Механика работы с фреймворком проста и заключается в четырех шагах:

1. Описание проблемы.

На этом этапе описывается контекст проблемы — определяются основные Subjects (субъекты) и их Descriptors (дескрипторы).

Ключевой элемент фреймворка BRIDGeS — Subjects (субъекты) — это стейкхолдеры, вовлеченные в контекст проблемы, которые в итоге должны получить выгоду от конечного решения. Это могут быть: пользователь, роль, тактика, стратегия, решение, действие, событие и так далее. В зависимости от задачи субъект — это не всегда одушевленный предмет.

Определив ключевые субъекты, их анализируют с помощью присущих им характерных признаков — Descriptors (дескрипторов):

• Benefits — выгоды, которые субъект может получить от будущего решения;
• Issues — проблемы субъекта на текущий момент;
• Risks — потенциальные проблемы, которые могут возникнуть;
• Domain knowledge — дополнительная информация о субъектах или о контексте проблемы в целом, которую важно учесть;
• Goals — ожидаемый результат от будущего решения.

2. Приоритизация потребностей.

Чтобы выбрать правильный вектор для разработки решения, важно приоритизировать все упомянутые дескрипторы. Это поможет избежать пустой траты ресурсов на разработку ненужных решений.

Из существующих методов приоритизации во время сессий BRIDGeS мы пользуемся подходом MoSCoW. Это простой, но эффективный метод, который можно применять на любом этапе проекта для приоритизации задач, с учетом временных рамок или без них. Название является аббревиатурой от категорий приоритетности — Must, Should, Could и Won’t.

Таким образом, возвращаясь к фреймворку BRIDGeS, после определения всех дескрипторов во время описания проблемы, мы маркируем каждый из них, определяя, что самое важное (Must), должно учитываться (Should), можно, но не критично (Could), и не нужно брать во внимание (Won’t).

3. Поиск возможных решений.

На этом этапе работа перемещается во вторую рабочую зону — Solution Space, где описываются потенциальные решения, исходя из потребностей, ранее описанных в контексте проблемы (Problem Space). Здесь определяются векторы возможных решений, которые будут детализироваться уже на следующем этапе.

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

4. Детализация решений.

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

В качестве инструмента для сессий BRIDGeS рекомендуем использовать виртуальную доску (Figma, Mural).

Как это работает?

Чтобы вышенаписанное стало понятней, предлагаю рассмотреть все это в действии на примере. Возьмем всем известный Uber в то время, когда он только зарождался как идея. Мы не знаем, как реальные основатели организовали процесс разработки самой идеи, но предлагаю немного пофантазировать и представить, как бы это все могло выглядеть с фреймворком BRIDGeS.

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

Итак, начнем с первого шага — описание сути проблемы. Здесь мы определяем основные цели (Goals), основных стейкхолдеров — субъектов (Subjects), которые будут получать выгоду от будущего решения, или каким-либо образом сопричастны к нему. Затем по каждому субъекту анализируем проблемы, потребности и риски соответственно (Issues, Benefits, Risks). Также не забываем про дополнительные факты, которые важно учесть в контексте описания проблемы (Domain knowledge).

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

Теперь проанализируем каждый субъект с помощью дескрипторов — сфокусируемся на потребностях и текущем опыте пассажиров и водителей.

На рисунке ниже показано, как будет выглядеть готовый Problem Space. Обратите внимание на цвета карточек, они не случайны. Субъекты всегда отображаются в больших зеленых прямоугольниках — в нашем случае это водитель, пассажир и компания. Дескрипторы изображаются на прямоугольниках поменьше: зеленые — Benefits, желтые — Risks, красные — Issues, сиреневые — Domain knowledge, голубые — Goals.

На рисунке можно рассмотреть, какие выгоды (зеленые Benefits) может получить от сервиса водитель: легкая регистрация в службе, быстрый заработок, служебное авто и дополнительный источник дохода. На красных карточках изображены проблемы (Issues), которые есть у водителей на текущий момент: сложности с получением соответствующей лицензии водителя такси и нехватка поездок за смену.

Таким же образом определяют дескрипторы для каждого субъекта, размещая соответствующие карточки рядом с ним. На рисунке вы можете заметить группу карточек, которые расположены посередине — это дескрипторы, которые релевантны как для водителя, так и для пассажира.

Например, такое преимущество (Benefit) как справедливая цена, или проблема в коммуникациях с колл-центром, или риски, которые связанные с безопасностью. Представим, что во время изучения рынка оказалось, что 75% пассажиров не довольны текущим сервисом такси. Эта информация и есть наша Domain knowledge, которая может нам пригодится позже. Мы фиксируем эту информацию на сиреневой карте.

Компания Uber — это наш ключевой субъект. На голубых карточках сформулированы цели, которые ставит перед собой компания — трансформировать работу такси сервиса и заполучить 75% доли рынка.

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

Когда весь контекст проблемы красиво разложен на карточках, мы приступаем к следующему этапу — приоритезации — чтобы понять, за какие задачи браться в первую очередь, и отсеять все не важное. Используя технику MoSCoW, мы маркируем каждую карточку с benefits, risks и issues, таким образом определяя, что критично, желательно, возможно, и не стоит брать во внимание. Вы можете видеть эти маркеры на рисунке в правом верхнем углу карточек.

Тип карточки не влияет на приоритезацию: например, выгода (benefit) может быть важнее проблемы или риска. После того, как все карточки приоритезированы, можем передвигаться во вторую рабочую зону — Solution Space — и приступать к работе над решением проблемы.

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

Все варианты мы фиксируем на карточках синего цвета согласно цветовой легенде и размещаем в Solution Space.

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

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

Исходя из дескрипторов в нашем примере, можем выделить такие эпики: «поездка», куда мы будем добавлять все задачи, связанные поездкой, «оплата», «коммуникации», «безопасность» и «аккаунт».

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

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

Вот так это выглядит:

Вы, наверное, успели заметить на рисунке маркеры приоритетов MoSCoW. После того, как все проблемы, выгоды и риски покрыты задачами, их тоже стоит приоритезировать таким же способом, как мы это делали во время описания контекста проблемы. Иначе как понять, за что браться в первую очередь?

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

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

Вуаля! Можно приступать к реализации.

Надеюсь, с этим примером механика фреймворка стала понятнее. Мы сейчас работаем над разработкой других, не только продуктовых, кейсов, чтобы продемонстрировать использование BRIDGeS со всех сторон.

Что отличает BRIDGeS от других фреймворков

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

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

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

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

• Рекурсивное применение
  После описания контекста проблемы и ее анализа, мы приходим к возможным вариантам решений. Чтобы убедиться в их жизнеспособности и релевантности, BRIDGeS поможет проанализировать каждое из решений — определить выгоды, риски и проблемы, которые могут помешать реализации задачи.

• Глубокое понимание контекста
  BRIDGeS позволяет исследовать контекст достаточно глубоко, чтобы найти оптимальное решение.

• Точность
  На протяжении всей сессии участники сопоставляют контекст проблемы в Problem Space и детали решения в Solution Space. Это делается для того, чтобы убедиться, что каждая потребность и риски учтены, и на все вопросы дан ответ. Такой подход позволяет не упустить важных деталей.

Выводы

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