Продолжая разговор про требования, начатый в предыдущем посте о декомпозиции требований, хочется теперь поговорить про их приоритезацию, поскольку это краегольный камень абсолютно для каждого проекта.
Представьте проект, который длится уже, например, несколько релизов. В нем скопился целый ряд новых, еще не реализованных требований заказчиков (причем, требований крайне важных и срочных!), а так же целый набор доработок из разряда «долга» — ошибки от пользователей, недоделанные в прошлых релизах требования, технические недоработки или «костыли» и т.п.
Для второй категории мы сегодня мы даже придумали новый термин «Темная сторона релиза» — это не бизнесовые задачи, но делать все равно надо, причем каждый заказчик мечтает, чтобы это происходило в любое другое, но не рабочее время :).
Итак, два больших набора требований, плановые и долги, все очень важные и срочные, и нужно из них сформировать скоуп следующего релиза. Проблема в том, что релиз длиной всего 2-3 месяца, все и сразу в него не влезет. С другой стороны, эти несколько месяцев — достаточно большой срок для бизнеса, чтобы задумываться о приоритезации.
Вопрос только в том, что непонятно, на основе чего определять приоритеты, кроме внутреннего ощущения заказчиков, которое, к сожалению, при различных аргументах со стороны окружающих коллег, может меняться несколько раз на дню.
Одним из основных способов приоритезации требований, конечно, является их атрибутирование — это очевидно для большинства заказчиков и проектных команд. Только какие именно атрибуты нам использовать в данном случае? И как?
Приведу пример большого проекта одного из крупных Российских банков — целью следующего релиза проекта была выбрана миграция части клиентов из старой версии системы в новую, а так же привлечение новых клиентов с рынка за счет удобной, востребованной функциональности нового продукта.
Рецепт примерно такой:
- Собираем очень ограниченное число заинтересованных лиц (3-5 человек: заказчики, менеджер проекта/продукта, лид аналитиков)
- Выявляем мозговым штурмом перечень атрибутов, которые релевантны цели нашего релиза
- Составляем матрицу требований, где в первом столбце — список требований, а в остальных — атрибуты, влияющие на приоритезацию
- Заполняем матрицу значениями атрибутов для каждого требования
- Анализируем получившийся результат и вырабатываем алгоритм сквозной приоритезации записанных требований на основе указанных значений атрибутов.
Например, проставляя некий «вес» каждому атрибуту, тем самым получая суммарную оценку по каждому требованию. Или используя просто последовательную приоритезацию, например, сначала требования, влияющие на максимальное количество пользователей, потом принесущие максимальный доход, потом требующие минимальных затрат и тп.
В нашем случае, мы выбрали следующие атрибуты требований:
| Требование | Сколько клиентов затрагивает? | Сколько денег (времени) потратим? | Сколько денег это принесет банку? | Насколько клиент заинтересован в требовании? | Кому в банке это нужно? | Какое подразделение будет осуществлять перевод? |
| Мульти-валютный перевод | ||||||
| Платежи между своими счетами | ||||||
| Работа с мобильных устройств | ||||||
| …. |
И далее пошли путем последовательной приоритезации требований в нужном нам порядке атрибутов.
Таким образом, получилась адекватная, максимально объективная последовательность приоритетов требований — обоснованная цифрами, минимально учитывающая тот самый фактор нестабильного «внутреннего ощущения» заказчиков.
Итак, приоритеты ясны, вперед за работу!
А вы как приоритезируете требования в своих проектах?