Воскресный лонгрид, сегодня поговорим про бэклог и задачи, которые ставит продакт, какими они должны быть?

Как продакту создать идеальный бэклог? Практические рекомендации Бэклог (backlog) — это не просто список задач, которые нужно выполнить. Это план развития продукта, который говорит о его текущем состоянии и направление движения. Создать хороший бэклог — не такая простая задачка, как может показаться. Ниже рекомендации, как это сделать.

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

Рекомендации: - Периодически перетряхивайте бэклог: выкидывайте задачи, которые больше не актуальны, так сказать, проводите "генеральную уборку". - Оценивайте задачи по важности для бизнеса, трудоёмкости и срочности. Это не просто полезный навык, а почти искусство. Бездумное погружение в мелочи  превратит ваш бэклог в бесполезное месиво. Всегда помним: важное не всегда срочно, срочное не всегда важно. - Если приоритеты изменились — двигайте задачи. Нельзя относиться к бэклогу как к застывшему в янтаре комару. Переоценка, изменения приоритета, перестановка задач — это всё инструменты управления бэклогом, пользоваться ими можно и нужно. Ну мы же не проектами ватерфолльными управляем, право дело! (тут половина проджектов тяжко вздохнула, а вторая половина снисходительно улыбнулась).

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

Рекомендации: - Проводите исследования и тестируйте гипотезы. - Заведите "icebox" в котором будут храниться не срочные, но важные задачи, вы сможете их сделать в моменты просадки утилизации ресурсов разработки. - Не добавляйте в бэклог задачи "на всякий случай". Именно такие задачи будут мешать вам больше всего: они будут сбивать фокус  и формировать ложные ожидания у бизнеса и/или пользователей. 

3. Прозрачность и понятность самих задач Совместно с командой необходимо выработать критерии понятности и полноты описания задач. Обычно появляется такой документ как DoR — Definition of Ready, в котором фиксируется формат и требования к описанию задач.

Рекомендации: Я с командой договорился о таком формате, моё продуктовое описание фичи содержит следующие разделы: 1. User Story (одна или чаще несколько) 2. Критерии приёмки (для каждой из user story) 3. Основная логика (различные аспекты новой функциональности с учетом имеющихся компонентов, если у вас есть бизнес-аналитик в команде, то отдайте это описание ему) 4. Дополнительная логика (неочевидные пользовательские пути или дополнительные требования, например проверки при сохранении или дополнительные действия, опять же, работка для бизнес-аналитика) 5. Ключевые метрики (опционально, если я хочу обвес из технических метрик, то требования к ним я описываю тут) 6. Мокапы (наброски визуализации функциональности) 7. Макеты (это уже делает UX/UI-инженер или дизайнер)

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

А как вы работаете с бэклогом? Какие подходы и инструменты считаете самыми эффективными? Делитесь в комментариях! А если остались вопросы — задавайте!

автор: Игорь Михайлов