Приоритезация требований

Записаться

Здравствуйте, коллеги. Мы с вами продолжаем изучение области знаний по бизнес-анализу "Управление жизненным циклом требований" в соответствии с БАБОК версии 3.0. И сегодня мы с вами поговорим о такой важной задаче по бизнес-анализу, которая называется "Приоритизация требований".

Мы уже поговорили про трассировку требований, про то, как важно устанавливать связь между различными типами требований, между требованиями одного типа, между требованиями и тест-кейсами, между требованиями и компонентами решений и так далее. Мы с вами поговорили о том, как важно поддерживать требования, поскольку это касается их актуальности, целостности, подготовки для повторного использования, и вот сегодня поговорим о приоритизации требований.

Приоритизация – это то, без чего не обходится практически ни одна активность по бизнес-анализу, поскольку время у нас конечно чаще всего, а требований бывает много, и все заинтересованные стороны хотят, чтобы их требования реализовывались в первую очередь по разным причинам, и бизнес-аналитику все время необходимо каким-то образом управлять очередностью реализации этих требований. Мы сейчас поговорим о том, какие есть подходы к приоритизации требований.

Давайте посмотрим, что нам говорит назначение этой задачи. Назначением задачи "Приоритизация требований" является ранжирование, то есть некоторое упорядочивание требований в порядке относительной важности. Здесь важный момент – что важно или что ценно для заинтересованной стороны, какой критерий для приоритизации та или иная заинтересованная сторона выдвигает. Про это и будет основной разговор в этом уроке.

Давайте посмотрим на окружение этой задачи в соответствии со сводом знаний. Здесь много чего есть, и на вход задачи 5.3, так же, как на вход задачи 5.1 и так же, как на вход задачи 5.2 поступают требования и дизайны безо всяких модификаторов, то есть в любом состоянии. И мы уже можем их приоритизировать.

Но, помимо требований и дизайнов, необходимо много чего знать для приоритизации. Бизнес-ограничения, стратегия изменений, знание бизнес-домена, подход к управлению, архитектура требований, границы решения, инструменты управления требованиями и репозиторий. Все это необходимо в той или иной степени для того, чтобы решить задачу по приоритизации требований. Результатом выполнения задачи являются дизайны решения и требования приоритизированные. Таково окружение задачи 5.3 "Приоритизация требований".

Давайте посмотрим на то, из каких элементов состоит эта приоритизация. Самый важный здесь пункт – это первый, базис для приоритизации. Давайте подумаем о том, какой может быть базис для приоритизации. Допустим, у нас сто, или двести, или тысячи требований, не принципиально. На основании чего я буду приоритизировать, почему я считаю, что, например, требование 56 необходимо делать раньше, чем требование 72? Может быть из-за какой-то срочности, из-за важности? А что значит важность, для кого? Важность, например, потому что на нас наложат штраф, если мы это не сделаем. О! Это уже из-за необходимости удовлетворить требования какого-то закона, нормативной документации. Вот это уже подход к приоритизации на основании какого-то нормативного подхода.

Или, например, мы приоритизируем с точки зрения относительной ценности для бизнеса, мы просим бизнес оценить требования по какой-то шкале и, исходя из совокупности оценок каждого требования, допустим, всеми заинтересованными сторонами, у нас составляется какая-то интегрированная оценка, и мы требования, набравшие наибольшее количество баллов с точки зрения совокупной ценности для всех заинтересованных сторон, пускаем вперед.

Таким образом, базис для приоритизации является самой важной вещью, которой бизнес-аналитик должен озаботиться, потому что если у него не будет четкого подхода, то есть: "Почему вы делаете это требование?" – "Потому что у меня есть такой подход, этот подход является одобренным в самом начале". Когда мы с вами вырабатываем наш подход к бизнес-анализу, мы одним из пунктов должны понять наш подход к приоритизации и к оценке трудоемкости той или иной задачи.

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

Следующий пункт, который здесь есть – это вызовы приоритизации. Какие трудности могут встретиться при приоритизации? Здесь может встретиться очень много трудностей, начиная от того, что заказчики не хотят участвовать в приоритизации, заинтересованные стороны, они могут сказать, что для нас все важно, делайте, пожалуйста, все. Иногда бывает такое аполитическое решение, когда заказчик отказывается участвовать в приоритизации. Возможно, у нас возникают какие-то конфликты, если мы уже вышли на какую-то приоритизацию, возникают трудности с определением приоритетов, с согласованием шкалы этих приоритетов, с оценками конкретных уровней для каждого требования. Таким образом, это все вызовы приоритизации, которые могут аналитику испортить жизнь в этой задаче 5.3 "Приоритизация требований".

