Меня зовут Анастасия Сабирова и я работаю аналитиком в MONS (входит в ГК «КОРУС Консалтинг»). В прошлой статье мы поговорили о сборе требований и даже составили список рекомендаций, которые должны сделать этот процесс наиболее эффективным. Сегодня же мы попробуем разобраться с приоритизацией требований и разберём алгоритм, который может помочь начинающим аналитикам в расстановке приоритетов.
Давайте представим (а может вы в действительности сейчас находитесь в подобной ситуации), что вы собрали требования в рамках вашего проекта. Этих требований, конечно, получилось ни одно, и не два, а, например, пятьдесят. И понятно, что взять их в работу все одновременно попросту невозможно. А тут ещё и РП сообщил вам о том, что количество разработчиков на проекте ограничено и планировать их загрузку нужно с учётом того, что заказчик хочет лично проверять промежуточные результаты еженедельно.
То есть от нас требуется расставить приоритеты для работы с собранными требованиями, выделив из них те, с которых стоит начать работу и расставив все остальные по убыванию «значимости» и «срочности взятия в работу». По сути, так простыми словами и объясняется суть приоритизации требований.
Приоритизация – это ранжирование требований, чтобы определить их относительную важность для стейкхолдеров через выставление приоритета – оценки, отражающей ценность требования или очередности реализации.
(определение по BABOK)
Есть масса различных методов приоритизации, из которых, пожалуй, самыми известными являются MoSCoW-приоритизация и метод Карла Вигерса. Но, когда я только начинала работать с требованиями, мне такие подходы казались сложными и непонятными. Поэтому хотелось придумать для себя простой алгоритм приоритизации, “проходя” по которому можно было бы маркировать каждое требование тем или иным приоритетом.
И снова на помощь мне пришли коллеги! Во время менторинга с Александрой Бобровой, бизнес-аналитиком «ДАРа» (входит в ГК «КОРУС Консалтинг»), нам удалось разработать такой алгоритм, и я рада поделиться с вами полученным результатом!
Для работы с алгоритмом мы подготовили небольшую инструкцию, следуя которой, анализ требования для последующей приоритизации не должен составить для вас труда.
Давайте разберём один пример.
Допустим мы собрали требования по развитию личного кабинета работника АЗС. Возьмем следующее требование:
В форме фильтрации журнала товаров необходимо сделать так, чтобы фильтрация производилась не только после нажатия кнопки «Фильтровать», но и после нажатия клавиши «Enter».
Также нам известно, что Заказчик не обозначал особую важность данного требования, сама фильтрация уже реализована (по кнопке «Фильтровать»), и данное требование не связано с другими требованиями из тех, что мы собрали.
Следуя инструкции, начнём движение по схеме сверху вниз. Удостоверимся, что требование отвечает всем критериям качества и перейдём к приоритизации.
Проверяем правдивость первого утверждения относительно нашего требования:
Пока требование не будет реализовано, все или часть других требований невозможно реализовать.
Нет, это не так. Нам известно, что фильтрация уже реализована и данное требование не влияет на остальные, имеющиеся у нас в работе требования.
Переходим ниже по схеме алгоритма и проверяем правдивость следующего утверждения:
Требование было обозначено Заказчиком как приоритетное и дальнейшая работа по проекту не будет продолжена до момента реализации данного требования.
Нет, это не так. Нам известно, что Заказчик не обозначал особую важность данного требования.
Однако, обратим внимание на то, что у данного элемента есть ещё одно “ответвление” развития событий. Если Заказчик, действительно, обозначил требование, как приоритетное, то (мы «сдвигаемся» вправо на схеме) нам стоит попытаться донести до него значимость других более критичных требований. Если нам это удаётся, то мы идём по алгоритму дальше вниз, а если нет, то требование маркируем как Блокирующее требование.
Нашему требованию этот тезис не соответствует, по условиям Заказчик не обозначал особую важность данного требования.
Переходим ниже по схеме алгоритма и проверяем правдивость следующего утверждения:
Пока требование не будет реализовано часть основных функциональностей системы будут работать нестабильно/некорректно.
Тут нам потребуется обратиться к инструкции и уточнить, что такое «основные функциональности системы», чтобы понять, влияет ли на них наше требование.
Основная функциональность системы – это ключевая возможность, без которой система не может выполнять своё основное предназначение (например, выполнение расчетов в онлайн-калькуляторе).
Мы понимаем, что фильтрация в журнале товаров не влияет на основные возможности личного кабинета работника АЗС. К тому же нам известно, что сама по себе фильтрация и сейчас работает. Учитывая определение, получается, что данный тезис также не относится к нашему требованию.
Идём дальше и проверяем правдивость следующего утверждения:
Требование включено в ближайший показ Заказчику или является частью согласованного перечня требований, обязательных к реализации до ближайшей контрольной точки.
Уделим немного внимания этому пункту. Изначально его не было в алгоритме, но в процессе тестирования приоритизации, стало понятно, что иногда значительное влияние на график реализации требований оказывает сам заказчик. Требование может не относиться к основной функциональности и даже не влиять на неё, но заказчик хочет видеть его как можно раньше. Поэтому мы постарались учесть и этот момент в нашем алгоритме.
Итак, нашему требованию этот тезис не соответствует.
Идём дальше и проверяем правдивость следующего утверждения:
Требование касается основных функциональностей системы и его реализация позволит «закрыть» потребность пользователя (требование является частью критического пути).
Снова сверимся с определением, о котором уже говорили выше. По нашему требованию, снова ответ «нет».
Идём дальше:
Требование относится к дополнительной функциональности системы.
Обратимся к определению в инструкции:
Дополнительная функциональность системы – это вспомогательная возможность, расширяющая базовый функционал, но не являющаяся критичной для работы системы (например, сохранение истории расчетов или экспорт результатов в онлайн-калькуляторе).
Если вы сомневаетесь, подходит ли такое определение нашему требованию, давайте ознакомимся сразу с ещё одним определением, о котором речь пойдёт в последнем пункте алгоритма:
Удобство использования системы - это количество времени и/или действий, необходимых для выполнения пользовательского сценария (например, сохранить историю расчётов нажатием одной кнопки удобнее, чем делать это через вызов меню правой кнопкой мыши).
Теперь уже сомнений не остаётся, согласны? Запуск фильтрации нажатием кнопки «Enter» абсолютно точно относится к удобству использования системы и не является дополнительной функцией. Поэтому на предпоследнем этапе алгоритма мы отвечаем «нет», смещаемся ниже и уже тут отвечаем «да», что приоритизирует наше требование как Требование низкого приоритета.
Конечно, описанный в данной статье алгоритм не является панацеей, но, я надеюсь, что он поможет начинающим аналитикам «нащупать» основные принципы приоритизации и облегчит работу с требованиями.
Попробуйте приоритизировать какое-либо требование с использованием представленного алгоритма и напишите о своих впечатлениях в комментариях. Мне, действительно, важно получить обратную связь по работоспособности данного метода и, возможно, вместе нам удастся доработать его до более совершенного вида!
