Определяем, что важнее: методы расстановки приоритетов в big data и цифровизации

Методы приоритезации

Метод весового ранжирования по одному критерию

Основан на попарном сравнении элементов набора друг с другом для их
ранжирования по заданному критерию.

Ранжирование элементов по заданному критерию

Сравнение производится следующим образом — если элемент1 более значим по выбранному
критерию, чем элемент2, то в ячейку 1:2 ставится 1 балл, а если менее значим, то 0 баллов.
Если элементы примерно одинаковы по значимости, то у обоих можно поставить 0 или 1 балл.
Подобное сравнение проводится для каждой пары элементов.

После сравнения производится суммирование баллов по горизонтали и определяется ранг каждого
элемента. Элемент с наибольшим рангом имеет наибольший приоритет.

Многокритериальная модель весового ранжирования

В этом методе составляется список критериев, по которым будут
расставляться приоритеты элементов.

Ранжирование элементов по нескольким критериям

По каждому критерию выполняется весовое ранжирование элементов. Затем вычисляется сумма
рангов по всем критериям и расставляются приоритеты элементов на основе суммарного ранга.

Уважаемый гость, Это Самая Ценная Часть Метода!!!

Чтобы ее прочитать, РАССКАЖИТЕ ДРУЗЬЯМ об этой странице.
Нажмите на одну из кнопок соц.сетей и добавьте пост на свою страницу.Для получения подсказки как это сделать, наведите курсор на знак вопроса под кнопками
Сразу после этого под этими кнопками откроется ПОТРЯСАЮЩИЙ ТЕКСТ!

Определения приоритетов

Осталось обосновать определения приоритетов. Сделать это можно разными способами. Можно просто определить, никак не обосновывая. Можно и обосновать. Не претендуя на всеобщность я приведу один из подходов. Интересен он только тем, что его можно повторить для других специфических условий. Подход будет такой. Будем придумывать критерий, который позволит из общей массы запросов выделить те, которые требуют более пристального внимания. Потом из этих отобранных выбирать те, которые требуют ещё более пристального внимания. Ход мысли, надеюсь, понятен. А дальше из этих критериев и сделаем определения приоритетов. Чтобы определения были ясными, будем стараться каждый раз выбрать такой критерий, чтобы он был максимально простым и понятным.

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

Вернёмся к делению на приоритеты. Перво-наперво поделим все запросы на важные и неважные. Все неважные безжалостно закрываем.

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

Если Вам почему-то кажется, что все проблемы срочные и критичные, то просто попытайтесь письменно сформулировать, в чём важность и критичность каждой. Вот те, для которых не приходится натужно придумывать причину важности или брать нахрапом (сами что ли не понимаете, это же очень критично!), те и будут критичными

Теперь из срочных и критичных выберем те, у которых нет обходных путей решения проблемы. Да, не так уж и редко бывает так, что с конкретной ситуацией вполне можно справиться без решения исходной проблемы. Посчитать руками на бумажке, собрать отчёт в Экселе, провести ручную операцию вместо штатной и т.п. Это всё обходные пути. Никто не спорит, что так делать неудобно, и что решать проблему надо, ибо зачем нужна ИТ-система, если она не работает. Но при наличии обходного пути, можно потратить на решение больше времени. Поэтому, если обходной путь существует, то им надо сразу пользоваться. Пока исполнитель пытается решить проблему в общем виде, инициатор сразу, не теряя времени, приступает к использованию обходного пути. А если инициатор может себе позволить подождать решения проблемы, то проблема скорее всего не такая уж важная или срочная, за которую он пытался её выдать, можно понижать приоритет.

Вернёмся обратно к приоритетам

Нужно ли выделять в отдельный приоритет что-то ещё более важное? Да вроде бы уже и не нужно. Дальше только аврал

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

• важные, но не критичные запросы (сюда по-умолчанию попадают все новые запросы);
• срочные и критичные (требуется обоснование почему);
• срочные и критичные, для которых нет обходного пути (тоже само собой с обоснованием).

Ну и конечно сверхприоритет:

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

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

Названия можно взять предложенные мной, а можно нейтральные числовые — первый (самый высокий), второй, третий и четвёртый. А то бывает, что у кого-то рука не поднимается открывать запросы с приоритетом, который называется «Низким». Я, например, привык пользоваться обоими.

Как применяется приоритизация в проектах разработки программного обеспечения

Переходя от теории к практике, в нашей индустрии есть множество техник проведения приоритизации.

