Реакция пользователей на просьбу определить приоритеты обычно такая: «Мне нужны все эти функции. Уж как-нибудь реализуйте их». И как в такой ситуации быть? 🤔

👉 Один из разработчиков рассказал, что в их компании не принято назначать низкий приоритет требованиям. Вместо этого существуют категории «высокие», «очень высокие» и «исключительно высокие».

Чтобы с большим мужеством назначать требованиям низкие приоритеты, стоит задаться следующими вопросами:

❓ Есть ли другой способ удовлетворить это требование клиентов? ❓ Что случится, если это требование убрать или отложить? ❓ Что произойдёт с бизнес-целями проекта, если это требование не будет реализовано в ближайшие месяцы? ❓ Стоит ли из-за этой функции откладывать выпуск всех остальных функций с тем же приоритетом?

Определение приоритетов, в принципе, и основано на том, что некоторые возможности системы более ценны, чем остальные. Это становится очевидным, когда на поздних стадиях требуется «быстро урезать» проект, то есть отказаться от несущественных характеристик, чтобы критически важные возможности были реализованы в срок. В такой ситуации люди вынуждены принимать решения по приоритетам в состоянии паники 😬

😌 Чтобы избежать подобных ситуаций, необходимо определить приоритеты на ранних этапах разработки проекта и пересматривать их в соответствии с изменяющимися предпочтениями клиентов, условиями рынка и реалиями бизнеса. Это позволит команде мудро тратить своё время на создание наиболее ценных возможностей 👌