О приоритизации бэклога.

Один из самых популярных вопросов у менеджеров продукта/Product owner-ов про приоритизацию бэклога. Какой из инструментов самый лучший? Прежде чем ответить на этот вопрос, хочется обратиться к математике.

Есть такой класс математических задач, которые называются NP-полными. Практически это означает, что не существует алгоритма, который может решить эту задачу за полиномиальное, т.е. какое-то реальное и адекватное время.

Одна из таких задач — об укладке ранца. Суть ее такова: есть ранец, и известен некий максимальный вес, который вы можете поднять и унести в нем. И есть набор коробок, отличающихся весом и ценностью. Задача заключается в том, чтобы найти способ наиболее эффективно разместить коробки в рюкзаке так, чтобы можно было унести максимальную ценность.

И кажется, этот пример очень близок задаче приоритизации бэклога 😉

Конечно, можно возразить, что приоритизация более простая вещь, потому что есть такие параметры, как дедлайны или зависимости, существенно упрощающие процесс. Но проблема в том, что если по условиям задачи про ранец вы точно знаете ценность коробки и ее вес, то в случае приоритизации все предположения о «value» или сложности элемента бэклога достаточно приблизительны.

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

Остается забыть о поисках серебряной пули и, как обычно в любой непонятной ситуации, просто-напросто думать.

Ну или использовать "жадные" алгоритмы, но про них в следующем посте.