Наконец, такой элемент, как непрерывная приоритизация. Вопрос: когда проводить приоритизацию? Что, после каждого нового требования мы должны это сделать? Раз в неделю мы должны все перетряхнуть? Необходимо выработать какой-то подход к непрерывной приоритизации.

Следующий вопрос, я уже частично начал про это разговаривать, это варианты базиса для приоритизации. Давайте коротко пройдемся, при необходимости я вас отсылаю к своду знаний по бизнес-анализу, там чуть более подробно, но тем не менее.

Выгода. Заказчик формулирует какую-то оценку выгоды для каждого требования, и, исходя из оценки этой выгоды, она может быть финансовая, может быть нефинансовая, в каких-то условных показателях, но тем не менее, мы ранжируем, упорядочиваем порядок реализации наших требований с точки зрения выгоды. Один подход.

Затраты. Например, мы четко можем понимать, что реализация вот этого требования стоит столько-то, не важно, это могут быть не деньги, это могут быть трудозатраты или совокупно материальные затраты, человеческие ресурсы и финансовые ресурсы, все вместе в определенной пропорции каким-то образом составляет совокупные затраты по данному требованию. И заказчик при принятии решения о том, что делать сначала, что делать потом, оперирует в основном затратами, а не выгодой. Например, давайте сделаем сначала что подешевле. Или у нас есть вот столько денег, давайте возьмем самую дорогую, самую интересную фичу и сделаем ее в первую очередь.

Штрафы. Возможно, вышел какой-то закон, и, если мы не удовлетворим требованиям этого закона или подзаконного акта к 1 января, мы попадаем под действие каких-то штрафов. Это тоже можно отнести к затратам или к выгодам с отрицательной оценкой, но мне кажется, это лучше вынести в отдельный вариант базиса, что мы в первую очередь должны реализовать требования, если мы их не реализуем, мы будем обложены штрафами.

Риск. Например, мы взяли какую-то технологию, с которой мы раньше не работали. Эти требования являются высоко рискованными при реализации. Здесь может быть два подхода. Мы говорим: давайте мы вот эти требования пустим вперед, поскольку они самые рискованные, и даже если мы здесь получим какой-то негативный эффект, у нас будет время переделать. Это один подход к риску. Второй подход: нет, давайте мы сначала сделаем менее рискованные, а все рискованные оставляем на потом, понижаем им приоритет. Это другой подход, но это тоже приоритизация, исходя из разного подхода к риску, в основе приоритизации лежит оценка риска.

Возможен базис для приоритизации на каких-то зависимостях, если сделал "А", говори уже и "Б" и так далее. То есть, когда у нас есть какие-то зависимости между требованиями и приоритизация зависит от этих зависимостей.

Для многих заказчиков принципиальным является время. У нас есть месяц, что мы можем максимально сделать за этот месяц, им это важно. Или, например, неделя. За эту неделю нам надо сделать максимум функциональности, давайте берем те задачи, которые минимальные по времени, нам главное сделать больше за этот период времени. Таким образом, возможно, временной аспект в некоторых случаях играет роль. Допустим, когда мы хотим показать какой-то квин, быструю победу. У нас очень мало времени и нам нужно реализовать какую-то эффектную функциональность, и для нас критично именно время при выборе базиса для приоритизации.

Стабильность. Тоже иногда такое бывает, когда заказчик говорит, что давайте мы весь этот экстремизм отставим в сторону, для нас важна стабильность, надежность, для нас это первейший приоритет. Любые все действия не должны нарушать статус кво, для нас необходима стабильность, поэтому в первую очередь надо реализовывать вещи, в которых мы полностью уверены. В этих требованиях мы не очень уверены, мы их считаем недостаточно стабильными, нас интересует стабильность, поэтому вот эти требования мы пускаем вперед.

Возможно соответствие чему-то, каким-то нормам, апплайнсам внутренним и так далее.

