Качества хорошего продуктового бэклога

Часто смотрю в наш бэклог и задаюсь вопросом — а всё ли с ним в порядке? Является ли он настолько полным и здоровым, что сможет продолжить работу, даже если текущий продакт/проект-менеджер, отвечающий за его наполнение, исчезнет?

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

Начну с базовых вещей:

Общее видение команд(ы)

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

Похоже на классическую "продуктовую воронку", где вместо юзеров ты и команда и вы движетесь по конверсиям (гипотезам/экспериментам/релизам/спринтам) внутри своего же продукта :)

Возвращаясь к бэклогу. Это инструмент для достижения цели и если её не знают/не понимают, то никакой инструмент не поможет её(??) достигнуть.

Единое мышление

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

Наверное, есть какое-то научное обоснование, но думаю, что мозгу просто легче и комфортнее в среде таких же мозгов — не приходится тратить лишнюю энергию на постоянное подстраивание под "инакомыслящих" (или их под других) и... эффективность работы мозга => процессов растёт.

Применимо к бэклогу это означает, что все в команде должны придерживаться выбранной методологии работы с задачами и общих процессов: описывать свои гениальные идеи хотя бы на 2-3 предложения, заполнять "все эти чертовы поля в задаче", не тегать всех подряд и своевременно задавать уточняющие вопросы и отвечать на комменты в таск-менеджере, а не Слаке.

Нет историй и задач, которые вы еще не собираетесь реализовывать

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

И да, от того, что лишние сторис и второстепенные задачи будут висеть в бэклоге, они не запилятся быстрее :)

Формализованный бэклог

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

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

Оцененный бэклог

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

Точный бэклог

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

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

Приоритезированный бэклог

Придумана куча методологий и моделей, позволяющих приоритезировать задачи по различным критериям - "5 фреймворков для приоритезации продуктовых фич"

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

Распланированный бэклог

Совсем неплохо, когда в бэклоге лежат формализованные задачи, которыми можно забить 2-3 спринта вперёд. Команде же надо прикинуть, кому и когда выходить в отпуска :)

Экспериментальный бэклог

Хорошим продуктовым тоном считаются задачи-эксперименты, которые встраиваются в бэклог и далее спринты и в которых тестируются те или иные продуктовые гипотезы.

Пара советов в качестве заключения:

• Не циклись на одной методологии — бери лучшее от каждой. И да, всё равно все мы в глубине души работаем (или хотим работать) по Agile.
• Просто и понятно. Не сыпь терминами и аббревиатурами — маркетолог может не знать что такое кеширование и асинхронная подгрузка кода, а разработчик то, как работает Google Optimize. Твоя задача сделать так, чтобы они оба, в конечном счете, поняли, как вам всем проводить A/B-тесты.
• Проводи периодически груминг бэклога (grooming — стрижка или подрезка с целью "подровнять" красоту). Это совместные действия команды, цель которого — зачистить бэклог от лишней информации/задач/сторис, оставив лишь самое важное и главное. Гуру-скрама выделяют на это отдельный день и время в каждом спринте.
• Сейчас в меня полетят камни за такой совет, но... покажите бэклог/родмэп продакт-овнеру. Обсудите текущие статусы, поделитесь планами и целями (и еще раз заапрувьте их, так, на всякий слукчай), расскажите об успехах и том, что затрудняет путь к ним. Синхрон между овнерами и продактами либо успешен, и все рады, либо это рассинхрон, последствия которого не обрадуют ни одну их сторон.
• Бэклог, как и спринт — понятия растяжимые.