Спринты, карты пользователей и архитектурные схемы уже давно перекочевали с бумажных стикеров на стене в онлайн-доски. Но часто команды на этом останавливаются и большую часть задач продолжают выполнять в тексте или табличках. В итоге разработка и планирование релизов структурированы на доске, а все остальное остается в документах: текстовый файл с результатами кастдева, таблица с итогами ретроспективы, которую никто не перечитывает, и презентация с роадмапом, которая устарела еще до того, как ее показали стейкхолдерам. Продакт-менеджер Битрикс24 Ольга Чепюк делится сценариями, которые помогут использовать доску максимально эффективно.
Принципиальная разница между доской и любым текстовым инструментом — в том, как мы воспринимаем информацию. Когда мы смотрим на карточки, стрелки, кластеры и связи между ними, мы видим систему. Так происходит, потому что мозг обрабатывает пространственно организованную информацию более целостно, запоминая и факты, и связи между ними.
Визуальное мышление особенно важно в продуктовой разработке, где постоянно приходится работать с гипотезами и конкурирующими приоритетами. Текст не всегда может передать напряжение между «хотим» и «можем», между «пользователь должен делать» и «пользователь делает». Визуальный формат справляется с этим в разы лучше.
Также в онлайн-досках всегда есть возможность командной работы, в отличие от текстовых и табличных редакторов без онлайн-версии. На доске несколько человек могут одновременно редактировать, добавлять новое и комментировать, что делает встречи более продуктивными. Вместо того чтобы смотреть на экран одного человека, который что-то записывает, вся команда участвует в процессе, и ни одна идея не останется упущенной.
От интервью к инсайту
Customer Journey Map, пожалуй, самая классическая задача для продуктовой команды. Не будем проходиться по базе и говорить, как здорово строить их в онлайн-досках, — перейдем к тому, как сделать CJM сильным опорным материалом.
Всегда прикрепляйте к каждому шагу карты первичные материалы: цитаты из интервью, скриншоты, референсы. На этапе разработки это может показаться лишней, никому не нужной работой, но когда вам будет нужно вернуться к прошлым CJM, вы себя поблагодарите. Все аргументы, которыми вы руководствовались тогда, будут под рукой и послужат основой для новых решений.
Также можно усилить CJM другими фреймворками, например, картой болей и драйверов. В связке этих карт будет видно, чего боится и что ищет клиент на каждом шаге, и приоритезировать бэклог станет проще.
Как зафиксировать все детали
Отсматривая пятнадцать пользовательских интервью, можно легко утонуть в деталях: несколько часов записей, сотни цитат и противоречивых сигналов. Емко структурировать это в текстовом документе почти невозможно. Эту задачу решает кластеризация основных паттернов, где каждое значимое высказывание переносится на отдельный стикер, затем стикеры группируются по темам.
Такой подход называется affinity mapping, он считается одним из самых популярных UX-методов. Структурированные результаты остаются доступными всей команде, и когда через три месяца кто-то спросит «А что пользователи говорили про онбординг?», ответ можно будет найти в группе цитат вместо обезличенного общего вывода.
Лучше всего фиксировать три слоя данных: что пользователи говорят, что они делают по данным аналитики и как команда это интерпретирует. Дальше на основе этой информации можно и принимать решения, и валидировать последующие сессии кастдевов.
Генерация гипотез и приоритезация
Качественная организация продуктового брейншторма никогда не начинается с вопроса «какие фичи мы можем добавить в новом спринте?». В начале планирования важно сформулировать приоритетную проблему, которую нужно решить в течение продуктового цикла. Доска удобна тем, что выбранную проблему можно буквально поместить в центр и разворачивать идеи вокруг нее.
После генерации идей наступает очередь приоритезации. Самый простой способ — матрица Value/Effort: четыре квадранта, в которые каждый участник команды перемещает карточки по своему усмотрению. Картина мнений выстраивается на глазах у всей команды и становится отправной точкой для обсуждения.
Если команда готова к чуть более структурированному подходу, стоит попробовать фреймворк RICE. Каждая гипотеза получает оценки по четырем параметрам — Reach, Impact, Confidence, Effort, затем по суммарному рейтингу можно отранжировать задачи в бэклоге. На практике этот подход сложнее первого, но дальнейшую работу он, как и любая качественная подготовка, сильно упрощает.
Ретроспектива, которая улучшает процессы
Многие команды проводят ретроспективу по привычке, почти ничего не меняя в процессе работы по ее итогам. Типичное ретро выглядит так: тимлид или модератор спрашивает «что было хорошо, что плохо», команда называет несколько пунктов, ответственный записывает их в документ, и встреча заканчивается без изменений.
Если проводить ретро на базе фреймворка на доске, дискуссия идет куда активнее, и выводы не теряются, когда все расходятся. Каждый добавляет карточки самостоятельно, без давления группы, честность ответов растет, и на поверхность выходит то, о чем обычно молчат. Формат при этом можно менять каждый спринт: Start-Stop-Continue, Sailboat, Mad-Sad-Glad — для ретро существует огромное количество креативных шаблонов. Так встреча перестает ощущаться как ритуал ради ритуала. А еще, когда ретроспектива структурирована так, к ней гораздо проще возвращаться спустя время, чтобы оценить, что команда обещала себе месяц назад и что из этого выполнила.
Связи, которые нельзя потерять
Даже для продуктовых команд со стажем планирование релиза — стрессовый период, в котором нужно все учесть и ничего не забыть. За каждым релизом стоит цепочка зависимостей: инфраструктура должна быть готова раньше фичи, полная документация нужна поддержке до выхода в прод, коммуникация с пользователями зависит от того, когда маркетинг оформит материалы. В таблице и диаграмме Ганта не всегда получается учесть всю сложность этих связей. Но если визуализировать процесс на доске со стрелками, swimlanes по командам и цветовой кодировкой по статусам, сдвиг в одном месте сразу покажет всю цепочку сопутствующих изменений.
Отдельная история, которой мы коснулись в примере выше — планирование коммуникации вокруг релиза. Кто из пользователей получит уведомление, в каком канале, с каким сообщением и в какой момент лучше всего планировать на одной доске и сразу согласовывать с маркетингом и поддержкой, чтобы релиз прошел гладко.
Техническая архитектура и флоу разработки
Продуктовый менеджер не обязан разбираться в технической архитектуре на уровне разработчика. Но понимать, как устроена система, необходимо, иначе будет невозможно адекватно оценить сложность задач и сроки их выполнения.
В этом случае доска вновь становится отличным местом для кросс-командного диалога: между продуктом и разработкой. Схему сервисов, диаграмму потоков данных, пользовательские сценарии в виде флоу можно разместить рядом и обсуждать в одном пространстве. Некоторые команды даже ведут на доске так называемые «карты системы»: упрощенные схемы, которые показывают, как разные части продукта работают и как они связаны между собой. Такая карта помогает быстро объяснить новому члену команды, как это все работает, и дает контекст для любого разговора об изменениях.
Один инструмент или экосистема?
Когда с доски можно перейти к проектам и чатам, она становится центром принятия решений. Именно поэтому некоторые платформы для совместной работы включают доски в более широкую экосистему. Например, в Битрикс24 доски встроены в общую рабочую среду вместе с задачами, чатами и CRM — это позволяет работать в едином пространстве без лишних переключений.
Эффективная работа с досками также зависит от культуры их использования в компании. Доска, с которой команда работает регулярно, становится полноценным инструментом управления продуктом.
Почему доска часто остается холстом для стикеров
Самый частый барьер — перфекционизм. «Мы сначала разберемся, как правильно, а потом попробуем внедрить». Но правильного способа не существует. Лучший способ использовать доски по-новому — внедрить их в простой и понятный процесс, например, провести следующую ретроспективу по фреймворку Sad-Mad-Glad и посмотреть на результаты.
Второй блокер — привычка пользоваться текстовыми документами. Некоторым людям непривычно работать с визуальными инструментами, и это нормально. Как правило, после нескольких совместных сессий большинство команд не хотят возвращаться к старому формату.
Третий, пожалуй, самый распространенный — потенциал досок часто недооценивают. Их используют для стикеров на брейншторме, хотя их возможности гораздо шире: в досках можно строить исследовательские базы, архитектурные карты, системы приоритезации и многое другое.
Надеюсь, что в этой статье были новые для вас идеи, как можно применить этот инструмент, и вы попробуете применить их в работе.