Наверное, можно дальше продолжить этот список, но, в принципе, он уже является достаточно неплохим подходом, неплохим началом к тому, чтобы вы задумались на тему, а как вы сейчас справляетесь с приоритизацией своих требований, какой базис для приоритизации есть у вас. Он действительно обоснован, этот базис, или все-таки более рационально выбрать другой базис для приоритизации. Поэтому, пожалуйста, посмотрите этот список и подумайте над выбором базиса. Возможно, вы его как-то поменяете и это сподвигнет вас на то, чтобы поменять свой базис для приоритизации.

Давайте рассмотрим заинтересованные стороны, которые могут быть задействованы в приоритизации требований. Их здесь не так много, это покупатель, конечный пользователь, эксперт по внедрению, руководитель проекта, регулятор и спонсор. Все они так или иначе участвуют в приоритизации.

Спонсор подтверждает ценность приоритизации, что именно такая приоритизация с точки зрения спонсора или лица, которое олицетворяет собой для нас заказчика в целом, спонсора, инициатора этих работ по бизнес-анализу, он подтверждает ценность именно этого подхода к приоритизации.

Регулятор при приоритизации как всегда нам указывает на стандарты, чтобы мы ничего не нарушили, внутренние какие-то или внешние.

Приоритизация может влиять на план работ руководителя проекта, потому что в зависимости от выбора базиса могут поменяться длительность работ, последовательность взаимосвязей и так далее.

Эксперт по внедрению приоритизацию использует для тестирования анализа.

Конечный пользователь – у него тоже есть своя точка зрения на приоритизацию, он тоже может нам как-то в этом деле помочь. Это все заинтересованные стороны с точки зрения БАБОК.

Рекомендуемые методы. На чем я здесь хотел бы остановиться. Есть отдельный метод, который называется Приоритизация, который предназначен для фасилитации, для управления, для обеспечения процесса приоритизации. Есть специальный отдельный метод в БАБОК, который так и называется "Приоритизация". Во время приоритизации возникает куча всяких вопросов, каких-то проблем неразрешенных и так далее. Это метод отслеживания элементов, чтобы к окончанию цикла приоритизации мы с вами как-то управляли всеми этими вопросами, инцидентами, элементами.

Для приоритизации часто необходима какая-то финансовая оценка, именно поэтому здесь есть метод "Финансовый анализ", оценка финансовой ценности для определения базиса для приоритизации. Такой интересный метод – бизнес-кейс, когда мы составляем, возможно, какое-то описание кейса, если мы реализуем вот эти требования, то мы сможем достичь вот этой цели наиболее оптимальным образом, то есть составляем некий кейс, почему именно вот так необходимо поступить.

Я уже говорил о том, что в БАБОК есть отдельный метод "Приоритизация". Этот метод обеспечивает системный подход для бизнес-аналитика для того, чтобы обеспечить принятие решений заинтересованными сторонами и понять относительную важность этой информации. Есть разные подходы к приоритизации, это группировка, что это требование низкого уровня, это среднего уровня важности, это высокого уровня важности. Это такая группировка. Ранжирование. У нас требования ранжированы сверху вниз, каждому присвоен какой-то конкретный коэффициент, который однозначно указывает на его место в иерархии.

Возможен подход к приоритизации, когда у нас есть какое-то бюджетирование или есть какой-то объем средств, и мы берем требование и накладываем в коробку ровно столько, сколько влезает в эту коробку. Это немножко другой подход к приоритизации, сколько влезло, то и берем.

Возможен такой неформальный подход, как переговоры, обсуждения. Исходя из этих переговоров, обсуждений, заказчики просто указывают на приоритизацию фактически без обоснований. Результатом переговоров явилась приоритизация требований вот в таком порядке. Фактически даже без базиса, просто заказчик считает нужным после переговоров выстроить требования вот в таком порядке приоритизации. Возможно и так, когда мы не связываемся или заказчик не хочет подводить под это дело какой-то системный подход, а просто после переговоров бизнес-аналитик получает такой приоритизированный перечень требований.

Давайте посмотрим, что же у нас получилось. Результатом выполнения задачи 5.3 "Приоритизация требований" являются требования, дизайны, решения с модификатором "приоритизированы", то есть они ранжированы, доступны для выполнения какой-то дополнительной работы. Для чего это все нужно? Для первоочередной работы с наиболее ценными дизайнами и решениями. То есть, наша задача приоритизации – в первую очередь надо заниматься тем, чем нужно заниматься именно в первую очередь. На этом по задаче 5.3 "Приоритизация требований" все, всего доброго, до свидания.