Превращение информации в идеи с помощью пирамиды разговора с клиентом

Вы поговорили с клиентами и сделали подробные заметки. Что дальше?

Sherif Mansour Автор: Sherif Mansour
Просмотр тем

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

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

Одним словом, вы будете проектировать и создавать более удобные и качественные продукты.

Ранее я уже писал о множестве различных способов достижения взаимопонимания. (Если вы еще не читали эти материалы, сначала ознакомьтесь с ними. Я подожду… Хорошо, давайте продолжим.) Прежде чем начать составлять документ с требованиями к продукту, подумайте о других приемах, которые можно применить для достижения взаимопонимания. В Atlassian мы используем разговоры с клиентами.

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

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

Пирамида разговора с клиентом: схема передачи информации по итогам разговора

За последние несколько лет мы в Atlassian создали простую схему, помогающую нам выполнять такую трансформацию, — это пирамида разговора с клиентом. Выглядит она следующим образом:

Пирамида разговора с клиентом | Atlassian — тренер по agile

Идея проста. Позвольте мне провести вас по этой пирамиде и описать цели каждого этапа. Воспользуемся для этого примером.

Представьте, что на дворе 2002 год. Мир до Twitter и Facebook. (*вздох*) Кнопки «нравится» не существует. Слово «tweet» используется в английском только для того, чтобы описать детям звук, издаваемый птицами. Вы работаете над проектом, который станет прорывом… социальной сетью.

Не поддавайтесь искушению записывать наблюдения

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

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

Реализация пирамиды разговора с клиентом в команде

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

Главная страница нашего раздела для разговоров с клиентами выглядит так:

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

Что внутри шаблона для разговора с клиентом

Наш шаблон для разговора с клиентом имеет простую структуру.

Предпосылки

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

Сведения о компании

  • Цель этого раздела — предоставить читателям дополнительный контекст о работе собеседника. Чем занимается его или ее компания?

Наблюдаемые проблемы

  • Для перечисления всех наблюдаемых проблем мы обычно используем список содержимого.

Для каждой проблемы нужно указать следующее.

  • Формулировка проблемы в одну строку. Будьте лаконичны. Сформулируйте стремление пользователей, а не запрос функции.
  • Наблюдения, которые приводят вас к заключению о наличии проблемы. Не забудьте включить скриншоты, записи или практические примеры, чтобы предоставить читателю контекст.
  • Имеющиеся у вас возможности для решения этой проблемы. Укажите ссылки на связанные эпики, задания или запросы функций в Jira Software или на других ресурсах, которые вы используете для управления бэклогом команды. Здесь одним из главных преимуществ является то, что в следующий раз, когда вы откроете задание Jira Software, вы сразу получите из этого разговора контекст, который поможет выстроить взаимопонимание.

Большая часть записей разговоров будет состоять из множества высказываний вида «наблюдения → проблемы → возможности». Мы обнаружили, что эта схема действительно полезна для четкой формулировки полученной информации и ее превращения в план действий.

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