Есть очень хорошая статья (на английском), которая дает краткое описание 20 техник приоритизации продукта. Хорошее, но далеко не полное собрание техник, которые открывают глаза на разнообразие подходов. Автор статьи идет еще дальше и пытается систематизировать и классифицировать методы по двум измерениям, что сильно упрощает понимание.

Оказывается (!), наши потуги каждый раз придумать подход к приоритизации можно очень облегчить 🙂

Статья не покрывает всех техник приоритизации. Она дает быстрое описание и ссылки на подробные инструкции. Однозначный must read для ознакомления! Запланируйте себе спокойные 30-40 минут на чтение, в том числе и комментариев, которые содержат ссылки на другие техники.

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

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

Идеи от конкурентов, их пользователей и с других рынков

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

Б. КатегоризацияВ. Приоритизация

1. По каждой фиче участники команды (продакты, тимлиды и разработчики, если они разбираются в продукте в контексте пользовательских сценариев) выставляют оценку от 1 до 3 для пользы фичи.
2. По каждой фиче разработчики выставляют оценку временных затрат.
3. Считаются средние величины, и в итоге, столбец 4 показывает отношение пользы к затратам — у каких фич больше процент, те и берем во вторую оценку, медленную.

• проект / фичу,
• количество людей, которых затронет эта функциональность — Reach,
• насколько для них это будет полезно, от 1 до 3 – Impact,
• насколько вы уверены в этой идее – Confidence, в процентах, и
• затраты со стороны разработки, в часах или днях, — Effort, и считаем Rice score – путём умножения первых трех показателей друг на друга и деления их производного на затраты.

1. Составляем формулу оценки прибыльности фичи, закладываем количество людей и денег. Коэффициенты, которые мы точно не знаем, например, сколько людей попробуют новую фичу, мы выделяем жёлтым – их прогоним через вероятности.
2. При помощи экспертов или коллег прикидываем сценарии для пессимистичного, реалистичного и оптимистичного вариантов исхода – что произойдет, и какова вероятность, что произойдёт именно так – после чего считаем среднюю величину, и подставляем в формулы, уже понимая, сколько фича принесет с учетом вероятности.
3. Оцениваем стоимость разработки.
4. Считаем ROI, и если он нас устраивает, заносим фичу в план релиза по месяцам.

1. Выбираем топ 3 ключевые метрики, на месяц или на квартал, видим, что эти метрики влияют на деньги и понимаем, что можем прокачать эти метрики.
2. Собираем гипотезы для их прокачки (пользователи, аналитика, команда, конкуренты).
3. Если рынок новый и аналитики нет – больше делаем акцент на качественный метод, общаемся с пользователями и смотрим на конкурентов.
4. Делаем быструю оценку и отбрасываем слабых кандидатов.
5. Делаем детальную оценку оставшихся кандидатов (например, по ROI).

Идеи от пользователей

• Userbrain.net (закупаете трафик – пользователь получает задание, и вы можете смотреть, как он используют продукт, понимать, насколько хорошо он справляется с кейсами и получать моментальную обратную связь,)
• Flinto.com (рисуете в фотошопе прототип, закидываете в тул и проставляете кликабельные области – наблюдаете за поведением)
• UserVoice (ставится на сайт и собирает фидбек: люди голосуют за фичи, и популярные поднимаются наверх)
• KanoSurvey (приоритизация фичей)
• optimizely.com (A/B эксперименты)
• wootric.com (опросы на сервисе)
• Отзывы и форумы
• Обзвон (мессенджеры, Skype)

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

Будьте готовы, что нее все рады фичам (большинство не рады). Что с этим делать? если фича небольшая – внедрять её нужно мягко, не ломая сценарий пользователя;
если большая — готовить людей заранее, открытость вам только в плюс. Даже для больших изменений обычно достаточно 15-20 касаний продукта пользователем.

• фокус-группы — собираем 5-10 пользователей для работы в группе и смотрим, как они обсуждают, — способ помогает выиграть в скорости получения информации
• наблюдения — при запуске прямых трансляций ВК выдавали пользователям телефон и смотрели, как они себя ведут, что получается и не получается, что обсуждают друг с другом, а также, полезен
• CustDev (интервью + UX) – показываем продукт и просим пользователя прогнать несколько кейсов, или когда нет продукта – тестируем проблематику и спрашиваем, как он раньше решал свою проблему.

• Опрос — почему используете эту функциональность + варианты ответа, которые по метрикам не увидеть.
• A/B тесты, смотрим, какой фидбек приносят пользователи + количественное отражение поведения пользователей.

