Постановка проблемы через разные виды целей (Outcomes vs Outputs)

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

‍

Чёткое определение помогает нам различать три совершенно разных подхода к постановке целей: ориентация на результат (output), ориентация на желаемый результат для клиента (outcome) и ориентация на долгосрочный бизнес-результат (impact).сЭти подходы основаны на трёх совершенно разных мировоззрениях и ментальных моделях, каждая из которых имеет свои собственные модели, процессы и инструменты.

‍

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

‍

Изменение самого высокого уровня, которое вы можете запланировать, — это то, что в структуре целей называется воздействием (impact). Это важные высокоуровневые цели и показатели того, как работает бизнес, и они имеют решающее значение. Но проблема в том, что они настолько общие и запаздывающие, что нужно понять результаты, которые создают воздействие, к которому мы стремимся. Это позволяет перейти к чему-то, что действительно применимо на индивидуальном или командном уровне.

‍

Долгосрочная бизнес-цель (impact) зависит от достижения продуктовых целей (outcome). Для достижения продуктовых целей нужно разработать решение (разработка измеряется через output).

‍

Показатели воздействия (impact) являются запаздывающими индикаторами. Другими словами, они оглядываются назад на то, что уже произошло. Все, что можно измерить как изменение поведения клиента (чаще всего это метрики использования продукта: конверсии в целевые действия и т. п.), — являются опережающими индикаторами. Это тактические показатели, которые дают представление о том, как будут работать наши показатели воздействия в будущем.

‍

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

‍

Результаты (outputs) — это то, что вы получаете, когда действие выполнено. Это может быть что угодно: от запущенных продуктов и функций до предоставленных услуг, обучения команды ключевым методам безопасности. Фокус здесь — максимизация количества производимых «материалов» (функций, эпиков, продуктов). Это правильный подход, когда делается крупная ставка, которая с высокой вероятностью приведёт к положительному влиянию.

‍

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

‍

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

‍

‍

Переход от результатов к результатам означает изменение вашего понимания прогресса

‍

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

‍

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

‍

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

‍

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

‍

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

‍

‍

Постановка проблемы

‍

С какой ключевой проблемой вы сталкиваетесь?

‍

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

‍

Простое эмпирическое правило для написания хорошего описания проблемы— избегать упоминания вашего решения, а говорить о сегментах, состоянии пользователя и их боли, то есть делать постановку через желаемый результат (outcome) и добавлять меру измерения [метрику] с [базовым значением] и [целевым значением] к [дате].

‍

Изменяется подход к обсуждению работы:


‍

1. Какова текущая ситуация, на которую мы намерены повлиять?
2. Как это будет выглядеть, когда мы достигнем желаемой результата?
3. Какое поведение пользователей необходимо изменить, чтобы достичь этого результата?
4. Что необходимо пользователям, чтобы изменить поведение?
5. Какие действия необходимо выполнить, чтобы вызвать необходимое изменение?
6. Какие ресурсы потребуются для достижения желаемого результата?

‍

Пример

‍

Представьте, что вы разрабатываете контентный сервис, успех которого можно выразить в выручке (impact). Чтобы добиться этой цели, необходимо увеличить среднюю продолжительность использования сервиса с X часов в неделю до Y часов в неделю (outcome). Вы определяете несколько возможностей, например внедрить просмотр трансляции мероприятий в прямом эфире, и задаёте критерий успеха как среднюю продолжительность просмотра прямых трансляций (outcome второго уровня, относящийся к сегменту «прямые трансляции»).

Для этого вы решаете запустить MVP для подключения сервиса и разрабатываете его дизайн к дате Z (output — конкретная задача). Чтобы выполнить работу, вы нанимаете дизайнера (действия и ресурсы).

‍

Что происходит в продуктовых компаниях: мы хотим увеличить выручку за счёт увеличения среднего времени просмотра и выхода в сегмент прямых трансляций мероприятий. Мы протестировали интерес с помощью <набор экспериментов> и хотим реализовать MVP <фича 1, фича 2, фича 3>, чтобы провалидировать идею. Критерием успеха будет увеличение среднего времени просмотра с X часов в неделю до Y часов в неделю. Для этого нам нужны ресурсы дизайнера и разработчика в количестве N часов. Мы придём с первыми результатами через 1,5 месяца.

‍

Что происходит в непродуктовых компаниях: мы заметили, что у конкурента есть прямые трансляции; кажется, они пользуются популярностью среди пользователей, во всяком случае реклама висит на главном экране приложения. А что если нам тоже сделать эту фичу? Тем более идею уже обсуждали с руководством. Мы сделали прототип решения. Для его реализации нам нужно <куча ресурсов дизайна и разработки>. Мы посчитали, что сможем заработать <кучу денег>, потому что подписку купят ещё X человек.

‍

Чёткое понимание входных данных, выходов (outputs) и конечных результатов (outcomes) помогает структурировать рабочие сессии, отслеживание прогресса, обновление отчётности и связать ежедневную работу с квартальными и годовыми целями компании.