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