Техники скоринга

ICE Scoring

• Impact — влияние на продукт либо с точки зрения бизнеса, либо сколько денег принесет, либо что эта фича даст, насколько она крутая. Параметр задается в диапазоне от 1 до 10.
• Confidence — уверенность в оценке сложности или в оценке влияния фичи. Например, вы придумали какую-то функцию и думаете, что она хорошо повлияет на проект. Аналитики не было, данные неточные и пока приоритет основывается только на вашем личном мнении. Чем ниже уверенность в вашем личном мнении, тем ниже показатель. Задается также в диапазоне от 1 до 10.
• Ease — трудозатраты или простота реализации. Также задается от 1 до 10. Чем проще функция, тем у нее выше балл.

Влияние

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

Уверенность

• личном мнении, мнении команды, мнении сторонних экспертов;
• UX-исследованиях;
• опросах;
• интервью;
• наблюдениях, в том числе — за конкурентами;
  MVP;
• A/B-тестах;
• сторонних исследованиях;
• аналитике;
• топовых обращениях в техподдержку;
• топовых запросах от сейлз-менеджеров;
• топовых запросах клиентов.

ПлюсыМинусы

RICE Scoring

• Reach — охват: сколько пользователей у нас от этой фичи получат хоть какое-то удовлетворение, либо заметят эту фичу, либо будут ей пользоваться. Можно измерять количественно: например, 500 миллионов пользователей ощутят на себе эту функцию. Можно измерять в процентном отношении — например, 30% пользователей будет использовать эту фичу.
• Impact — влияние: насколько эта функция на самом деле нам нужна, насколько она нам поможет, насколько функция крутая.
• Confidence — уверенность: аналогично с ICE Scoring, уверенность в наших оценках и прогнозе влияния.
• Effort — трудоемкость.

RICE

Оценка приоритетов проводится на основе следующих критериев:

• Reach — охват, то есть количество людей, которые будут затронуты данным решением. Например, вы решили установить в офисе систему контроля времени. Ваш охват будет равен числу сотрудников.

• Impact — влияние принимаемого решения, выраженное в деньгах или других численных единицах. Для системы контроля времени это могут быть деньги. Например, вы рассчитываете, что ваши сотрудники станут работать в сутки на час больше, что позволит вам делать в месяц на один проект больше, а значит ваша выручка может увеличиться на 1 млн рублей.

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

• Effort — трудозатраты. Они могут быть оценены в деньгах и/или времени.

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

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

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

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

Приоритезация дел

Для целей, которые решено достичь, нужно составить единый список дел. Эти дела также
нужно приоритезировать и для каждого принять решение:

Выполнить

Отложить

Делегировать

Отказаться

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

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

Каждый день выполняйте дела с наибольшим приоритетом, не отвлекаясь на менее
приоритетные

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

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

Если Вы не можете заставить себя заниматься самыми важными делами, а хотите выполнять
сначала что-нибудь полегче, но менее полезное, то воспользуйтесь методом
Тренировка самодисциплины.
При возникновении трудностей с выполнением дела воспользуйтесь методами
Решение проблем и Генерация полезных идей.
При недостатке личного времени воспользуйтесь методом
Управление личным временем и сервисом
Личное время, для поиска и устранения «поглотителей» времени.

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

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

Метод оценки ICE

ICE Scoring: Как это работает?

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

В качестве примера, применим это к фиче «Виджеты для Dashboard»:

Влияние: насколько это будет эффективно? Что это даст нашим пользователям и их целям и задачам?

Легкость реализации: насколько легко будет разрабатывать, тестировать и запускать эту фичу?

Уверенность: как я могу быть уверен, что эта фича приведет к такому улучшению, которое я описал в Impact и займет столько-то времени?

Недостатки ICE

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

Приоритезация целей

Чтобы сделать путь к успеху более эффективным, необходимо
материализовывать все свои цели.
Составьте список личных целей и приоритезируйте их, используя описанные методы.
Определите, какие цели могут быть достигнуты только после достижения других целей
(иерархия целей). Для каждой цели нужно принять решение:

Достичь

Отложить

Отказаться

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

Метод 6: Walking Skeleton – «ходячий скелет».

• В этом методе задачи приоритезируются таким образом, чтобы наиболее тесно связанные между собой требования, которые составляют сквозной бизнес процесс, были реализованы и выпущены одновременно или в течение короткого промежутка времени.
• Вначале отбираются задачи, реализация которых даст минимальный возможный набор  end-to-end функционала и позволит выпустить первую рабочую версию продукта. Данные задачи будут иметь максимальный приоритет.
• Остальные задачи также при помощи приоритетов объединяются по группам. Каждая группа требований получает свой приоритет и ее реализация позволяет добавить к продукту новый небольшой функционал (сквозной бизнес процесс).
• Важным принципом при разбиении требований на группы приоритетов с использованием Walking Skeleton является то, что в первом релизе, в начальной версии продукта мы не реализуем сразу конечную архитектуру. Архитектура и функциональные задачи реализуются параллельно в последующих итерациях.

Цели компании

1 стадия: хороший продукт

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

2 стадия: хороший рост

• привлечение – насколько хорошо приходят новые пользователи,
• referral — как хорошо текущие пользователи приводят своих друзей,
• A/B – тест — вы увидели, что 100 человек зашли на страницу, и только 2 совершили целевое действие, тогда вы что-то меняете и 50 человек отправляете на старую версию, а вторую половину на новую, и сравниваете,
• оптимизация конверсии — работа с воронкой платных лидов,
• тестирование различных каналов и аудитории.

3 стадия: монетизация

• доход, в первую очередь,
• масштабируемость глобальная,
• партнёрства, которые нужно расширить, и
• инфраструктура, которую нужно проработать для ещё более быстрого роста дохода. Например, можно построить хаб, к которому другие приложения будут подключаться, и компания будет что-то с этого иметь.

Метод 4: Kano model — модель Кано.

• В этом методе требования классифицируются на основе предпочтений клиента по 5 категориям. Каждая категория показывает насколько важна пользователю\заказчику\клиенту та или иная функциональность, качество или характеристика продукта:
  • Must-be Quality — обязательные для пользователя характеристики продукта. Это требования, которые заказчики\пользователи\клиенты ожидают в первую очередь и воспринимаются как должное, они являются необходимыми для выпуска продукта. Когда данные функции реализованы, клиенты воспринимают это как само собой разумеющееся, но когда они не реализованы или сделаны плохо, клиенты очень недовольны.
  • One-dimensional Quality — одномерные характеристики. Это функциональность, которая приводит к удовлетворению пользователей\клиентов, когда она реализована и недовольству, когда ее нет. Это параметры и возможности продукта, на которых строится конкуренция компаний между собой.
  • Attractive Quality – привлекательные для пользователя характеристики. Реализация данных требований обеспечивает удовлетворение пользователей, но при этом когда они не выполняются, это не вызывают неудовлетворенности. Это функционал, который обычно не ожидается и радует пользователя, если он вдруг появился.
  • Indifferent Quality – безразличные для пользователя характеристики. Для пользователя требования из этой категории не являются ни хорошими, ни плохими, они не приводят к удовлетворению или неудовлетворенности клиентов. Примером таких задач могут быть различные технические решения, которые скрыты от пользователя.
  • Reverse Quality – противоположные характеристики. К этой группе относятся требования, реализация которых улучшает, но при этом усложняет продукт. Это могут быть различные дополнительные функции, которые расширяют необходимый и достаточный функционал продукта. Для ряда клиентов и пользователей сложный высокотехнологичный продукт, с большим количеством функций и возможностей может быть скорее минусом.
• Данная модель позволяет характеризовать каждую задачу, выстроить очередность реализации требований и сформировать план поставок базируясь на ожиданиях пользователей, управляя их реакцией на вывод той или иной функциональности.

Что же такое приоритизация?

Определение, которое дает Wikipedia: «Приоритизация — понятие, показывающее важность, первенство. Например, приоритет действий определяет порядок их выполнения во времени»

Если пойти еще дальше в этимологию слова, увидим слово «priority» («предшествующий»), еще дальше — «prior» («передний», «прошлый», «старший»).

Из определения становится понятно, что основная цель приоритизации — понять, «что важнее чего»

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

Метод 1: Value Based – техника основанная на ценности для бизнеса.

• В рамках данной техники каждая пользовательская история оценивается с точки зрения ее ценности для бизнеса, какую потенциальную прибыль она может создать для компании.
• В качестве критериев бизнес ценности может выступать не только сумма заработанная на продукте, но и репутация компании, удовлетворенность пользователей, качество и надежность продукта (хотя все эти факторы в конечном счете так или иначе конвертируются в прибыль).
• Ценность того или иного требования для бизнеса может быть определена владельцем продукта (Product Owner) либо самостоятельно, либо с привлечением команды бизнес заказчиков и стэйкхолдеров.
• Чем выше ценность, тем приоритетнее требование и, следовательно, тем раньше оно должно быть реализовано и поставлено на рынок.

Метод 3: «MoSCoW» — метод «Москва».

При оценке приоритета методом «MoSCoW» для каждой задачи мы подбираем наиболее соответствующее ей 1 утверждение из 4

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

Must have this – Это обязательно должно быть

«Must» требования не подлежат обсуждению и в любом случае должны быть реализованы. Если они не поставлены пользователю в ближайших релизах, тогда весь проект не имеет смысла.

Should have this if at all possible – Следует сделать, если это только возможно. Данные задачи также важны для пользователя и\или заказчика, однако, сроки их поставки не так критичны как для «Must». Без данной функциональности продукт уже можно использовать, ее отсутствие не блокирует базовых возможностей из списка «Must» и она может быть выдана немного позже.

Could have this if it does not affect anything else – Можно сделать, если это не повлияет на что-то другое. Эта категория задач допускает максимально гибкий взгляд на такие основные критерии выполнения как скоуп, сроки, качество и ресурсы. Здесь возможна вариативность и компромиссы.

Will not have this time but would like in the future – Сейчас на это нет времени, но хотелось бы сделать в будущем. Для этой категории ключевым моментом является то, что данные требования могут быть также важны (также как и «Must»), однако, их можно оставить для более поздних поставок продукта. Категория «Will not» имеет 3 важных эффекта:
Пользователям и заказчикам не нужно бороться, чтобы включить какое-либо требование в Product Backlog.
Имея возможность видеть список требований для отдаленных релизов, можно оценить как это будет влиять на то, что будет реализовано в первую очередь.
На требования из категории «Will not» можно ориентироваться как на долгосрочную тенденцию в развитии продукта, учитывая данные особенности в ранних поставках.

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

Зачем нужны приоритеты и какими они должны быть

Когда мы сами пишем регламенты, мы сами устанавливаем «правила игры». И имеет смысл установить такие правила не абы как, а чтобы было максимально удобно и эффективно. Это вопрос опыта, но начинать плясать от чего-то надо. Дальше уже дотачивать по месту. Давайте поговорим о том, как определять приоритеты. Начнём как обычно с главного — с ответа на вопрос «зачем это нужно».

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

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

Удобно иметь 3-5 приоритетов. Обычно этого хватает на все случаи жизни, другое количество приоритетов является скорее экзотикой. Чтобы приоритеты правильно работали, запросов более высокого приоритета должно быть в 5-10 раз меньше, чем предыдущего. Получается эдакая характерная лесенка (см.рис.)

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

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

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

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

Дом качества

Еще одна японская методика пиритизации, созданная Йоджи Акао в 1966 году. Ее официальное название — 
«Развертывание функции качества»
, но широко известно иное наименование — «дом качества», где:

• крыша — корреляция между характеристиками продукции, определенными командой как значимые;

• левое крыло — перечень характеристик, определенных пользователями как значимые;

• правое крыло — рейтинг приоритетности характеристик, по мнению клиентов;

• фундамент — рейтинг приоритетности характеристик, определенных командой как значимые для продукта.

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

Работа начинается со сбора информации о потребностях клиента: что в вашем продукте или услуге для него самое важное. Вариантов сбора информации может быть много — от анкетирования до глубинного интервью.. Получив результаты, заполните матрицу «дома качества»:

Получив результаты, заполните матрицу «дома качества»:

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

2. Дайте названия строкам. Это будут те характеристики продукта, что вам сообщили клиенты в ходе полевых исследований. Например, цена, внешний вид и т.д.

3. Определяем вес для потребительских характеристик в относительной шкале от 0 до 10 по частоте ответов пользователей. Например, первая характеристика была выбрана клиентом как приоритетная 10 раз, значит ее вес 0.1, а пятая — 8 раз, ее вес 0.08. Сумма всех коэффициентов должна быть равна единице.

4. Далее заполняется «крыша». Если технические характеристики, обозначенные командой, усиливают другу друга, ставим плюс, ослабляют — минус, не влияют друг на друга — знак равенства.

Далее сравниваем характеристики клиентов и команды, присваивая каждой баллы по шкале:

9 — характеристики клиентов и команды имеют причинно-следственную связь.

3 — связь есть, но слабая.

1 — связи нет.

Умножаем оценки из пункта выше на коэффициент клиентской характеристики.

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

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