Как вы в проектах сортируете беклог?  Публичный пост

Чем больше погружаюсь в управление продуктами, тем больше есть ощущение, что информации о приоритезации тасок уделяется довольно мало времени.
Типа: вот у вас тут конвейер (от new до closed) и сидите думайте как скорость прохода увеличить. А вот как эти задачи в new попадают - чистая магия. Например как в скраме - нууу, PO сортирует беклог, это его ответственность и он вообще молодец. А если в беклоге 100500 задач?

Ладно, более насущный пример. Команда пережевывает 10-15 тасок в неделю. Они видят только макушку беклога (например, последние 5 задач, если освободился, то бери сверху первую и молодец). Входящий трафик: 10-20 таскок (от багов, до хотелок). Ну и “якобы” отсортированный беклог еще тасок 200.

Очевидно, что входящие кажутся более приоритетными (это нам всякие умные дядьки разъяснили не раз). Допустим мы с этим как-то боремся титаническими усилиями и не бросаем все что приходит сразу в high. Еще очевидно, что совсем старье мы периодически сливаем в /dev/null.

А что в итоге? Имеем около 200 +- как-то отсортированных задач и периодически заглядываем в конец и в середину, в надежде не забыть что-то нужное.

Понятно, что можно применить какой-то фреймворк в весами (типа RICE). Но тут свои проблемы (устаревание, куча времени на поддержку в актуальном состоянии и тд).

Как вы решаете эту проблему?

За собой заметил, что в личных задачах все чаще использую рандом. Например следующую книгу из списка выбираю по генератору случайных чисел - и так это чудесно.
Может в с беклогом так нужно? Убрать приоритет у задач и раз в неделю перетряхивать все и ура.

10 комментариев 👇
Виктор Диктор, Руковожу разработкой 25 мая 2020

Может в с беклогом так нужно? Убрать приоритет у задач и раз в неделю перетряхивать все и ура.

Можно очень быстро и усердно плыть не в ту сторону.

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

Крупные цели, при этом, можно подвязать к метрикам прокачивать которые кажется важным на уровне компании.

У нас это работает через OKR https://bit.ly/2XsOa59

  Развернуть 1 комментарий

В теории легко, а на практике есть:

  • критикл задачи
  • бесконечные баги
  • клиентские вопросы
  • техдолг
  • ну и да, фичи, привязанные к большим целям

как вы все это впихиваете в свои итерации?

  Развернуть 1 комментарий

@DenisKabalkin, это никак не противоречит механизмам целеполагания, но, возможно, стоит провести аудит целей и проблем в их достижении. Т.е. глобально нужно понять что сейчас важнее: сделать sexy ui или захватить долю рынка.

  • Бесконечные баги - звучит как измеримая метрика, которую можно прокачать, через налаживание тестирования, внедрения какого-нибудь Zero Bug Policy и практик agile-tesing, например
  • Клиентские вопросы - ну ведь этот тоже про продуктовую разработку и поддержку. Подвязывайте эти вопросы к целям по развитию продукта и берите в первую очередь те, которые нужны большему количеству клиентов
  • Техдолг должен снимать блоки или быть пререквизитом для достижения каких-нибудь целей, желательно продуктовых, в противном случае не понятно зачем с этим долгом бороться
  Развернуть 1 комментарий

Backlog.sort( (x,z) => x-z) // по приоритетности )))

  Развернуть 1 комментарий

x и z это длинна заголовков тасков, я полагаю? =)

  Развернуть 1 комментарий

@DenisKabalkin, скорее "длина членов" авторов )

  Развернуть 1 комментарий
Роман Романов, Предприниматель 25 мая 2020

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

  Развернуть 1 комментарий

Ну вот да, в теории "смотреть и выбирать", а на практике каждые две недели перебирать 200 задач и выбирать из них 10? Похоже на оверкил

  Развернуть 1 комментарий
Nik ILyushkin, Product Manager 26 мая 2020

Все как всегда зависит от контекста и продукта. От того кто его пользователи, а кто клиенты.

Например, если твой продукт – настоящий, он имеет пользователей, данные и аналитику по ним; сбоку тусуется пяток стейкхолдеров; есть поток хотелок из поддержки; сверху цепочка из боссов разной степени истеричности, а CEO на самом-то деле расфуфыривает лавку ради следующего раунда инвестиций, то может неплохо зайти что-то типа https://www.productboard.com. Здорово сохраняет нервы и время на поддержание системы в актуальном состоянии и помогает с коммуникациями вокруг.

Если твой продукт компонентка в ентпрайзе с бесконечным количеством бабла, то визуализации целей для команды, чтобы видели биг пикчу и медленней выгорали, да пачка меток на тикетах в духе ShowStopper, ReportedByHIPPO, etc могут быть более чем.

Неплохая и довольно свежая статья на тему работы с Product Backlog с примерами организации потока - https://www.scrum.org/resources/blog/product-backlog-workflow

И да, согласен с Виктором, что святой рандом здесь ну ващее не вариант.

  Развернуть 1 комментарий

Спасибо за ссылочки, покурю на досуге.

Я скорее не про святой рандом, а про некий управляемый хаос. Например у меня есть 5 бакетов с задачами (баги, техдолг и тд), логично предполжить, что брать оттуда рандомно может сработать. Например, берем основные задачи (то, куда целимся) - это 80% и 20% добираем по остаточному принципу (по одной из каждого ведра, например). Так вся эта куча из хвоста беклога потихоньку всплывает. Плюс это позволит от неактульного избавляться по мере их всплытия. Как-то так =)

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб