Хочешь получать новые знания про тимлидство? Подписывайся в Telegram на Teamlead Good Reads!

# Генерация элементов бэклога

# Описание

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

  • Почему это улучшение ценно?
  • Удобно ли это улучшение для пользователя?

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

  • Аналитика продукта
  • Интервью с пользователями
  • Результаты UX-исследований
  • Анализ конкурентов
  • Анализ рынка и трендов
  • Стратегия бизнеса и продукта

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

# Почему ветка важна?

Для компании:

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

Для менеджера:

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

Для команды:

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

# Что будет, если её не делать?

  • В разработку будут поступать задачи, не прошедшие проверку ценности или удобства.
    • Фичи не принесут ожидаемой пользы для продукта и бизнеса.
  • Команда будет хаотично прыгать между задачами из разных областей продукта.
    • Не будет системного продвижения к поставленным продуктовым целям.
  • Любой стейкхолдер сможет свободно проталкивать свои задачи в разработку, исходя из принципа "кто громче кричит".

# На кого может быть делегирована?

  • Product Owner
  • Тимлид ниже уровнем
  • Разработчик, ответственный за конкретную фичу

# Примеры поведения

# Примеры плохого поведения

  • Бэклога нет.
  • В бэклоге появляются задачи, ценность которых не подтверждена ничем, кроме экспертного мнения тимлида или заказчика.
  • Удобство новых фич проверяется только на конечных пользователях после релиза.
  • PBI описаны хаотично или вообще не имеют описания.
  • Задачи в бэклоге не связаны совсем, либо связаны лишь косвенно с целями команды.

# Примеры хорошего поведения

  • У команды есть продуктовый бэклог, который доступен на просмотр любому желающему.
  • Каждый PBI описан по стандартному шаблону. Можно изучить изначальную гипотезу, её валидацию, посмотреть definition of done.
  • Все члены команды знают, что за фича разрабатывается, почему она ценна, какая польза от неё ожидается на выходе.
  • Бэклог прозрачен для стейкхолдеров.

# Способы прокачки

# Практика

Пройди отличный онлайн-курс управления продуктом на основе данных Go Practice. Он реализован в виде симулятора – всю получаемую теорию ты сразу же применяешь в специальной песочнице на практике.

# Консультации

# Теория

# Статьи

# Книги