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

Хрупкое равновесие: жизнь между фичами, багами и техдолгом

Из чего состоит бэклог программного продукта? Чаще всего он состоит из задач трех основных типов: 1. Задачи развития/улучшения Это те самые фичи, которые делают наш продукт лучше: добавляют новые возможности, улучшают пользовательский опыт и приносят деньги нашей компании. 2. Дефекты (баги) Ошибки, которые стоит исправить. 3. Задачи технического долга Это работа, которую чаще всего откладывают в пользу быстрых решений. Те самые элегантные конструкции из костылей, порожденные сумрачным гением компромиссов сроков и стоимости ради быстрой ценности.

Задача продакта — тонко балансировать между всеми тремя типами. Игнорирование баланса приведёт к проблемам: - Бесконечное развитие приведёт к снижению стабильности. - Вечный багофикс приведёт к стагнации продукта. - Игнорирование техдолга приведёт к апокалипсису.

Как достичь баланса? Я в своей практике разделяю всю работу команды в рамках спринта на два трека: медленный и быстрый.

Медленный трек содержит в себе задачи развития, запланированные исправления багов и задачи устранения техдолга.

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

Я использую следующие пропорции резервирования ресурсов при планировании: 80% на медленный трек и 20% на быстрый. В моменты запуска больших блоков функциональности, смещаю соотношение на 60/40.

Медленный трек, в свою очередь, разбиваю в пропорциях: 60% — развитие, 20% — дефекты, 20% — техдолг.

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

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

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

А пока поделитесь с нами в комментариях о том, как вы находите баланс в своём бэклоге?

автор: Игорь Михайлов, эксклюзивно для "Немного продакт" пишу про управление разработкой программных продуктов.

#немногопродакт  #бэклог #backlog #задачи #productmanagement
Воскресный лонгрид, сегодня продолжим про бэклог и затронем тему баланса в нём | Сетка — новая социальная сеть от hh.ru
repost

797

input message

напишите коммент

· 22.12

Про резервирование интересно, спасибо! Как-то ещё сталкивался с нежеланием разработчиков дорабатывать архитектуру, из-за особенностей которой много вещей делалось неудобно. Мол, если у клиента есть workaround, то зачем тратить усилия и заниматься сложным исследованием. Контр-аргументы про клиенто-ориентированность не убедили, к сожалению :)

ответить

22.12

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

Часто на такие задачи нужно много времени и появляются другие проблемы: как уложить это в бэклог? Но об этом, в следующее воскресенье ;)

ответить

еще контент автора

еще контент автора

войдите, чтобы увидеть

и подписаться на интересных профи

в приложении больше возможностей

пока в веб-версии есть не всё — мы вовсю работаем над ней

сетка — cоциальная сеть для нетворкинга от hh.ru

пересекайтесь с теми, кто повлияет на ваш профессиональный путь