Аналитик · Организация работ

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

Статья — участник конкурса от ITWorks!

Источник: https://www.bridging-the-gap.com/requirements-prioritization/

Автор:  Laura Brandenburg

Вольный перевод: Анна Гасраталиева

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

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

Я Лора Бранденбург из “Bridging the Gap”.  Мы помогаем бизнес-аналитикам начать карьеру.

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

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

Если вам сказали, что вы слишком ориентированы на бизнес, то это обратная связь, которую некоторые аналитики получают, когда они являются своего рода куклой в руках заказчика, и просто говорят, “хорошо, вы хотите все эти требования сразу. Тогда я так и сделаю.”

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

Давайте поговорим о некоторых самых простых способах. Это не должно быть сложно.

Определение приоритетов требований становится проще, когда вы знаете, какую проблему решаете

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

Допустим, вы знаете, что должны решить проблему А, Б и В. То есть задачи бизнеса — увеличение продаж, повышение лояльности или увеличение эффективности в каком-то конкретно месте. Это значит, что вы понимаете, какие требования самые важные, так как можете соотнести требования и требования бизнеса.

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

Существует также сложность с масштабированием процесса обучения, когда мы начинаем обслуживать все больше и больше клиентов. Все, что мы делаем, не должно усугублять эту проблему. “Помогает ли вот эта конкретная функция решить нашу проблему?” — это очень четкий фильтр, его обязательно нужно использовать в процессе приоритизации.

Приоритизация требований становится проще, когда вы упрощаете ее

Есть много сложных инструментов для приоритизации требований, с которыми вы можете попробовать поэкспериментировать. Но мы сфокусируемся на практических простых практиках, которые мы используем в ““Bridging the Gap””. Ниде вы можете увидеть два основных способа, которые я предлагаю.

Вы даете каждому требованию приоритет 1, 2 или 3.

1  — самый высокий приоритет, 2-средний, 3-низкий. Это довольно просто. Проблема в том, что каждый хочет, чтобы все было 1.

Вы должны вернуться к тому, какую проблему мы решаем:

  1. Фичи с приоритетом 1 — это фичи, которые помогают нам решить проблему максимально эффективно,
  2. Фичи с приоритетом 2 могут быть похожими на то, что они могут добавить к проблеме, но они не важны для решения проблемы, и
  3. Фичи с приоритетом 3 — это какие-то связанные фишки, которые мы хотели бы получить, но скорее всего они не будут реализованы в этом проекте.

Этот этап закончен, когда вы распределили требования по приоритетам от 1 до 3.

Вторая идея заключается в ранжировании порядка

Так, если каждое требование имеет приоритет 1, 2, и 3, то порядок рангов был бы таким: 1, 2, 3, 4, 5, 6.. и так до конца списка. Вы говорите, что требование №1 самое важное, а №2 более важен, чем №3… и так упорядочиваете приоритеты.

Это очень мощный способ приоритизации требований, используемый для гибкой разработки программного обеспечения. Убирается вся двусмысленность по поводу того, какое требование важнее, какое менее важно. Ведь нет никакого смысла иметь 20 фич с приоритетом 1, когда  мы можем сделать только три фичи в ближайшем спринте. Какие именно три из этих 20? Мы сделаем фичу №1, 2 и 3. А в следующий спринт возьмем фичи с номером 4, 5 и 6.

Я думаю, что именно сочетание этих методов хорошо работает, если у вас есть продукт с бэклогом в 20, 30, 50 элементов. Ранжируя их от 1 до 50 вы начинаете спрашивать себя, есть ли разница между 45 и 46? Насколько это вообще важно?

Когда мы работаем в рамках приоритетов от 1 до 3, то используем их, чтобы выкинуть совсем неважное, а затем ранжировать те, которые явно важны, то есть являются нашим приоритетом 1. Попытка ранжировать все-все требования — это ужасно утомительная задача, которая несет все меньше и меньше смысла в ходе движения вниз по бэклогу.

Определение приоритетов требований становится проще, когда вы понимаете сроки и трудозатраты

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

В рамках разработки системы управления обучением я установила приоритеты от 1 до 3. У нас было несколько фич с приоритетом 3, то есть у  нас были фичи, которые не являлись чем-то необходимым, но если бы они были, это было бы здорово. Однако, если мы должны были бы потрудиться, чтобы эти фичи были реализованы, то от них придется отказаться.

Фичи с приоритетом 1 были очень важны. Они были просто необходимы для решения проблемы, для проведения курсов и обеспечения работы нашего бизнеса. Мы должны были иметь фичи из списка “приоритет 1”. Они были необходимы нам, чтобы выпустить продукт.

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

Поэтому про фичи с приоритетом 2, я сказала: “если это конфигурация, то есть что-то, что позволяет настраивать наш продукт, или если это займет меньше часа работы, то давайте сделаем это”. Если для реализации фич с приоритетом 2 потребуются серьезные доработки или новые инструменты (которых у нас нет или не доступны из коробки), мы не будем делать это в рамках текущего проекта.

Это дало нам всем возможность понять, что означает приоритет 2, и стало легче расставить приоритеты, поскольку мы знали, каким временем и затратами располагаем. Затем мы могли посмотреть на фичи с приоритетом 2, по которым не было понимания, как они могут быть реализованы. Требуется не так уж много анализа, и немного сотрудничества с командой, чтобы проверить каждое из этих требований. Достаточно лишь спросить: «Сколько времени займет реализация этого требования?Сколько это будет стоить?”

Вы можете заметить, что приоритеты заинтересованных лиц, как правило, немного смещаются со временем. Иногда что-то, что вы считали важным — например, фича с приоритетом 1 — может опуститься до приоритета 2 или даже 3, когда вы скажете: «о, это две недели работы».

И вы видите, что когда люди понимают время, объем и бюджет, которые уйдут на выполнение этого требования, то они начинают гораздо комфортнее ощущать себя при  приоритизации требований, потому что теперь она имеет для них гораздо больше смысла. Теперь у этого процесса есть фактическое значение, а не просто: «Эй, до тех пор, пока я могу попросить все, я буду просить все”.

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

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

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

Как вы устанавливаете приоритет требований?

Я надеюсь, что это была полезная статья. Я хотела бы узнать, как вы устанавливаете приоритеты требований, или какие проблемы у вас возникают в процессе. Я Лора Бранденбург из “Bridging the Gap”.  Мы помогаем бизнес-аналитикам начать карьеру.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *