Естественная реакция пользователей на просьбу определить приоритеты обычно такая: «Мне нужны все эти функции. Уж как-нибудь реализуйте их». Трудно убедить клиентов обсуждать приоритеты, если они знают, что функций с низким приоритетом не получат никогда. Один разработчик как-то сказал мне, что в их компании не принято назначать требованию низкий приоритет. Категории приоритетов требований назывались у них «высокие», «очень высокие» и «невероятно высокие». Другой разработчик заявлял, что назначение приоритетов совсем не нужно: если он записал что-либо в спецификацию требований, то собирается это реализовать. Но это не отвечает на вопрос, когда будет реализована каждая функция. Некоторые разработчики избегают определения приоритетов, потому что оно не соответствует позиции «мы можем все», которую они декларируют.
| Ловушка Избегайте определения приоритетов «по децибелам», когда требование, высказанное громче всего, получает наибольший приоритет, и «по угрозе», когда те, кто имеют больший вес в компании, всегда получают требуемое. |
В действительности некоторые возможности системы более ценны, чем остальные. Это становится очевидным, когда на поздних стадиях требуется «быстро урезать» проект, то есть отбросить несущественные характеристики, чтобы критически важные возможности удалось реализовать в срок. Определив приоритеты на ранних этапах разработки проекта и переоценивая их в соответствии с изменяющимися предпочтениями клиентов, условиями рынка и реалиями бизнеса, команда сможет мудро тратить свое время на создание наиболее ценных возможностей. Реализовав большую часть функции, а затем решив, что она не нужна, вы впустую потратите ресурсы и испытаете горькое разочарование.
Предоставленные самим себе, клиенты, скорее всего назначат 85% требований высокий приоритет, 10% — средний и 5% — низкий. Это не дает менеджеру проекта большой свободы для маневра. Если почти все требования действительно важны, вы рискуете тем, что не весь ваш проект будет успешен, поэтому придется составить планы соответствующим образом. Отшлифуйте требования до блеска, чтобы отбросить не имеющие большой ценности и упростить неоправданно сложные требования (McConnell, 1996). Чтобы представители клиентов с большим мужеством назначали требованиям низкие приоритеты, аналитику стоит задать вопросы, подобные перечисленным ниже.
· Есть ли другой способ удовлетворить это требование клиентов?
· Что случится, если это требование убрать или отложить?
· Что произойдет с бизнес-целями, если это требование не будет реализовано немедленно?
· Почему пользователи будут недовольны, если реализацию этого требования отложить до следующего выпуска?
Однажды команда управления менеджментом в крупном коммерческом проекте выразила нетерпение, когда аналитик настаивал на определении приоритетов требований. Менеджеры отметили, что зачастую они могут обойтись без какой-либо функции, но тогда в компенсацию придется усиливать другую функцию. Если бы они отсрочили слишком много функций, то продукт не принес бы запланированные доходов. Оценивая приоритеты, учитывайте связи и взаимосвязи между различными требованиями, а также их соответствие бизнес-целям проекта.
Шкала приоритетов
Обычный метод расстановки приоритетов подразумевает три группы категорий требований. Неважно, как вы назовете их, все сводится к. высокому, среднему и низкому приоритетам. Такие шкалы приоритетов субъективны и неточны. Лица, заинтересованные в проекте, должны согласовать, что означает каждый уровень в используемой шкале.
Один из способов оценки приоритетов предлагает учитывать два измерения: важность и срочность (Covey, 1989). Каждое требование считается важным либо не важным и срочным либо не срочным. Как показано в табл. 14-1, получаются четыре комбинации для определения шкалы приоритетов:
· требования с высоким приоритетом (high priority) — и важные (пользователям нужны функции), и срочные (они необходимы уже в следующем выпуске). Некоторые требования приходится включать в эту категорию согласно контрактным или юридическим обязательствам либо из-за непреодолимых бизнес-причин;
· требования со средним приоритетом (medium priority) — важные (пользователям нужны функции), но не срочные (они могут ждать следующего выпуска);
· требования с низким приоритетом (low priority) — не важные (пользователи при необходимости могут обойтись без этой функций) и не срочные (пользователи могут ждать, причем вечно);
· требования в четвертой клетке кажутся срочными, но в действительности — они не важны. Не тратьте время на работу над ними. Они не сделают продукт более ценным.
Таблица 14-1. Определение приоритетов требований по важности и срочности
| Важные | Не важные | |
| Срочные | Высокий приоритет | Не занимайтесь ими! |
| Не срочные | Средний приоритет | Низкий приоритет |
Включайте приоритеты каждого требования в описания вариантов использования, спецификацию требований или базу данных требований. Установите правила, чтобы пользователь знал, присваивается ли приоритет, назначенный высокоуровневому требованию, всем дочерним требованиям или же каждое функциональное требование должно иметь свой собственный атрибут приоритетности.
Даже проект средних масштабов может иметь сотни функциональных требований — слишком много, чтобы классифицировать их аналитически и последовательно. Чтобы не потерять контроль над ситуацией, выберите для определения приоритетов определенный уровень абстракции — возможности, варианты использования или функциональные требования. В рамках одного варианта использования некоторые альтернативные направления могут иметь больший приоритет, чем остальные. Вы имеете возможность сначала определить приоритеты на уровне функций, а затем назначить приоритеты функциональным требованиям отдельно для каждой функции. Это поможет вам отделить основную функциональность от усовершенствований, которые предполагается реализовать позже. Документируйте даже требования с низким приоритетом. Их приоритет может впоследствии измениться, и если разработчики знают о них сейчас, им проще планировать будущую модификацию.