Как вы в проектах сортируете беклог?
Публичный постЧем больше погружаюсь в управление продуктами, тем больше есть ощущение, что информации о приоритезации тасок уделяется довольно мало времени.
Типа: вот у вас тут конвейер (от new до closed) и сидите думайте как скорость прохода увеличить. А вот как эти задачи в new попадают - чистая магия. Например как в скраме - нууу, PO сортирует беклог, это его ответственность и он вообще молодец. А если в беклоге 100500 задач?
Ладно, более насущный пример. Команда пережевывает 10-15 тасок в неделю. Они видят только макушку беклога (например, последние 5 задач, если освободился, то бери сверху первую и молодец). Входящий трафик: 10-20 таскок (от багов, до хотелок). Ну и “якобы” отсортированный беклог еще тасок 200.
Очевидно, что входящие кажутся более приоритетными (это нам всякие умные дядьки разъяснили не раз). Допустим мы с этим как-то боремся титаническими усилиями и не бросаем все что приходит сразу в high. Еще очевидно, что совсем старье мы периодически сливаем в /dev/null.
А что в итоге? Имеем около 200 +- как-то отсортированных задач и периодически заглядываем в конец и в середину, в надежде не забыть что-то нужное.
Понятно, что можно применить какой-то фреймворк в весами (типа RICE). Но тут свои проблемы (устаревание, куча времени на поддержку в актуальном состоянии и тд).
Как вы решаете эту проблему?
За собой заметил, что в личных задачах все чаще использую рандом. Например следующую книгу из списка выбираю по генератору случайных чисел - и так это чудесно.
Может в с беклогом так нужно? Убрать приоритет у задач и раз в неделю перетряхивать все и ура.
Можно очень быстро и усердно плыть не в ту сторону.
А если серьезно, то приоритет и цели конкретных итераций должны быть привязаны к целям более крупным и стоящим выше. Когда все конечные таски будут провязаны с крупными целями, то управлять приоритетами станет легко.
Крупные цели, при этом, можно подвязать к метрикам прокачивать которые кажется важным на уровне компании.
У нас это работает через OKR https://bit.ly/2XsOa59
Backlog.sort( (x,z) => x-z) // по приоритетности )))
Смотреть на цели и задачи проекта\продукта\ближайшего этапа, выбирать более релеватные исходя из них.
Все как всегда зависит от контекста и продукта. От того кто его пользователи, а кто клиенты.
Например, если твой продукт – настоящий, он имеет пользователей, данные и аналитику по ним; сбоку тусуется пяток стейкхолдеров; есть поток хотелок из поддержки; сверху цепочка из боссов разной степени истеричности, а CEO на самом-то деле расфуфыривает лавку ради следующего раунда инвестиций, то может неплохо зайти что-то типа https://www.productboard.com. Здорово сохраняет нервы и время на поддержание системы в актуальном состоянии и помогает с коммуникациями вокруг.
Если твой продукт компонентка в ентпрайзе с бесконечным количеством бабла, то визуализации целей для команды, чтобы видели биг пикчу и медленней выгорали, да пачка меток на тикетах в духе ShowStopper, ReportedByHIPPO, etc могут быть более чем.
Неплохая и довольно свежая статья на тему работы с Product Backlog с примерами организации потока - https://www.scrum.org/resources/blog/product-backlog-workflow
И да, согласен с Виктором, что святой рандом здесь ну ващее не вариант.