Инструкции9 минут чтения

От расплывчатого запроса на функцию к чёткому плану реализации

Проследите на одном примере онбординга путь от открытого вопроса к небольшому улучшению, которое можно проверить, — с интеллект-картой, которая растёт по мере уточнения решений.

Кто-то говорит: «Нужно упростить онбординг».

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

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

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

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

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

1. Начните с запроса, но не принимайте его за ответ

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

Команда размещает в центре карты тему Улучшить онбординг и добавляет четыре ветви:

  • Создать аккаунт
  • Настроить рабочее пространство
  • Пригласить коллег
  • Вместе выполнить первое полезное действие

Так у разговора появляется структура. Вместо обсуждения «онбординга» как одной большой проблемы участники могут указать на конкретную часть пользовательского опыта.

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

Эти наблюдения указывают, что стоит изучить. Они не доказывают, что весь процесс онбординга нужно переделывать.

Команда оставляет остальные ветви на карте и сосредотачивается на ветви Пригласить коллег.

2. Отделите то, что знаете, от того, что предполагаете

Объяснение легко начинает звучать как факт, если кто-то произносит его уверенно.

«Люди не приглашают коллег, потому что процесс приглашения слишком сложный».

Возможно. Но им трудно найти форму приглашения, заполнить её или понять, зачем уже сейчас кого-то приглашать? Это разные проблемы.

В ветви о приглашениях команда создаёт три группы.

Наблюдения

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

Предположения

  • Более заметная точка входа помогла бы людям её найти.
  • Некоторые владельцы могут не понимать, что приглашение коллег — полезный следующий шаг.

Пока неясно

  • Могут ли владельцы заполнить существующую форму, когда находят её?
  • Понимают ли получатели приглашения, что делать дальше?

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

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

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

Теперь команда может сформулировать более узкую проблему:

“Новым владельцам рабочих пространств трудно найти, где пригласить коллег.”

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

Начните с разделения того, что вы наблюдали, и того, что ещё предстоит выяснить.

3. Рассмотрите несколько вариантов решения одной проблемы

Уточнив проблему, команда возвращается к возможным улучшениям. Она добавляет на карту три варианта:

  • Разместить действие Пригласить коллег на главном экране рабочего пространства.
  • Добавить шаг приглашения в процесс первоначальной настройки.
  • Позже отправить письмо с объяснением, как пригласить коллег.

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

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

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

Не нужно наносить на карту все мыслимые решения. Начните с нескольких правдоподобных вариантов и спросите:

  • Помогает ли это справиться с наблюдаемой трудностью?
  • Будет ли это полезно в тот момент, когда владельцу нужна помощь?
  • Что нужно выяснить или изменить, чтобы это сработало?

Полезная карта упрощает обсуждение этих вариантов. Больше ветвей не всегда означает лучше.

Сравните несколько вариантов решения одной проблемы, прежде чем выбрать один.

4. Выберите один полезный первый шаг

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

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

Это отправная точка, а не утверждение, что все проблемы онбординга решены.

Команда дополняет выбранную ветвь согласованным объёмом работ и рядом с планом записывает отложенные идеи и вопросы для дальнейшего изучения:

В этом улучшении

  • Добавить на главный экран рабочего пространства действие приглашения с понятной подписью.
  • Открывать существующую форму приглашения по этому действию.
  • Сохранить текущие права на приглашение и логику отправки.

Позже

  • Рассмотреть, нужен ли шаг приглашения в первоначальной настройке.
  • Рассмотреть, будет ли полезно последующее напоминание.

Нужно изучить

  • Проверить опыт получения и принятия приглашения.

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

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

Разверните выбранное улучшение в небольшой, явно описанный объём работ.

5. Опишите, что человек должен иметь возможность сделать

«Добавить кнопку приглашения» описывает изменение интерфейса. Это мало говорит об опыте, который команда хочет создать.

Полезнее спросить:

“Что владелец рабочего пространства должен иметь возможность сделать после завершения этого улучшения?”

Команда согласовывает короткий набор проверок:

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

Это критерии приёмки: наблюдаемые условия, с помощью которых команда может проверить свою работу. Их не обязательно формулировать как техническую спецификацию.

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

Кнопка может работать точно по спецификации и всё равно оставаться незамеченной.

6. Перенесите согласованную работу в Jira

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

Команда создаёт одну задачу в Jira для согласованного результата. Она не создаёт задачу для каждой ветви карты.

Вот что может содержать такая задача:

Название: Сделать приглашение коллег доступным с главного экрана рабочего пространства

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

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

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

Критерии приёмки: Включить проверки, согласованные в предыдущем разделе.

Контекст планирования: Добавить ссылку на карту, чтобы любой участник работы над задачей мог увидеть наблюдения, альтернативы и решение об объёме работ.

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

Ветвь упорядочивает мысли. Задача описывает работу. Между ними не обязательно должно быть соответствие один к одному.

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

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

Выберите согласованное улучшение, проверьте его краткое описание и критерии приёмки, затем создайте задачу. На этом скриншоте показан выбор до создания задачи.

7. Проверьте, стало ли проще справляться с исходной проблемой

После выпуска изменения команда возвращается к ранее записанной формулировке:

“Новым владельцам рабочих пространств трудно найти, где пригласить коллег.”

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

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

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

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

Исходный запрос был широким. Получившийся план конкретен: ясная проблема, выбранное решение, посильный объём работ и способ проверить, помогло ли оно.

Именно это делает карту полезной. Она ведёт разговор от «это стоит улучшить» к согласованному следующему шагу, сохраняя на виду логику решения и вопросы, которые ещё предстоит закрыть.

#MindMapping#ProductManagement#Jira#ProductDiscovery

Похожие статьи

Связаться

Есть вопросы по этой статье? Обсудим ваши инженерные цели.

Контактные данные